Tablica zadań inspirowana ideą Kanban niesłychanie rozprzestrzeniła się wśród zespołów projektowych. Oferuje niesamowitą przejrzystość i elastyczność. Przejrzystość wynika z prostoty i tego, że od razu wszystko widać. Kto zajmuje się danym zadaniem, na jakim statusie znajduje się zadanie, ile zadań czeka w ogonku. Elastyczność, bo w kanban obowiązuje tylko kilka zdroworozsądkowych zasad.
Znacznie upraszczając tą metodę można powiedzieć, że:
- Zadania płyną z lewa na prawo zgodnie z ustalonym porządkiem kolumn i raczej się nie cofają.
- Zespół ustalił jasne kryteria, kiedy zadanie może przeskoczyć między kolumnami.
- Zadania posortowane są według ważności z góry na dół.
- Członkowie zespołu mają autonomię, jeżeli chodzi o tempo brania zadań do realizacji.
- Klient może regularnie dodawać zadania do pierwszej kolumny i zmieniać ich priorytety.
- W idealnej sytuacji każdy członek zespołu może podjąć się dowolnego zadania, co zapewnia najoptymalniejszą alokację mocy przerobowych.
Wokół zadań mogą trwać dyskusje, zadania mogą mieć listy kontrolne, można załączać pliki i obrazki do nich.
Jednak jak obserwuję różne zespoły to praktyka stosowania tablicy kanban bywa różna. Za chwilę omówię przykłady, ale najpierw chciałbym rozstrzygnąć powody.
Pierwszym ograniczeniem Kanbana jest liniowość. Zakłada się, że zadania nie wracają i wędrują tą samą ścieżką. Dopóki dla różnych zadań można stworzyć taki sam zestaw etapów, dopóty mogą one być zarządzane wspólną tablicą. Jednak natura prac nawet w jednym projekcie bywa różna. Przykładowo inaczej produkuje się oprogramowanie, inaczej szkoli pracowników, a inaczej projektuje materiały reklamowe. Natomiast wszystkie te zadania mogą być realizowane przez jeden zespół w jednym projekcie.
Drugim ograniczeniem jest bałagan. Kanban dobrze sprawdza się dopóki lista zadań nie przekracza dwóch, trzech ekranów przewijania. Przy dłuższych listach zaczyna się bałagan. Przy większej liczbie zadań pojawia się także potrzeba klasyfikowania, grupowania, zagnieżdżania zadań. Dobrze obrazuje to użycie WBS w projektach budowlanych, albo dzielenie zadań na moduły w projektach typ hardware.
Trzecim ograniczeniem są kompetencje. Bardzo często jednym zadaniem nie może zająć się dowolny członek zespołu, bo się po prostu na tym nie zna. Konkretne zadanie musi trafić do konkretnego eksperta. Wówczas wspólna tablica nie służy balansowaniu zasobów tylko demonstrowaniu bieżących wyzwań i priorytetów.
Czwartym ograniczeniem jest różny cykl produkcyjny. Jedne zadania można machnąć w dzień lub maksymalnie w sprint. Inne jednak wymagają dużo dłuższego czasu, zatem przeskoczą między sprintami. W projektach eksploracyjnych rozwiązuje się to po prost wprowadzając sprinty o nieregularnej długości. Jednak sytuacja, gdy jakieś zadanie wisi na tablicy tygodniami, bo albo zespół czeka na dostawę komponentu z Chin, albo mozolnie zbiera dane badawcze, wprowadza zamieszanie.
Zatem, w jaki sposób zespoły przełamują te ograniczenia kanbana.
Pierwszy z omawianych projektów realizowany był w sektorze kosmicznym. Był to projekt hardware’owy, czyli jego celem było stworzenie urządzenia. Początkowo zespół stworzył klasyczną tablicę z kolumnami reprezentujacymi statusy prac. Tablica była regularnie przeglądana i zadania wędrowały z lewa na prawo. Jednak po kilku miesiącach wykorzystanie tej techniki zaczęło ewoluować. Po ponad roku tablica wyglądała mniej więcej tak:
Jak widać kluczowym wyzwaniem było pokazać stan prac w podziale na główne moduły. Wynikało to z tego, że moduły były różne kompetencyjnie i zajmowały się nimi różne zespoły.
W innym projekcie, tym razem był to startup z obszaru usług internetowych, tablica Kanban wyglądała tak:
W tym projekcie zespół też zaczął od tradycyjnego kanbana, ale po jakimś czasie zaczął modyfikować tablicę. Jak widać ważne dla niego było dodanie trzech kolumn zawierających backlog. Wynikało to z tego, że ów startup miał mnóstwo pomysłów i trzeba było wprowadzić lejek, który porządkowałby ich napływ.
W jeszcze innym projekcie IT wprowadzono kolumny reprezentujące zakresy kolejnych wdrożeń systemu. W innym dodano strumienie prac reprezentujące główne zakresy merytoryczne. W jeszcze innym podzielono prace na eksploracyjne (discovery) i produkcyjne (delivery), dodając odpowiednie kolumny z backlogami.
Czy to źle, że zespoły modyfikują metodyką? Skądże, najważniejsze kryterium to czy dane rozwiązanie działa i przynosi korzyść. Żeby działało, zespół musi się z nim utożsamiać.
Ograniczenia tablicy Kanban dostrzeżono już wcześniej i pojawiło się kilka rozszerzeń.
W niektórych systemach takich, jak Proofhub, Trello można do zadania dodać podzadania. Takie dwa poziomy zadań ułatwiają zarządzanie zakresem, gdy backlog jest bardzo długi.
W innych, jak Teamwork i Productboard, wprowadzono storymap. Jest to tablica Kanban z dodanym wymiarem Y. Zadania są podzielone również na wiersze reprezentujące kolejne etapy lub wdrożenia rozwiązania. Przyklad poniżej:
Wreszcie sam, nieskromnie dodam, również postanowiłem zająć się tym problemem i opracowałem rozwiązanie pozwalające na dowolne zagnieżdżanie zadań. To połączenie logiki WBS i tablicy Kanban.
Wroolo to ciągle jeszcze prototyp, ale starałem się zademonstrować, że możliwe jest dowolnie elastyczne zagnieżdżanie zadań w ramach jednej tablicy. Mimo możliwości przenoszenia ich przez kolejne kolumny, można nie utracić porządku w stworzonej strukturze prac.
Chętnych do sprawdzenia, jak działa filozofia kanban zapraszam do naszych dwóch symulatorów:
- Agile Game – gra indywidualna na tablicy Kanban, pokazuje różne wykresy dostępne w ramach tej metodyki.
- Scale Agile – gra zespołowa demonstrująca problemy bilansowania zasobów, wielozadaniowości i priorytetyzowania prac między projektami zwinnymi.
Chętnych do sprawdzenia, jak działa system Wroolo, zapraszam pod adres wroolo.com.
Jedno zastrzeżenie chcę zgłosić. Powyższe rozumienie tablicy Kanban jest zupełnie różne od tego stosowanego w zarządzaniu magazynem lub produkcją. Wspomniany w tym artykule Kanban jest znacznie uproszczoną wersją magazynowo – produkcyjnego, który był jego pierwowzorem.
