Kanban mnie zawiódł (raz)

Lubię słuchać opowieści, w których pojawia się takie zdanie:

"Scrum nie zadziałał, więc przeszliśmy na kanbana".

Uśmiecham się wtedy szeroko (w duchu 🙂 ) i dopytuję jak to faktycznie wyglądało z tym "Scrum nie zadziałał".

Po wysłuchaniu kilku takich historii, dochodzę do wniosku, że kanban nadal jest w niektórych miejscach traktowany jako 'scrum bez commitmentu na sprint'. Pal licho nawet fakt, że od kilku lat nie ma już słowa 'commitment' w scrum guide! Nie udaje się 'dowozić', zespół jest pod presją (biedny zespół...) bo klient (o zgrozo!) oczekuje regularnie dostarczanych paczek z wartością? Zrezygnujmy ze spotkań, celów i tych niedobrych 'commitment'ów' i przejdźmy na 'kanbana' - pójdzie nam szybciej 😀

Są jednak sytuacje, kiedy kanban może być przydatny - czy to jako suplement scrum'a (o tym napiszę kiedy indziej) czy to jako "samodzielna" implementacja. Dzisiaj zajmiemy się tym drugim przypadkiem - opiszę pewną historię z życia i pokażę w jaki sposób podejście przepływowe (i filozofia 'pull' zamiast 'push') pomogła ograniczyć znacznie lead time w pewnym projekcie. I jednocześnie - dlaczego nie zrobiło to żadnego wrażenia na managemencie 🙂

Trzy lata temu pracowałem w pewnej międzynarodowej firmie telekomunikacyjnej we Wrocławiu. Zmieniłem dopiero co dział i rozpocząłem pracę w dwóch rolach - Scrum Master jednego z zespołów i 'Agile Coach' tegoż działu (gdzie tej drugiej roli raczej wtedy nie rozumiałem :). Zespoły w tym dziale pracowały w "scrumie" i dostarczały część produktu, która co rok (później pół roku) była składana w jeden release. Od czasu do czasu niektóre zespoły wchodziły (na okres do 3 miesięcy) w tak zwany tryb 'maintenance', gdzie ich głównym zadaniem było ograniczenie liczby błędów w systemie przed końcem danego release'u.

Kiedy przyszedłem do swojego zespołu, właśnie rozpoczynał się taki 'tryb' maintenance, który jak się później okazało - trwał właśnie ok. 3 miesiące. Pomyślałem sobie wtedy - super, jest okazja do przetestowania kanbana i pokazania wszystkim (ha!), że jest to świetne narzędzie i w ogóle. Zaczęliśmy stopniowo - od sprawdzenia jak wygląda nasz proces przepływu błędów przez zespół, jak możemy zaadaptować naszą tablicę (czyli podobnie do tego, o czym już pisałem). Kolejnym krokiem było przekonanie managementu (a także 'koordynatorów od błędów' - tak, były takie pozycje w dziale 🙂 do tego, że ograniczenie WIP jest dobre i nie prowadzi to do tego, że ludzie 'się obijają'. Ustaliliśmy, że możemy zacząć eksperyment.

Zespół ustalił sobie limity WIP na naszej tablicy. Szybko odkryliśmy, że ustawienie limitu na 6 (ilość członków zespołu) w KAŻDEJ kolumnie sprawia, że możemy mieć 18 błędów na raz otwartych w zespole - a to trochę mija się z celem :). Koniec końców zdecydowaliśmy się zmniejszyć limity i zobaczyć jak to wpłynie na pracę zespołu - a konkretnie na lead time (od przyjęcia błędu do zespołu do wypuszczenia poprawki 'dalej') i cycle time (od rozpoczęcia pracy nad błędem do 'wypchnięcia' poprawki).

Warunkiem sprzyjającym do przeprowadzenia eksperymentu było też to, że w poprzednim roku zespół także był w trybie 'maintenance' przez 3 miesiące i mogłem także dotrzeć do danych typu lead time i cycle time w tamtym okresie. Co nam się udało osiągnąć dzięki wprowadzeniu kanbanowych zasad i filozofii (oraz budowaniu zespołu, kompetencji i wdrażaniu praktyk inżynierskich 🙂 )? Skrócenie średniego lead time i cycle time dla poprawy błędów:

Jak zmieniła się ilość błędów naprawionych w danym okresie? Nie zmieniła się - być może nawet spadła o kilka procent. Nie zawsze 'system' był w stanie zapewnić stały (równomierny) przypływ nowych błędów do poprawy, a 'przepustowość' zespołu się nie zmieniła.

Czy w takim razie udało mi się przekonać management do tego, że kanban jest świetny i powinniśmy we wszystkich zespołach tak pracować? W skrócie - nie. Nadal słyszałem wypowiedzi w stylu:

"2 błędy na osobę w tym samym czasie jest optymalną ilością - przecież jak jeden jest zablokowany lub czeka się na odpowiedź od testera, to developer może w tym czasie poprawiać drugi, a nie siedzieć bezczynnie".

Moją reakcją było wtedy oczywiście obruszenie i stwierdzenie - nie znacie się 🙂 Nie mogłem zrozumieć dlaczego, mimo przedstawienia twardych dowodów na 'skuteczność' tego podejścia nie zyskałem wsparcia od sponsorów. Teraz jak na to patrzę z perspektywy czasu i dodatkowego doświadczenia to zaczynam rozumieć.
Próbowałem sub-optymalizować jakąś cząstkę całego przepływu wartości - bardzo małą cząstkę. Dla organizacji nie było kluczowe ograniczanie 'lead time' - nie w sytuacji, kiedy wdrożenie poprawek odbywa się raz na pół roku (częściej, jeśli są faktycznie 'krytyczne' problemy). W takiej sytuacji ustawiane były cele ilościowe - np. ile max. błędów może być otwartych na koniec danego release'u. Nie miało znaczenia to, czy poprawki będą dostarczane regularnie w trakcie pracy, czy wszystkie na koniec ostatniego dnia - byleby by były zrobione i był czas na ich 'odpowiednie' (DoD się kłania) przetestowanie. Tak naprawdę to, że skróciliśmy średni lead time poprawy błędów w zespole z 90 dni do 10 nie miało znaczenia, jeśli Time to Market cały czas wynosił min. pół roku. Co więcej - management był właśnie odpowiedzialny za to, aby te cele ilościowe były spełnione - więc optymalizacja lead time i cycle time, którą zaproponowałem, nie adresowała ich najważniejszych potrzeb.

Nie pracuję już w tak dużej organizacji, ale wiem też teraz ciut więcej i rozumiem jak ważne w przypadku przepływu jest spojrzenie na 'cały obrazek' i szukanie wąskich gardeł w całym systemie. Warto też moim zdaniem zwrócić uwagę na to, co mierzymy jako organizacja - jakie wyznaczamy sobie cele. Nieodpowiednie ustawienie tych rzeczy może prowadzić do konfliktu interesów 'niżej' w strukturze organizacji. Jako Scrum Master powinniśmy starać się zrozumieć potrzeby różnych interesariuszy - także managementu. Zaadresowanie tych potrzeb może w znacznym stopniu ułatwić wprowadzanie 'dobrych zmian' później 🙂

Praca z zespołami jest bardzo ważna i jednocześnie nie może być jedynym obszarem zainteresowania Scrum Mastera. Możemy stworzyć najbardziej efektywny zespół na świecie - jednak jeśli nie jest on jedynym elementem 'układanki' - wtedy niekoniecznie przyśpieszymy dostarczanie wartości naszym klientom 🙂