W poprzednim tekście “Scrum z Kanban” https://www.jsproject.pl/wiedza/kanban/987-scrum-z-kanban wyjaśniłem dlaczego warto rozszerzyć Scrum o praktyki i metryki Kanban oraz opisałem jak to zrobić, wprowadzając do Scrum’owego podejścia iteracyjnego i framework’u Scrum, zasady, praktyki oraz metryki podejścia Flow (ang. przepływ).

W tym zaś tekście przeczytacie o tym, jak podczas wydarzeń Scrum’a stosować praktyki Kanban oraz wykorzystywać metryki Kanban.

Przypomnijmy na początek, że Kanban to strategia optymalizacji przepływu wartości (ang. flow of value) przez proces, używająca wizualnego systemu ssącego (ang. pull-based system). Jak podaje The Kanban Guide - strategią Kanban jest optymalizacja wartości poprzez optymalizację przepływu, oznaczającą dążenie do odpowiedniej równowagi pomiędzy efektywnością, wydajnością i przewidywalnością sposobu wykonania pracy.

Jak można przeczytać w Przewodniku: Kanban dla zespołów Scrum: „Kanban stosowany w kontekście Scruma nie wymaga wprowadzenia żadnych dodatkowych wydarzeń ponad te wyszczególnione w Przewodniku po Scrumie”.

Zobaczmy więc, jak będą wyglądały wydarzenia Scrum’owe zorientowane na przepływ i uwzględniające perspektywę praktyk i metryk Flow. Warto na początek podkreślić, że choć przebieg, treść i kluczowe tematy rozmowy w każdym z wydarzeń Scrum ulegają zmianie, to sam Scrum pozostaje niezmieniony. Scrum nadal będzie wykorzystywany do zarządzania pracą realizowaną w czasie Sprintu, natomiast Kanban i jego praktyki i metryki będą zastosowane do optymalizacji przepływu tych prac i w konsekwencji do optymalizacji przepływu wartości związanych z realizowaną pracą.

Planowanie Sprintu:

Podczas planowania Sprintu Product Owner oraz zespół deweloperski dyskutują teraz o możliwościach realizacyjnych zespołu, określonych przepustowością. Nie będą w ogóle rozmawiali o oszacowaniu zadań w punktach (ang. story points). Teraz to właśnie przepustowość zespołu będzie kluczową informacją podczas określania Celu Sprintu oraz Rejestru Sprintu, gdyż to ona będzie umożliwiała określenie ile pracy zespół jest w stanie dostarczyć w Sprincie.

Natomiast wiek pracy (WIP Age) będzie analizowany podczas Planowania Sprintu w przypadku, gdy niektóre prace z poprzedniego Sprintu nie zostały ukończone. Pomocą jest tu także porównanie wieku nieukończonej pracy z ustalonym poziomem SLE. Decyzja o tym, czy kontynuować tę nieukończoną pracę będzie podjęta na podstawie Celu Sprintu oraz takich metryk Flow, jak: przepustowość, SLE, wiek pracy oraz dodatkowo na podstawie wartości tej pracy.

Codzienny Scrum:

Cele Codziennego Scrum – opisane w Scrum Guide – pozostają bez zmian. W sytuacji rozszerzenia Scrum o praktyki i metryki Kanban spotkanie to odbywa się przy tablicy Kanban, a rozmowa koncentruje się wokół metryk przepływu.

Kluczową metryką dyskutowaną podczas codziennego spotkania będzie teraz wiek pracy w zestawieniu z poziomem SLE, gdyż ich analiza pozwala określić, czy termin dostarczenia pracy, określony w SLE, będzie dotrzymany. Wiek pracy będzie też określał zasadę pobieranie pracy do realizacji w każdym z etapów. Będzie on też ograniczał pobieranie kolejnych prac do realizacji i pozwalał na działanie wg Kanban’owej zasady „Stop starting, start finishing”.

Praktyka wizualizacji procesu pracy na tablicy umożliwia podczas Codziennego Scrum „przechodzenie” (czyli w praktyce analizowanie) prac znajdujących się na tablicy zespołu: od prawej kolumny do lewej (czyli najpierw prace znajdujące się najbliżej ukończenia) oraz od góry do dołu w każdej kolumnie, w której prace najstarsze i prace priorytetowe będą znajdować się właśnie na górze kolumny.

Rozmowa podczas spotkania koncentruje się więc na zapewnieniu przepływu realizowanej i zaplanowanej pracy, a tym samym na miejscach i problemach ograniczających płynny przepływ i działaniach, jakie należy podjąć dla „upłynnienia” przepływu.

Inne tematy i punkty do rozmowy podczas Codziennego Scrum, zorientowanego na zapewnienie płynnego przepływu to:

• Identyfikacja zablokowanych prac i określenie co Zespół Scrumowy może zrobić żeby je odblokować
• Identyfikacja prac, które przepływają wolniej niż oczekiwano i analiza wieku każdej z prac w toku. Identyfikacja prac, które już przekroczyły lub wkrótce przekroczą ustalony poziom SLE i określenie co Zespół Scrumowy może zrobić, by te prace zostały ukończone
• Identyfikacja innych czynników, wpływających na zdolność Zespołu Scrumowego do ukończenia pracy dziś, a niewidocznych na tablicy
• Ujawnione nowe – dla Zespołu Scrumowego - informacje, mogące zmienić plany dotyczące kolejnych realizowanych prac
• Sytuacja dotycząca limitów prac w toku (limitów WIP): czy i w jakich fazach zostały one przekroczone. Określenie co Zespół Scrumowy może zrobić dla ukończenia prac w toku.

Przegląd Sprintu:

Product Owner, interesariusze oraz zespół – trzymając się zasad Przeglądu, opisanych w Scrum Guide - będą podczas Przeglądu Sprintu analizować (czyli robić inspekcję w języku Scrum) uzyskane podczas Sprintu rezultaty oraz analizować kiedy poszczególne elementy Rejestru Produktu mogą być dostarczone. Do tych analiz będą wykorzystywane takie mierniki – i ich wizualizacje – jak: wykres XY czasu wykonania (ang. Cycle Time scatter plot) oraz SLE.

Dzięki temu wykresowi, jak i metodom prognozowania probabilistycznego (symulacje Monte Carlo) Product Owner oraz interesariusze mogą otrzymać precyzyjniejszą, w porównaniu do tradycyjnych metod szacowania, odpowiedź na pytania: kiedy zostanie ukończona konkretna funkcjonalność? kiedy zostanie dostarczone wydanie, czyli moduł składający się z wielu funkcjonalności?

Retrospektywa Sprintu:

Retrospektywa zorientowana na optymalizacji przepływu realizuje Scrum’ową zasadę „Inspect and Adapt” dla określenia możliwych i celowych do wprowadzenia usprawnień w sposobie pracy zespołu, w szczególności zaś w Definicji Procesu (ang. Definition of Workflow). Dzięki wykorzystaniu takich metryk przepływu i ich wizualizacji na wykresach, jak:

• Skumulowany diagram przepływu (ang. Cumulative Flow Diagram – CFD)
• Wykres liniowy przepustowości (ang. Throughput run-chart)
• Wykres blokerów

czyli danych historycznych, zespół jest w stanie zidentyfikować - na podstawie analizy ilościowych danych historycznych, a nie na podstawie opinii i intuicji (jak się to często dzieje w przypadku Scrum) – najważniejsze problemy, przeanalizować ich źródłowe przyczyny oraz zaproponować rozwiązania do wprowadzenia. A wszystko to zgodnie z zasadą Kanban „dokonujcie wspólnie w zespole, ewolucyjnych zmian i usprawnień”.

Co ważniejsze: ponieważ metryki przepływu są zbierane na bieżąco – dzień, po dniu – to takie retrospektywy, z wykorzystaniem w/w metryk, mogą być realizowane na bieżąco, w trakcie Sprintu.

Koniecznie jednak, dokonując usprawnień, bazujących na metrykach przepływu, trzeba uzbroić się w cierpliwość. Potrzebny jest bowiem czas, by wprowadzona zmiana, np. zmniejszenie poziomu limitu WIP, dało się zaobserwować na wykresie CFD, czy na wykresie XY czasu wykonania.

Podsumowanie

Sądzę, że z tego, jak i wcześniejszego tekstu wyraźnie wyłaniają się korzyści z rozszerzenia Scrum o praktyki i metryki Kanban, czyli praktyki Flow Management. Do najważniejszych z nich należą skuteczne i efektywne zarządzanie pracą, bazujące na metrykach i danych historycznych, a nie na punktach, opiniach i intuicjach i prowadzące do zwiększenia przewidywalności dostarczania, do stabilności pracy zespołu, a w konsekwencji do zadowolonych klientów i równie zadowolonych pracowników.

Sprint (czyli iteracja) rozszerzony o myślenie i działania zorientowane na przepływ, to – jak widzę w zespołach stosujących opisane rozszerzenie Scrum o praktyki i metryki Kanban – zupełnie inna jakość pracy i inny poziom uzyskiwanych rezultatów.

Co dalej? Sądzę, że zgodnie z logiką Kanban’owego i Lean’owego ciągłego doskonalenia, warto pomyśleć po prostu o odejściu od Sprintu i pracy iteracyjnej (gdyż ma ona kilka istotnych słabości o których niedługo napiszę) i przejściu na stosowanie Flow Management.

I zacząć od stosowania Flow Management na poziomie zespołu deweloperskiego lub innego zespołu realizacyjnego. Potem zacząć stosować Flow Management na poziomie projektu i/lub produktu i wreszcie na poziomie całej firmy, czyli na poziomie portfela prac i projektów/produktów dla osiągnięcia zwinności biznesowej w całej firmie.

Parafrazując łacińską sentencję: „Per Flow ad Enterprise Agility”.