Blog

Kanban staje się coraz bardziej popularny: wedle State of Agile Report zaledwie 7% organizacji deklarowało posługiwanie się Kanbanem w 2020, a dwa lata później było ich aż 56%. Niezależnie od tego, jak kulawe i wypaczone może być to, co się tam faktycznie dzieje i co nazywają w nich Kanbanem (niekoniecznie słusznie), nie należy ignorować tej statystyki. Pokazuje ona bowiem, że wcześniej czy później każdy zetknie się z Kanbanem i warto się do tego przygotować.

Jednocześnie od lat w firmach króluje Scrum – wspomniany już raport z 2022 donosi, że 87% organizacji deklaruje posługiwanie się tą metodą. Oczywiście nie oznacza to, że te same Zespoły posługują się zarówno Scumem, jak i Kanbanem, ale na pewno dzieje się tak często.

Dlaczego o tym piszę? Bo zauważam zaskakująco niski poziom znajomości Kanbana wśród uczestników szkoleń, jakie prowadzę. Niby każdy coś tam słyszał, a niektórzy nawet deklarują pracę w Kanbanie, ale niemal zawsze głębsza dyskusja ujawnia, że wiedza o tej strategii kończy się na kwestiach bardzo podstawowych i jest mocno wymieszana z różnymi mitami.

Tymczasem, skoro Scrum jest tak często używany, Kanban powinien być podstawowym narzędziem, po jakie sięgną Zespoły, które chcą podnosić swoją skuteczność i efektywność. Inaczej mówiąc, od pewnego momentu bez skutecznego zarządzania przepływem (ang. flow) w Sprincie (a być może i na poziomie zarządzania Backlogiem Produktu) nie da się wydusić ze Scruma więcej. A ciężko zarządzać przepływem skutecznie, jeśli nie ma się pojęcia, na czym to polega. Jasne, można eksperymentować i samemu do tego dojść, ale skoro nie wymyślamy kół, tylko je kupujemy, dlaczegóż mielibyśmy sami wymyślać coś, co dawno już zostało wymyślone?

Z drugiej strony wiele organizacji stosuje Scruma tam, gdzie to nie ma żadnego sensu. Choć może powinienem napisać: narzuca Zespołom Scruma. Dlaczego to robią? Bardzo często z niewiedzy, ale nierzadko z prostej przyczyny: nikt i tak nie potrafiłby tam użyć innego podejścia, bo wszelakiej maści agenci zmiany i coachowie mają w swym przyborniku z narzędziami zaskakująco mało praktyk. Wszak mają uzwinniać organizację, a nie ją kanbanizować czy uleanowić, prawda? Dlatego precz z jakimiś tam wymysłami, ma być Scrum! A najlepiej taki w dużej skali, bo wiadomo – duża firma, to i skala duża, ważne rzeczy itd.

W obu przypadkach ujawnia się słabość przede wszystkim Scrum Masterów, którzy nie posiadają wiedzy o Kanbanie (to jeszcze pół biedy), nie dążą do jej zdobycia (to gorzej), albo wręcz zwalczają wszelkie pomysły sięgnięcia po praktyki kanbanowe (to fatalnie). To ostatnie jest często pochodną obaw, że Zespół porzuci Scruma i automatycznie Scrum Master stanie się zbędny.

Scrum w połączeniu z Kanbanem

Kanban to strategia optymalizacji wartości poprzez optymalizację przepływu nośników tej wartości przez proces, w którym jest ona wytwarzana. Brzmi to skomplikowanie, ale jest proste i jeśli ktokolwiek zada sobie trud zrozumienia tej definicji, bez trudu zauważy: to dobrze pasuje do Scruma. Wszak Zespół Scrum ma uzyskać dla interesariuszy maksimum możliwych do osiągnięcia korzyści (czyli właśnie optimum wartości) i powinien robić to skutecznie (bo tylko wtedy wartość pojawia się we właściwym momencie i może być realnie skonsumowana).

Między bajki należy włożyć przekonanie niedouczonych coachów i propagatorów zwinności, którzy uważają, że Scrum i Kanban się wykluczają. Nie warto słuchać również nawoływań tych, którzy utrzymują, że Scrum jest lepszy od Kanbana lub na odwrót. Jeśli Zespół ma zbudować płot, to młotek wcale nie będzie lepszy od piły – oba narzędzia są niezbędne.

Nie istnieje w mechanice Kanbana nic, co byłoby sprzeczne ze Scrumem, aczkolwiek by to zrozumieć, trzeba… no, właśnie – wiedzieć o Kanbanie coś więcej, niż tylko tyle, że jest tablica i jakieś tam limity WIP. Raz, że limity te wcale nie są wymagane (pisałem o tym niedawno), a dwa, że tablica musi spełniać określone kryteria i być używana w przemyślany sposób, jeśli faktycznie ma w czymkolwiek pomagać. Sama z siebie nie zadziała i cudu nie dokona.

Zmiana metody

Wspomniałem już, że są Scrum Masterzy, którzy wolą trzymać swój Zespół z dala od Kanbana na wszelki wypadek, by nie strzeliło komuś do głowy porzucenie Scruma. Cóż, to najgorszy sposób postępowania, jaki mogą wybrać Scrum Masterzy, bo stanowi skrajne odejście od odpowiedzialności, jaką na siebie wzięli. Scrum Master nie może wpływać na Zespół w ten sposób, by ten robił to, co służyć ma Scrum Masterowi. Ma wpływać na Zespół tak, by rosła jego skuteczność w działaniu i w ten sposób by możliwe stało się wykreowanie większych korzyści dla interesariuszy.

Sięgnięcie po praktyki kanbanowe i ich użycie w Scrumie zawsze zwiększa efektywność Zespołu i jego skuteczność. Może jednak być tak, że Scrum jest niewłaściwym narzędziem i sam fakt korzystania z niego prowadzi do marnowania możliwości. I wtedy, co wydaje się szokować wielu Scrum Masterów, powinni oni pomóc swoim Zespołom w migracji do innej metody. Może to być Metoda Kanban (czyli konkretna propozycja implementacji Kanbana), może być Lean użyty wprost, może w końcu być jakiś własny proces (optymalizowany kanbanowo lub nie), albo nawet klasyczne podejście projektowe, jeśli faktycznie miałoby ono sens w tym konkretnym Zespole i organizacji.

To oznacza, że Scrum Master w ten nowej metodzie powinien przyjąć taką samą odpowiedzialność, jaką miał w Scrumie i nadal pomagać Zespołowi. Najpierw w migracji, a potem dobrym użyciu nowego podejścia. I pal licho, jak się będzie nazywać od tej pory to, co robi. To nie nazwa czyni kogoś Scrum Masterem, ale to, co ten ktoś faktycznie robi i co jest celem podejmowanych przez niego działań.

Powstrzymanie Zespołu od złej decyzji

Z drugiej strony czasami Scrum jest dobrym narzędziem, od którego z jakiegoś powodu Zespół mimo wszystko chce uciec. Choćby dlatego, że ma nadzieję, iż „przejście na Kanban” spowoduje zniknięcie części problemów, z jakimi się teraz boryka. Oczywiście, jeśliby to był faktyczny Kanban (a nie jego pusta skorupa), to wszystkie problemy, jakie utrudniają działanie w Scrumie, zamanifestują się ponownie – choć być może w nieco inny sposób. Inaczej mówiąc, taka ucieczka nie ma żadnego sensu.

I znów ujawnia się tu odpowiedzialność Scrum Mastera: jeśli chce powstrzymać Zespół od niepotrzebnej zmiany, która nic mu nie da, musi mieć jakieś argumenty. W szczególności powinien być w stanie wyjaśnić, jak działa ta nowa metoda, która ma „zbawić świat” i dlaczego jest mało prawdopodobne, że tak się stanie.

Nie byłbym sobą, gdybym nie napisał, że Scrum Master, który naprawdę radzi sobie z wywiązywaniem się z podjętej odpowiedzialności, raczej nie znajdzie się w podobnej sytuacji. Po prostu na tyle wcześnie nauczy Zespół i jego otoczenie, czym jest Scrum i kiedy jest sens go użyć, że nikt nie będzie upierał się, by zmienić metodę. Albo też o wiele wcześniej ta zmiana nastąpi, a Scrum Master będzie być może jednym z jej inicjatorów.

Oczywiście to wszystko odnosi się do sytuacji, w której Scrum Master miał dość czasu, by z Zespołem popracować. Moja cierpka uwaga nie ma więc zastosowania do sytuacji, w której Scrum Master dopiero dołączył do Zespołu, który istnieje już od jakiegoś czasu i właśnie rozważa porzucenie Scruma.

Pomoc dla organizacji

Nie wolno też zapominać, że Scrum Masterzy pracują na rzecz nie tylko swoich Zespołów, ale też organizacji, która je stworzyła. I być może będzie tworzyć kolejne, a wtedy wiedza o różnych metodach, jeśli Scrum Master takową posiada, może się bardzo przydać. Dzięki temu da się zawczasu uniknąć przymuszania ludzi, którzy nie budują żadnego produktu, by posługiwali się Scrumem albo konstruowania Zespołów w ten sposób, że żaden z nich nie będzie w stanie wykreować samodzielnie niczego wartościowego.

Jak pokazuje raport, do którego odniosłem się na początku, jest niemal pewne, że rozważane będą każdorazowo dwa narzędzia: Scrum i Kanban. Dlatego Scrum Master, jeśli chce cokolwiek użytecznego wnieść do dyskusji i zadziałać jako faktyczny servant leader w stosunku do kierownictwa organizacji, powinien poza Scrumem znać również Kanban. Choćby po to, by obalać mity i uzupełniać braki wiedzy decydentów.

Od czego zacząć?

Przede wszystkim od pewnego przewartościowania priorytetów, jeśli skupienie na Scrumie spowodowało utratę z pola widzenia wszystkiego innego. Jasne, Scrum Master musi znać Scruma świetnie, ale musi znać też wiele praktyk (developerskich, związanych z zarządzaniem produktem, komunikacją, budowaniem relacji, coachingiem itd.). Musi też znać dobrze Kanban – co starałem się wyjaśnić w poprzednich akapitach.

Kolejnym krokiem jest sięgnięcie po Kanban Guide (na tej stronie, do której podaję link, jest naprawdę dużo moich komentarzy, które ułatwią zrozumienie, na czym polega optymalizacja przepływu). Następnie warto sięgnąć po literaturę na temat Kanbana lub zapisać się na jakieś warsztaty, gdzie będzie można pogłębić podstawową wiedzę.

A potem trzeba zabrać się za praktykę. Choć niekoniecznie każdy będzie chciał iść aż tak na żywioł, nie mówiąc już o tym, że nie każdy dysponuje stosownymi możliwościami. Więc cierpliwość jest wskazana.

Uwaga!

Kanban jest prosty, ale ta prostota może być zwodnicza (podobnie, jak w przypadku Scruma). Dlatego bardzo łatwo ulec błędowi poznawczemu, jakim jest efekt Dunninga-Krugera i uznać, że już wie się wszystko.

Dobrym pomysłem, by uniknąć tej pułapki, jest zderzenie swej wiedzy i rozumienia Kanbana z innymi osobami, które tej strategii korzystają (np. na szkoleniach czy spotkaniach różnych społeczności). Wspomniany wcześniej Kanban Guide z moimi komentarzami ma między innymi taką właśnie funkcję: dać do myślenia i pokazać, że nie jest to aż tak proste, jak niektórym może się wydawać.

Dlaczego taki jest tytuł artykułu?

Jeśli z jakiegoś (dobrego!) powodu Zespół postanowi odejść od Scruma na rzecz innej metody, w której posłuży się optymalizacją przepływu (a więc Kanbanem), wtedy Scrum Master w zasadzie już nie jest Scrum Masterem. W niektórych organizacjach wciąż będzie wtedy używana taka nazwa odpowiedzialności, inni uprą się, żeby zmienić tytulaturę na Agile Coacha.

Ja jednak mam dwie lepsze propozycje, które są mniej wyświechtane i lepiej oddadzą, czym zajmuje się osoba, wcześniej będąca Scrum Masterem. Jedna z takich nazw to właśnie Kanban Master, czyli mistrz Kanbana. Mistrz rozumiany nie jako pan i władca, ale mentor, nauczyciel i ekspert. A druga moja propozycja to Flow Manager, czyli manager przepływu. I znów nie chodzi tu o managera w rozumieniu kierownika, ale osoby, która ma spowodować, by pojawił się przepływ i był skutecznie optymalizowany.