Blog

Dość często spotykam się z osobami, które z pełnym przekonaniem twierdzą, że Kanban jest metodą nadającą się wyłącznie do prac utrzymaniowych i administracyjnych, zaś do rozwoju nowego produktu (lub modyfikacji już istniejącego produktu) należy obowiązkowo zastosować Scruma.

Z pozoru takie traktowanie obu metod wydaje się trochę usprawiedliwione. Scrum jest prostym frameworkiem do rozwiązywania złożonych problemów, nastawionym „produktowo”; nacisk położony jest na empiryzm, a sposób realizacji celów biznesowych odkrywany jest w trakcie kolejnych iteracji (sprintów). Kanban jest metodą zarządczą, służącą optymalizacji sposobu świadczenia usług (lub przetwarzania zleceń); nacisk kładziony jest na płynność procesu i optymalizację czasu realizacji zadań, brak też wprost nawiązania do iteracyjnego i inkrementalnego rozwoju produktu. Więc niby wszystko się zgadza…

Tu uwaga na marginesie: jeden z poprzednich wpisów „O co Kanban?” prezentuje tą metodę jako alternatywę dla Scruma, który zbyt często traktowany jest jako synonim Agile. Niestety porównując metody zbyt słabo podkreśliłem szerokie spektrum zastosowań Kanbana. Niektórzy czytelnicy mogli uznać, że metoda ta nie nadaje się do niczego poza pracami utrzymaniowymi. Niesłusznie.

Dużo więcej niż tablica

Na początek trzeba rozprawić się z przekonaniem, że stosując tablicę do wizualizacji procesu używa się Kanbana. Takiej tablicy można użyć z powodzeniem w projektach prowadzonych kaskadowo, w RUPie i innych wynalazkach z przeszłości, co wcale nie uczyni ich automatycznie Kanbanem. Wciąż są tym, czym są, a tablica jest jedynie narzędziem wizualizującym ten nienajlepszy proces.

Aby mówić o prawdziwym Kanbanie, należy obok wizualizacji procesu zadbać o optymalizację przepływu: zdefiniować, kontrolować i dostosowywać częstotliwość pobierania nowych zleceń do procesu, limity pracy w toku, głębokości kolejek i wielkości buforów (o ile je stosujemy). Trzeba mierzyć co najmniej cycle time, warto mierzyć lead time i przepustowość (throughput) procesu i dokonywać adaptacji tak, by te dwie pierwsze metryki malały, a druga pozostawała stała lub wzrosła.

Kanban nie wymaga obsadzenia z góry określonych ról, ale metoda przewiduje, że wyłonią się one wraz z rozwojem procesu (Service Request Manager oraz Service Delivery Manager). Nie ma zdarzeń jak w Scrumie, ale wraz z rozwojem procesu powinny pojawić się pętle feedbackowe (feedback loops), zwane też kadencjami (cadences), których może być aż siedem. Podobnie jak Scrum, Kanban oparty jest na wartościach (aż dziewięciu), ma też jasno zdefiniowane zasady. Więcej tutaj: http://leankanban.com/guide/

Maintenance = Kanban?

Cechą prac utrzymaniowych i ogólnie rozumianego maintenance jest brak kontroli nad ilością i charakterem zgłoszeń oraz niemożność swobodnego decydowania, kiedy prace nad nimi będą wykonane. Bardzo często wymagane jest zareagowanie w określonym czasie, zazwyczaj też dokładnie wiadomo, co trzeba zrobić i jedynym problemem jest znalezienie wystarczającego czasu na realizację.

Ponieważ Kanban pozwala na planowanie just-in-time, łatwiej radzić sobie w nim z kolejką zgłoszeń niż w Scrumie, gdzie planowanie jest skwantowane (raz na sprint), i w którym dąży się do ustabilizowania zakresu prac w czasie iteracji. Przy czym warto pamiętać, że dojrzały Kanban, w którym pojawiły się pętle feedbackowe, wymaga ciut więcej planowania, a zgłoszenia nigdy nie są pobierane do procesu w sposób ciągły i w nieograniczonej ilości.

Natomiast prawdziwą przyczyną, dla której Kanban lepiej się sprawdzi w pracach utrzymaniowych niż Scrum jest nacisk tej metody na wspomnianą już optymalizację przepływu. Dlaczego? Bo w mainetnance ważny jest czas reakcji (realizacji zgłoszenia) i najczęściej dokładnie wiadomo, do czego dążymy. Skoro nie ma potrzeby doświadczalnego poszukiwania nowych rozwiązań i możliwości biznesowych, i skoro zależy nam na empirycznym doskonaleniu procesu – Kanban jest najlepszą odpowiedzią.

Czy da się realizować prace utrzymaniowe w Scrumie? Pewnie, że się da, choć niekoniecznie będzie to optymalne rozwiązanie. Ma to sens, jeśli maintenance stanowi uzupełnienie prac rozwojowych nad produktem; w przeciwnym razie może to być nieporozumieniem.

Rozwój produktu = Scrum?

To, że Kanban nadaje się do prac utrzymaniowych wcale nie oznacza, że nadaje się tylko do nich. Metoda stworzona została dokładnie do takich samych celów, jak Scrum: jako prosty framework pozwalający radzić sobie ze złożonymi problemami. Są trzy subtelne różnice między tymi metodami.

Pierwsza różnica: Kanban nie zakłada, że niezbędna będzie „wspólnota pracy”, a więc dopuszcza możliwość, że każdy członek zespołu samodzielnie będzie realizować zadanie, jakiego się podjął, od początku do końca. Przy czym nie jest wcale powiedziane, że w metodzie tej jest to wymagane – bardzo często nad jednym zadaniem pracuje cały zespół, zupełnie jak w Scrumie.

Drugą subtelną, ale bardzo istotną różnicą jest to, że Kanban traktuje rozwój produktu jako jedną z wielu możliwych usług, które przy pomocy tej metody mogą zostać zoptymalizowane i udoskonalone. W tym sensie Kanban jest metodą bardzo elastyczną i łatwiej niż ze Scruma wybrać z niego to, czego potrzebujemy bez ryzyka, że przestanie działać.

Trzecia różnica: Kanban nie wymaga obsadzenia konkretnych ról, wystąpienia z góry określonych zdarzeń czy zmiany istniejących procesów na samym początku (tak, jak to poniekąd czyni Scrum). Pierwszym krokiem jest wizualizacja stanu obecnego, który będzie punktem wyjścia, i z którego ewolucyjnie wyłoni się dzięki usprawnieniom nowy, lepszy proces, nowe role, zdarzenia i wszystko, co okaże się niezbędne.

Kanban do rozwoju produktu

Rozwój produktu z wykorzystaniem Kanbana ma jak najbardziej sens i wiele zespołów robi to z powodzeniem. Scrum nie jest i nie powinien być jedynym rozwiązaniem, wybór metody zależy od potrzeb i możliwości organizacji oraz pracujących w niej ludzi.

Natomiast nie ma się co oszukiwać: aby rozwijać produkt w Kanbanie, dyscyplina i kultura pracy zespołu musi być wysoka. Nie ma przecież narzuconych frameworkiem elementów, które wspierałyby empiryzm na poziomie produktu i samoorganizację zespołu, więc pojawienie się udoskonaleń (procesu, produktu) zależy od dojrzałości zespołu. Ciężej o wspólnotę pracy, developerzy muszą chcieć i rozumieć potrzebę pracy zespołowej. Skupiając się na optymalizacji sposobu pracy i praktykach technicznych można stracić z oczu cele biznesowe. Łatwiej też „zgubić” interesariuszy, bo metoda nie wymaga cyklicznych przeglądów, jak to się dzieje w Scrum.

Wiele dojrzałych zespołów pracujących w Scrumie zaczyna z czasem uwierać planowanie raz na sprint, i często zaczynają to robić just-in-time, aby wreszcie zmigrować do Kanbana. A przynajmniej tak twierdzą i pewnie jest w tym trochę racji. Ja preferuję mówienie, że zespół przekroczył magiczną granicę, za którą zaczyna empirycznie kształtować własny proces, i za którą Scrum i Kanban są już jedynie inspiracją i solidnym fundamentem czegoś zupełnie nowego.