Kanban dla Zespołów Scrumowych nie odejmuje niczego z ram postępowania w Scrum. To szalenie ważne zdanie! Niektórzy bowiem mylnie podchodzą do przewodnika dostępnego na scrum.org, interpretując jego nazwę w następujący sposób:
„a to fajnie, będziemy w końcu mogli nie planować jak przejdziemy na tego Kanbana”.
Nic bardziej mylnego. W tym zdaniu znajdują się aż dwie niepoprawne interpretacje. Po pierwsze, idea samego Kanbanu jest tutaj źle zrozumiana. Wśród wielu osób krąży przeświadczenie, że w pracując w Kanbanie nie trzeba planować, a jedynie dobierać rzeczy po kolei, zgodnie z określonym priorytetem. Faktycznie, Kanban to pull system (polska nazwa: ciągniony), czyli praca jest zaciągana wtedy, kiedy poprzednia jest zakończona. Jednak ogromnie ważne jest tutaj planowanie i uwzględnianie takich rzeczy jak praca w toku (WIP), Czas Cyklu (Cycle Time), Przepustowość (Throughput). Po drugie Kanban dla Zespołów Scrumowych nie zastępuje ram opisanych w Przewodniku Scrumowym, a jedynie je wzmacnia i uzupełnia.
Czym różni się zatem praca w Scrumie od tej w Kanbanie dla Zespołów Scrumowych?
Praktyki Kanbanu
Wizualizacja przepływu pracy
Jedną z rzeczy na której powinny skupić się Zespoły Scrumowe korzystające z praktyk Kanbanowych jest wizualizacja pracy. Scrum w żaden sposób nie definiuje jak osiągnąć przejrzystość przepływu pracy z Backlogu Produktu do Backlogu Sprintu. Tutaj z pomocą przychodzi Kanban definiując Workflow, czyli przepływ pracy. Nie jest to ściśle narzucony system, a wręcz przeciwnie. Każdy Zespół może i powinien zdefiniować swój własny przepływ pracy. Dla lepszej wizualizacji powinien on jednak zawierać kilka elementów:
- jasno zdefiniowane punkty, rozpoczęcia i zakończenia pracy nad określonymi elementami pracy (w wielu przypadkach będą to elementy Backlogu Produktu, PBI – Product Backlog Item);
- definicję pracy w toku (Work in Progress, WIP) i tego jak będzie ograniczana;
- określenie stanów przepływu pracy nad PBIs od momentu rozpoczęcia do zakończenia pracy nad nimi. Stanami mogą być na przykład:
- przepływ pracy z testów wewnętrznych na środowisko UAT;
- przepływ pracy z developementu do code review;
- Zasady co do przepływu pracy pomiędzy określonymi stanami.
Dzięki wizualizacji za pomocą tablicy kanbanowej wspieramy jeden z filarów Scruma, czyli transparencja. Warto podkreślić, że zespół nie musi się ograniczać do stworzenia przepływu pracy tylko dla Backlogu Sprintu. Śmiało może określić co dzieje się wcześniej i później z elementami backlogu lub z Przyrostem. Nic nie stoi na przeszkodzie, aby przepływ pracy był zdefiniowany osobno dla różnych typów PBI, czy innych jednostek wartości dla klienta.
Limity pracy w toku (WIP limit)
Zespoły Scrumowe, które używają Kanbanu muszą limitować swoją pracę w toku, czyli taką, nad którą zespół rozpoczął pracę, ale jej jeszcze nie zakończył. Jeszcze raz wrócę do Workflow by podkreślić, jak ważne nie tylko dla samej wizualizacji pracy, ale również ustalania limitów pracy w toku jest ustalenie momentu rozpoczęcia i zakończenia pracy nad poszczególnymi elementami. Limity ustalamy by ograniczać pracę w toku dla poszczególnych stanów określonych w Workflow. Pracę limituje się na przykład na grupę kolumn na tablicy Kanbanowej, na całą tablicę lub w dowolnie określony sposób przez Zespół Scrumowy. Poprzez określanie limitów pracy w toku tworzy nam się wspomniany już system ciągniony. Zespół dobiera kolejne elementy tylko wtedy, kiedy ma jasny sygnał żeby to zrobić. W Scrum, Sprint jest formą WIP, wtedy to Zespół Deweloperski próbuje wykonać określoną na planowaniu pracę w ustalonym czasie.
Aktywne zarządzanie elementami pracy w toku
Aktywne zarządzanie przepływem pracy w roku tuż obok WIP limitów jest niezbędnym elementem Zespołów Scrumowych pracujących w Kanbanie. Może ono przyjmować różną formę, nie jest zdefiniowane w konkretny sposób. Ważne jest proaktywne, aktywne i reaktywne zarządzanie pracą w toku i podejmowanie odpowiednich akcji wspierających przepływ. Cały Zespół Scrumowy jest odpowiedzialny za aktywne elementami pracy w toku na każdym etapie Workflow. Wśród akcji jakie zespół może podejmować można wymienić:
- upewnienie, że elementy nie spędzają niepotrzebnie czasu w przepływie pracy, czyli nie ulegają nieuzasadnionemu starzeniu się. Mówiąc prościej, element, który został zakończony powinien zostać odpowiednio przeniesiony do właściwego miejsca na tablicy Kanbanowej;
- aktywne reagowanie na potencjalne problemy, zablokowane elementy pracy.
Jednym z miejsc do dokonywania inspekcji m.in. wymienionych wyżej problemów może być Daily Scrum należy jednak pamiętać, że cały Sprint jest doskonałym miejscem do aktywnego zarządzania elementami pracy w toku. Kanban dla Zespołów Scrumowych daje nam kolejne, dodatkowe narzędzia i miary które możemy wykorzystywać żeby dokonywać inspekcji i adaptacji.
Inspekcja i adaptacja definicji przepływu pracy
Kanban dla Zespołów Scrumowych bardzo mocno skupia się na wizualizacji. Jednym z elementów, które są niezbędne do prawidłowego działania zespołów jest ciągła inspekcja i adaptacja stworzonego Workflow. Przykładami aspektów, które Zespół Scrumowy powinien poddawać usprawnieniom są:
- Stany przepływu;
- Limit WIP;
- Batch size, czyli wielkość paczek, które są wypuszczane na produkcję;
- Moment w którym pracę nad daną jednostką pracy uznaje się za rozpoczętą, etc.
W Scrum każde zdarzenie służy dokonywania inspekcji i adaptacji. Gdy wykorzystujemy do pracy Kanbana nic się w tym kontekście nie zmienia. Mamy tylko dodatkowe elementy, które powinny być usprawnianie i metryki, które mogą nam pomóc w inspekcji i adaptacji.
Metryki
Kanban dla Zespołów Scrumowych tuż obok czterech praktyk Kanbanu stawia cztery metryki, które już mimochodem pojawiły się w pierwszej części artykułu. Zbiorę je jednak w całość:
- Praca w toku (Work in Progress, WIP) – liczba elementów pracy, które zostały rozpoczęte zgodnie z definicją przepływu Zespołu Scrumowego, ale praca nad ciągle trwa (nie zostały ukończone);
- Czas Cyklu (Cycle Time) – to czas jaki upłynął od momentu rozpoczęcia pracy nad danym elementem do jego zakończenia;
- Wiek elementu pracy (Work Item Age) – czyli czas który upłynął od rozpoczęcia pracy nad danym elementem do chwili obecnej; pozwala określić jak stare jest dane zagadnienie;
- Przepustowość (Throughput) – liczba elementów pracy ukończonych w jednostce czasu, np. w Sprincie.
Metryki te są konieczne do aktywnego zarządzania elementami pracy w toku, czyli do clou tego co powoduje, że Zespoły Scrumowe pracują w Kanbanie. Są one również świetnym, dodatkowym narzędziem, które wspomaga inspekcję i adaptację. Metryki powinny być monitorowane i wykorzystywane w trakcie całego Sprintu, a szczególnie podczas niektórych zdarzeń Scrumowych. Daniel Vacanti wskazuje na poniższą konieczność wykorzystywania metryk podczas zdarzeń:
Podsumowanie
Na koniec chciałabym jeszcze raz podkreślić, że Kanban dla Zespołów Scrumowych opiera się całkowicie na Przewodniku Scrumowym, nie odejmując z niego żadnych elementów. Często zdarza się, że wiele z Kanbanowych praktyk już stosujemy pracując w Zespołach Scrumowych. Ale nie zdajemy sobie z tego sprawy. Dla mnie takim odkryciem było Workflow. Od lat pracując w Scrumie ustalam z różnymi zespołami jak poszczególne elementy naszej pracy będą przechodzić przez kolejne stany przepływu. Podejrzewam, że u Was może być podobnie. Jak pracować z metrykami, jak wyznaczać je w praktyce oraz jak wykorzystywać na poszczególnych zdarzeniach Scrumowych? O tym opowiem Wam już w kolejnej części.
Sprawdź nasze ostatnie wpisy:
