Blog

W opublikowanych ostatnio artykułach opisałem, co łączy Scrum z Kanbanem i czym te dwa narzędzia się różnią. Charakter podobieństw i różnic powoduje, że każdy Zespół Scrum może posłużyć się Kanbanem do optymalizacji swojego procesu. Inaczej mówiąc, Scrum i Kanban mogą być stosowane równocześnie w sposób, który przynosi wymierne korzyści.

Zasady łączenia

Scrum w takim tandemie definiuje proces i jego kluczowe elementy, Kanban dokłada do niego przepis na uzyskanie maksymalnej skuteczności i tym samym optymalizację wartości, jaką Zespół dostarcza interesariuszom. I nie trzeba w tym celu dokonywać żadnych modyfikacji Scruma, a zwłaszcza usuwać Sprintów (bo czasami takie pomysły się pojawiają).

Osobiście uważam, że Scrum i Kanban uzupełniają się wzajemnie do tego stopnia, że nie da się wydusić ze Scruma maksymalnych jego możliwości, jeśli nie sięgnie się w nim po praktyki kanbanowe. Nie dlatego, że Scrum jest ułomny – jest celowo niekompletny właśnie po to, by pozostawić przestrzeń dla Zespołów do użycia takich narzędzi, technik i praktyk, które pozwolą na osiągnięcie wysokiej skuteczności. Strategia optymalizacji przepływu idealnie pasuje w dużą ilość tych pustych miejsc, jakie twórcy Scruma pozostawili we frameworku. Nierozsądnie byłoby przynajmniej nie spróbować z niej skorzystać.

Warto przy tym wspomnieć, że choć zastosowanie Kanbana w Scrumie nie wymaga modyfikacji żadnego elementu tej metody, dążenie do uzyskania przepływu niemal na pewno wpłynie na zmianę sposobu pracy Zespołu. I dobrze, bo przecież nie ma usprawnień i rozwoju bez zmian. Na czym mogą one polegać?

Przede wszystkim na uzupełnieniu Scruma nowymi praktykami lub zmianie podejścia do praktyk już stosowanych. Jednocześnie miary przepływu, nawet jeśli Zespół sięgnie wyłącznie po minimalny ich zestaw, dostarczą dodatkowej informacji, która usprawni przebieg wszystkich zdarzeń metody Scrum i pozwoli na podniesienie przejrzystości stanu spraw. Pomoże w tym również definicja przepływu pracy (ang. definition of workflow) i jej wizualizacja w formie tablicy. To oczywiście tylko kilka przykładów pozytywnego wpływu Kanbana na sposób, w jaki Zespół działa w Scrumie.

Jeśli ktoś ma wątpliwości, czy takie połączenie Scruma z Kanbanem faktycznie jest dopuszczalne i nie wymaga wprowadzenia istotnych zmian w metodzie, powinien sięgnąć do oficjalnego przewodnika po Kanbanie dla Zespołów Scrum.

Kluczowe kwestie na początek

Wspomniany powyżej przewodnik jest zbiorem podstawowych zasad, z którym bezwzględnie należy się zapoznać. Jest on równie lakoniczny co Scrum Guide i bynajmniej nie próbuje odpowiedzieć na wszelkie pytania, jakie mogą zadawać Zespoły Scrum zainteresowane Kanbanem. Powiedziałbym raczej, że wskazuje, czego trzeba się dowiedzieć lub nauczyć, oraz co trzeba zrozumieć, by świadomie posłużyć się tą strategią.

Kilka przykładów rzeczy, nad którymi zastanowić powinien się Zespół:

• Czym jest przepływ (ang. flow) i co świadczy o jego zaistnieniu? Czy jest możliwe, że mimo iż Zespół ciężko nad czymś pracuje, to tego przepływu brak? Jaki przepływ, o ile w ogóle jakiś, ma miejsce w procesie stosowanym aktualnie przez Zespół? A jeśli go brak, to co jest kluczową przyczyną?
• Jak powstaje i dlaczego potrzebny jest do zarządzania przepływem system wciągania pracy (ang. pull system)? I jak sprawdzić, czy faktycznie udało się taki system stworzyć? Co trzeba zrobić, by powstał w tym konkretnym Zespole Scrum?
• Czym są jednostki pracy (ang. work items), których przepływ optymalizowany jest kanbanowo? Co może stać się takimi jednostkami w Kanbanie, którym posłuży się Zespół?
• Co jest częścią WIP-u i czym ten WIP właściwie jest? Dlaczego tak kluczowe jest kontrolowanie jego wielkości? Jak ten WIP kształtuje się w procesie aktualnie stosowanym przez Zespół? Czy aby nie jest zbyt wysoki?
• O co chodzi z prawem Little’a i jakie ma ono zastosowanie w tym konkretnym Zespole? Czy da się zaobserwować efekty jego zadziałania?
• Dlaczego w Kabanie mówi się o stanach przepływu, a nie po prostu o statusie lub postępie wykonywanych prac? Przez jakie stany przepływają jednostki pracy, którymi zamierza posłużyć się Zespół?
• Czym są jawne zasady (ang. explicit policies) w Kanbanie, jakie są ich rodzaje i do czego służą? Jak się zasady takie mają do reguł obowiązujących w Scrumie? Jaki jest ich związek z Definicją Ukończenia Zespołu Scrum? Jakie zasady powinny obowiązywać w Kanbanie tego konkretnego Zespołu?
• Jakie są cztery podstawowe miary przepływu? Czemu właściwie są podstawowymi i jak ustalać ich wartość? Do czego można użyć wiedzy o tych miarach? Jakie są wartości miar przepływu w aktualnie stosowanym procesie i co z nich wynika?
• Czym jest oczekiwany poziom obsługi (ang. service level expectation, w skrócie SLE), jak go ustalić i do czego może być użyty? Jakie mogłoby być początkowe SLE Zespołu Scrum?
• Co to jest definicja przepływu pracy i co się na nią składa? Jak powinna ona wyglądać w tym Zespole Scrum? Co będzie stanowić część workflowu, a co znajdzie się poza nim? Kto zatem będzie częścią systemu Kanban, jaki stworzy Zespół?

Dobrym punktem początkowym może być zapoznanie się po prostu z definicją Kanbana, która wraz z moim obszernym komentarzem dostępna jest na stronie kanbanguide.pl. Można też skorzystać ze wsparcia w postaci opracowanego przez Scrum.org warsztatu Professional Scrum with Kanban.

Od czego zacząć?

A jak zabrać się za praktyczne wprowadzanie Kanbana w Zespole? Wystarczy namalować jakąś tablicę, obwiesić ją karteczkami i ogłosić, że „oto mamy Kanban”? Cóż, nie, to troszkę bardziej skomplikowane.

Krok 1: pozyskanie niezbędnej wiedzy

Na początek trzeba zapoznać się z Kanbanem i przejść przynajmniej przez tę listę pytań, jaką zawarłem powyżej. Oczywiście należy uzyskać dobrą odpowiedź na nie.

Krok 2: definicja jednostek pracy

Zespół musi określić, czym będą jednostki pracy, czyli co ma przepływać przez proces. Jest to o tyle kluczowe, że wpłynie na wszystkie inne elementy definicji workflowu.

Bardzo często Zespoły sięgają tu z rozpędu po zadania, na które dekomponowane są elementy Backlogu Produktu, ale nie jest to dobry wybór. Zadania nie są samodzielnymi nośnikami wartości, bo często trzeba wykonać cały ich szereg, by wykreować cokolwiek przydatnego dla interesariuszy.

Krok 3: początek i koniec przepływu

Gdy już wiadomo, co ma przepływać przez proces, Zespół musi ustalić, co będzie traktowane jako praca w toku (ang. work in progress, w skrócie WIP). Inaczej mówiąc, skąd wiadomo, że praca nad czymś się już rozpoczęła albo że została zakończona.

Bez ustalenia tego nie sposób kontrolować wielkości WIP-u, nie da się też zbierać miar przepływu, bo ich wartości związane są wprost z czasem wciągnięcia danej jednostki pracy do procesu i czasem zakończenia jej realizacji.

Krok 4: monitorowanie miar przepływu

Zanim jeszcze Zespół zacznie posługiwać się Kanbanem, może rozpocząć monitorowanie miar przepływu w takim procesie, jakim posługuje się w tym momencie. Da się to zrobić właściwie od razu po tym, jak ustalone zostanie, co przepływa przez proces i jakie są punkty jego rozpoczęcia oraz zakończenia.

Dobrym pomysłem jest zgromadzenie również historycznych wartości tych miar przynajmniej z ostatnich kilku Sprintów. Pozwoli to na wyciągnięcie pierwszych wniosków i użycie ich do dobrego zdefiniowania zasad w Kanbanie, gdy już zacznie być stosowany.

Krok 5: definicja stanów w przepływie pracy

Stworzenie definicji przepływu pracy wymaga jeszcze kilku rzeczy poza tymi zrealizowanymi już w poprzednich krokach.

Przede wszystkim trzeba określić poszczególne stany, przez które jednostki pracy będą przepływać. Stany te odzwierciedlają postęp w osiąganiu wartości i raczej nie powinny być po prostu listą kolejnych czynności do wykonania. Stan „testowanie” ma zdecydowanie mniej sensu niż stan „potwierdzenie wartości rozwiązania” (albo krócej „walidacja”).

Odradzam tworzenie w procesie stanów w rodzaju „oczekiwanie na…”. Jeśli Zespół faktycznie na coś musi czasami czekać, to uzyskanie tego i zabieganie, by oczekiwanie było jak najkrótsze, powinno być częścią pracy w jakimś innym stanie. A fakt uzyskania tego, na co Zespół czeka, stanowić może jedno z kryteriów przejścia w procesie dalej.

Krok 6: zasady zarządzania przepływem

Zespół musi zdefiniować zasady wciągania nowych jednostek pracy do procesu, kryteria przejścia pomiędzy poszczególnymi stanami w nim oraz zakończenia realizacji.

Tu w sukurs Zespołom Scrum zawsze przyjdzie Definicja Ukończenia, ale niewykluczone, że w pewien sposób rozłoży się ona na więcej niż jeden stan w procesie. W ten sposób w miarę, jak jednostka pracy przechodzi przez takie stany, kolejne wymogi jakościowe zawarte w Definicji Ukończenia zostają zaspokojone.

Często definiowane są również zasady związane ze sposobem wizualizowania różnych istotnych informacji, np. o blokadach i problemach. Warto przy tym zachować umiar przy definiowaniu kolejnych reguł, by ich nadmiar lub złożoność nie doprowadziły do paraliżu decyzyjnego albo łamania ustaleń.

Krok 7: strategia kontrolowania WIP-u

Konieczne jest ustalenie, w jaki sposób kontrolowany będzie WIP i jakiej wielkości nie powinien przekraczać.

Niekoniecznie implikuje to zastosowanie limitów WIP przypisanych do poszczególnych stanów workflowu. Ja wręcz odradzałbym zastosowanie takich limitów, bo będą one na początku wyssane z palca. Lepiej użyć limitu nałożonego globalnie na cały proces albo zasad, które uwzględniają w procesie decyzyjnym nie tylko wielkość WIP-u, ale też jego aktualny wiek (czyli to, jak długo trwają prace nad tym, co już jest realizowane).

Krok 8: uzgodnienie, jakie będzie SLE Zespołu

Oczekiwany poziom obsługi (SLE) to prognozowany czas przepływu jednostek pracy przez proces, do którego Zespół będzie dążył. Zespół musi ustalić go na tyle realistycznie, by SLE faktycznie stało się punktem odniesienia przy podejmowaniu decyzji odnośnie do tego, czy i ile rzeczy wciągnąć do procesu równocześnie.

Pomocne przy ustalaniu początkowej wartości SLE będzie zebranie i przeanalizowanie historycznych danych o przepływie w procesie, jakim posługiwał się dotychczas Zespół.

Warto tu zauważyć, że w Scrumie istnieje domyślne SLE, które można zapisać następująco: 100% rzeczy, jakie podjęte zostaną do realizacji w Sprincie, powinno zostać ukończonych przed zakończeniem iteracji. Ja wciąż jednak namawiam do ustalenia SLE bardziej ambitnego, żeby unikać sytuacji, w której Zespół realizuje wszystko naraz do ostatniego dnia Sprintu. Z przepływem ma to niewiele wspólnego, czyż nie?

