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, natomiast do rozwoju nowego produktu (lub modyfikacji już istniejącego produktu) należy obowiązkowo zastosować Scruma.

Z pozoru wydaje się to usprawiedliwione:

• Scrum jest prostym frameworkiem do rozwiązywania złożonych problemów, nastawionym produktowo; nacisk położony jest na uzyskanie wartości (temu przede wszystkim służy empiryzm), a sposób realizacji celów biznesowych odkrywany jest w trakcie kolejnych iteracji (Sprintów).
• Kanban jest natomiast strategią optymalizacji przepływu pracy przez proces, w którym jest ona wykonywana (na przykład może pomóc w optymalizacji sposobu świadczenia usług lub przetwarzania zleceń); nacisk kładziony jest na płynność procesu i optymalizację wartości poprzez skrócenie czasu realizacji zleceń, brak też wprost nawiązania do iteracyjnego i inkrementalnego rozwoju produktu.

Więc niby wszystko się zgadza…

Tu uwaga na marginesie: jeden z poprzednich artykułów prezentuje tę strategię 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 strategia 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 RUP-ie 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:

• określić, czym będzie praca, jaką realizować będziemy w procesie, by uzyskać wartość, czyli czym są jednostki pracy w procesie (ang. work items),
• zidentyfikować stany w procesie (ang. states) i określić, gdzie praca się rozpoczyna, a gdzie kończy,
• zbudować definicję workflowu oraz jego wizualizację (ang. definition of workflow),
• zidentyfikować jawne reguły (ang. explicit policies), określające:
  • jakie warunki muszą być spełnione, by rozpocząć pracę lub przejść do kolejnego kroku w procesie (ang. pulling policies),
  • co i kiedy będzie traktowane jako priorytet (ang. prioritization policies),
  • w jaki sposób wizualizowane będą różne zdarzenia i informacje istotne dla zarządzania pracą w toku (ang. visualisation policies),
• określić, w jaki sposób kontrolowana będzie ilość pracy w toku (ang. work in progress, w skrócie WIP), choćby poprzez wprowadzenie jawnych jej limitów (ang. WIP limits),
• zdefiniować prognozę spodziewanego czasu ukończenia rozpoczętej pracy (ang. service level expectation),
• aktywnie zarządzać pracą w toku:
  • mierzyć co najmniej czas cyklu dla zleceń (ang. cycle time), przepustowość (ang. throughput), czyli ilość pracy kończonej w jednostce czasu, oraz czas trwania prac nad tym, co aktualnie jest w procesie (ang. work item age),
  • używać tych miar do identyfikacji działań, które zapewnią płynny przebieg procesu i zapobiegają niepotrzebnemu zestarzeniu się pracy w toku,
• regularnie sprawdzać i dostosowywać proces, jego wizualizację, reguły, limity WIP (jeśli zostały zdefiniowane).

Sporo tego, prawda? Sama tablica to zdecydowanie za mało – stanowi jedynie początek. Co ciekawe, Kanban nie stanowi sam w sobie procesu, jest bowiem strategią optymalizacji istniejących procesów. O tym kilka słów później.

Kanban nie wymaga obsadzenia z góry określonych ról, ale mogą się one wyłonić wraz z rozwojem procesu. Nie ma zdarzeń jak w Scrumie, ale wraz z rozwojem procesu prawie na pewno pojawią się w nim pętle zwrotne (ang. feedback loops), zwane też kadencjami (ang. cadences). Podobnie jak Scrum, Kanban ma swoją definicję, z którą zapoznać się można na stronie kanbanguide.pl.

Maintenance = Kanban?

Cechą prac utrzymaniowych (ang. maintenance) jest brak kontroli nad ilością i charakterem otrzymywanych 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 Sprintu odbywa się na początku iteracji, i w którym dąży się do ustabilizowania zakresu prac w czasie Sprintu. Przy czym warto pamiętać, że Kanban też wymaga pętli feedbackowych, 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 tego podejścia na wspomnianą już optymalizację przepływu. Dlaczego? Bo w tego typu pracach 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 – Kanban jest zapewne lepszą odpowiedzią. Zamiast na siłę stosować Scrum, użyjemy Kanbana jako strategii istniejącego procesu obsługi zgłoszeń.

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. Strategia optymalizacji przepływu może przecież posłużyć do osiągania dokładnie do takich samych celów, jak w Scrumie i doprowadzić do powstania prostego frameworku, który pozwoli radzić sobie ze złożonymi problemami. Są trzy subtelne różnice między Scrumem i Kanbanem.

Pierwsza różnica: Kanban nie zakłada, że niezbędna będzie wspólnota pracy, a więc dopuszcza możliwość, że każdy w Zespole 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 (tę praktykę określa się często anglojęzycznym terminem swarming).

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 strategii mogą zostać zoptymalizowane i udoskonalone. W tym sensie Kanban jest bardzo elastyczny – jak już pisałem, nie jest zdefiniowanym procesem, ale strategią optymalizacji procesów, nakładaną na nie po to, by uzyskać jego przepływ (ang. flow).

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 zwykle 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.

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 dokonać „migracji 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. Stąd cudzysłów, gdy pisze o „migracji”.

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 samozarządzanie 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 Sprintu, jak to się dzieje w Scrum. Planowanie just-in-time też może podnieść złożoność środowiska, w jakim budowany jest produkt.

Scrum i Kanban jednocześnie

Przypomnijmy definicję: Kanban to strategia optymalizacji przepływu wartości przez proces jej wytwarzania. Jeśli tak, jeśli nie jest to gotowy do użycia proces, można połączyć go z każdym procesem, który nie stoi w sprzeczności z ideą optymalizacji przepływu. Czyli na dobrą sprawą z każdym procesem, bo ciężko wyobrazić sobie, że ktoś aktywnie dążyłby do tego, by niczego nie kończyć i by praca nie posuwała się do przodu.

A skoro tak, Kanban i Scrum może być używany jednocześnie. Zespół Scrum może zastosować praktyki kanbanowe (a więc Kanbana) do optymalizacji swojego procesu tak, by w Sprintach uzyskać przepływ i podnieść skuteczność swojego działania. Nie musi to oznaczać automatycznego odejścia od Scruma, bo nie ma w Scrumie niczego, co byłoby niezgodne z definicją Kanbana.

Dla porządku dodam, że niektóre Zespoły łączą Scrum i Kanban w ten sposób, że wybierają sobie z obu to, co im pasuje. Znamienne dla tego podejścia jest to, że wybierane są rzeczy łatwe w zastosowaniu, a pomija się te, które w jakiś sposób Zespół uwierają. Najczęściej odrzucane jest to, co ujawnia nieefektywność działania i generowałoby przymus kończenia pracy jak najszybciej. W rezultacie powstaje metoda, która już na pewno nie jest Scrumem (bo brak wymaganych jego elementów), a jeszcze nie jest Kanbanem (bo brak dążenia do jak najszybszego kończenia prac optymalizacji przepływu). Odradzam tę strategię, ale jednocześnie zachęcam do łączenia Scruma (poprawnego) z Kanbanem (też poprawnym).