Krok 9: aplikacja realizmu i pokory

Zanim Zespół zacznie stosować się do poczynionych ustaleń, powinien upewnić się, że definicja workflowu z jej zasadami oraz samo SLE to nie tzw. pobożne życzenia, ale coś, czego jest w stanie się trzymać. Często takie sprawdzenie skutkuje zracjonalizowaniem definicji przepływu, przez co staje się ona możliwa do stosowania.

Nie chodzi przecież o wytyczanie sobie absurdalnych wymogów, których potem nie uda się spełnić. Nie chodzi też o to, by pomijać cokolwiek, czego wymaga Kanban, uzasadniając to stwierdzeniem, że „u nas się tego nie da zastosować”. Zawsze się da, aczkolwiek nie zawsze Zespołom podoba się to, co taka pragmatyczna definicja workflowu ujawnia – że proces i praktyki, jakimi się posługują, są marne…

No, właśnie: nie ma co się samooszukiwać. Jeśli punkt początkowy jest marny, bo musi być marny, to sensowna definicja workflowu ujawni boleśnie ten fakt. Akurat pod tym względem Kanban jest równie wredny, co Scrum – nie można go z sensem użyć, jednocześnie pozorując, że jest lepiej, niż jest naprawdę.

Nie próbujmy też przy definiowaniu workflowu wyciągnąć się sami z bagna za włosy, dokonując fundamentalnych zmian w nadziei, że uda się je przeprowadzić z dnia na dzień. Jest spore ryzyko, że tylko zaczniemy tonąć szybciej na skutek bezowocnej szamotaniny. Nie oznacza to, że bezwzględnie trzeba zacząć z takim procesem, jaki był stosowany dotychczas, ale rewolucja też nie jest zwykle najlepszą strategią.

Krok 10: współpraca z otoczeniem

O czym zapomina większość Zespołów? By jasno zakomunikować otoczeniu, jak zamierza pracować po wprowadzeniu Kanbana. A najlepiej, by było to połączone z prośbą o wsparcie, feedback, uwagi itd.

To akurat dość uniwersalna rzecz, o którą warto zadbać po sięgnięciu po każdą metodę lub framework: im lepiej ludzie dookoła Zespołu rozumieją sposób jego pracy, tym mniejsze ryzyko, że nieświadomie będą mu rzucać kłody pod nogi, a większe, że zdołają w czymś pomóc.

A potem wystarczy już dbać o przepływ (lub dążyć do jego uzyskania, jeśli na razie nie udało się tego osiągnąć) i monitorować go za pomocą miar i innych narzędzi, które znajdują się w zasięgu Zespołu.

Kiedy łączenie jest niemożliwe?

Nie potrafię wskazać żadnego scenariusza, w którym Zespół Scrum nie mógłby jednocześnie posługiwać się Kanbanem. Kanban jest strategią o wiele bardziej elastyczną niż sam Scrum, której celem jest optymalizacja wartości – czyli coś doskonale zbieżnego z powodami użycia Scruma.

Inaczej mówiąc, nie można odpowiedzialnie twierdzić, że przepływ – szybki i nieustanny postęp prac nad czymś, czego ukończenie przynosi korzyści – jest zbędny w Scrumie. Wręcz przeciwnie: jest pożądany, aczkolwiek niełatwy do uzyskania w wielu Zespołach.

Kompatybilność Scruma z Kanbanem nie działa rzecz jasna w dwie strony. Istnieje szerokie spektrum zastosowania Kanbana w Zespołach, które nie zajmują się rozwojem żadnych produktów lub usług, nawet bardzo szeroko rozumianych, więc nie posługują się Scrumem.

Można wręcz powiedzieć, że o sensowności łączenia Scruma z Kanbanem rozstrzyga w każdym Zespole możliwość posługiwania się przez niego Scrumem. O kryteriach, jakimi można się posłużyć przy podejmowaniu decyzji o użyciu tej metody, piszę w kolejnym artykule.