Blog

Od lat z mniejszym lub większym natężeniem pojawiają się w przestrzeni publicznej nawoływania, by odejść od Scruma i zacząć korzystać z Kanbana, bo dzięki temu będzie lepiej, szybciej, taniej i w ogóle zapanuje powszechna szczęśliwość. Co znamienne, spora część takich nawoływaczy kieruje się w tym przede wszystkim własnym interesem, bo zawodowo zajmuje się „wprowadzaniem Kanbana do organizacji”.

W istocie Kanban podobnie jak Scrum jest narzędziem dającym korzyści tylko tym, którzy potrafią go sensownie użyć. A ktoś taki nie nabierze się na lep wspomnianych nawoływaczy i przed podjęciem decyzji, czy zmieniać sposób pracy, przede wszystkim zapozna się z Kanbanem.

Istnieje sporo materiałów na temat Scruma i Kanbana, które dostarczają rzetelnej wiedzy, ale równie łatwo natrafić na informacje zainfekowane brakiem obiektywizmu, którego przyczyn nie będę tu roztrząsał. Na wszelki wypadek warto podchodzić ostrożnie do wszelkich przekazów, które są zbyt jednostronne lub budują zbyt piękne wizje tego, na co pozwalać ma ten czy inny sposób pracy.

A że uczę ludzi i Zespoły tak Scruma, jak i Kanbana, zebrałem w tym artykule garść przydatnych informacji, które mogą stanowić dobry punkt wyjścia dla chcących dowiedzieć się więcej.

Scrum

To metoda dla pojedynczego Zespołu zajmującego się długotrwałym rozwojem produktu lub usługi w zmiennym i nieprzewidywalnym środowisku. Potrzeby użytkowników tego produktu (a ogólniej: interesariuszy) zmieniają się dynamicznie, więc konieczne jest częste sprawdzanie, czy cel, do jakiego dąży Zespół, jest wciąż aktualny i dynamiczne dostosowywanie planów jego osiągnięcia tak, by uwzględniały bieżący stan spraw.

Rozwój produktu odbywa się w serii krótkich iteracji (w Scrumie nazywanych Sprintami), z których każda ma na celu wykreowanie czegoś, co faktycznie działa i może być użyte z korzyścią dla interesariuszy. Pozwala to empirycznie sprawdzić, czy nowa wersja produktu jest lepsza od wcześniejszej. Zespół może też dużo szybciej odkryć, co jest w ogóle możliwe do zrobienia i jakie założenia będące podstawą podjętych decyzji były błędne.

W Scrumie nie ma miejsca na spekulacje w rodzaju „dobrze idzie, bo x-procent planu udało się wykonać” albo „wydaje nam się, że to będzie dobre rozwiązanie”. Jeśli jakieś rozwiązanie powstało, można wprost sprawdzić poziom jego dopasowania do aktualnych potrzeb interesariuszy i na tej podstawie zdecydować o jego użyciu albo potrzebie wprowadzenia zmian. Jeśli rozwiązania nie udało się zbudować mimo przekonania, że jest ono wykonalne, można ustalić przyczyny i zdecydować, jaką kolejną próbę podjąć i czy w ogóle warto kontynuować.

Empiryczna kontrola procesu, o której tu mowa, ma przy tym jeden zasadniczy cel: dostarczenie interesariuszom korzyści, która uzasadnia koszt utrzymania Zespołu w działaniu. To wymaga kilku rzeczy:

1. Skuteczności w działaniu, czyli zdolności do dostarczenia przez Zespół tego, czego potrzebują interesariusze wtedy, gdy jest im to potrzebne. W kontrze do tego stoi brak skuteczności, którego objawem jest tworzenie niewłaściwych rozwiązań, nienadających się do użycia albo dostarczonych zbyt późno.
2. Nieustannego poszukiwania sposobów na podniesienie skuteczności tak, by Zespół potrafił osiągać stawiane przed nim cele nie na styk, ale również wtedy, gdy zdarzy się coś nieprzewidzianego lub podjęte zostaną błędne decyzje.
3. Eliminowania marnotrawstwa, którym jest zarówno brak efektywności (nieekonomiczne lub niewłaściwe użycie posiadanych środków i możliwości), ale też robienie rzeczy zbędnych, których realizacja nie przynosi korzyści interesariuszom, a zabiera cenny czas.
4. Zaangażowania oraz kompetencji, bez których trzy poprzednie punkty będą nieosiągalne dla Zespołu.

Co więcej, żeby to w ogóle miało jakikolwiek sens, Zespół Scrum musi mieć prawdziwy produkt (może to być też usługa, proces biznesowy itd.), czyli coś, co naprawdę jest komuś potrzebne. Inaczej mówiąc, Scrum nie nadaje się jako metoda pracy dla Zespołów, które robią coś tylko dlatego, że ktoś wciąż za to płaci, a na których efekty pracy nikt nie czeka.

Kanban

To strategia optymalizacji wartości kreowanej przez jakiś proces polegająca na optymalizacji przepływu jej nośników przez ten proces. Brzmi to bardzo skomplikowanie, ale jest w istocie bardzo proste:

• Jeśli zrobienie czegoś przyniesie interesariuszom korzyści, to im szybciej prace zostaną ukończone, tym wcześniej korzyści te się pojawią.
• Prace potrwają najkrócej, jeśli ani na moment nie dojdzie do ich zatrzymania, nie trzeba będzie cofać się i powtarzać wcześniej wykonanych czynności, a każde działanie realizowane będzie z maksymalną efektywnością (bez marnowania środków, możliwości i czasu).
• Im mniej czasu potrzeba na wykonanie pracy nad pojedynczą rzeczą, która przynosi interesariuszom korzyści, tym więcej takich rzeczy uda się zrealizować w jednostce czasu (np. na miesiąc).

Aby maksymalnie zbliżyć się do takiego stabilnego, szybkiego i niezaburzonego przepływu, Zespół musi trzymać w ryzach liczbę rzeczy, nad którymi pracuje równocześnie, by nie przekroczyć swoich możliwości zajmowania się nimi. Stąd wynika kojarzona powszechnie z Kanbanem idea kontrolowania ilości pracy w toku (ang. work in progress, w skrócie WIP). Wbrew mitom, nie chodzi po prostu o zdefiniowanie jakiegoś limitu i bezmyślne jego trzymanie się, ale o faktyczne dbanie, by nie robić za dużo rzeczy naraz.

Proces, który skutecznie chroni się przed zalewem nadmierną ilością pracy, określany jest po angielsku terminem pull system, bo nowe rzeczy do zrobienia wciągane są do niego dopiero wtedy, gdy Zespół oceni, że faktycznie będzie mógł się nimi zająć bez zatrzymania lub spowolnienia realizacji tego, co już wcześniej zaczął robić, a czego jeszcze nie skończył.

Szybki przepływ rzeczy przez proces, w jakim są one realizowane, ma też dodatkową zaletę: redukuje ryzyko, że w trakcie prac dojdzie do ich zatrzymania albo że coś się zmieni i wymusi wykonanie dodatkowych działań. Inaczej mówiąc, dzięki przepływowi, Zespół robi coś na tyle szybko, że jeśli pojawi się jakaś nowa potrzeba, to wynikająca z niej zmiana realizowana jest jako nowa, kolejna rzecz do zrobienia.

Przy czym szybki przepływ nie wynika wyłącznie ze skutecznego kontrolowania liczby rzeczy realizowanych równocześnie. Zespół musi aktywnie zabiegać o jak najszybsze zakończenie prac nad wszystkim, co już zaczął robić, oczywiście przy zachowaniu wymaganego poziomu jakości.

Konieczne jest też nieustanne dostosowywanie procesu, narzędzi, praktyk i samego Zespołu (jego kompetencji) do dynamicznie zmieniającego się środowiska, w jakim funkcjonuje. Optymalizacja wartości poprzez optymalizację przepływu nie jest czymś jednorazowym, ale następuje w sposób ciągły przez cały czas istnienia tego procesu i Zespołu.

Żeby Kanban przyniósł jakiekolwiek korzyści, potrzeba trzech rzeczy:

1. Procesu, który poddawany jest optymalizacji i w którego ramach ma pojawić się i być utrzymywany przepływ. W szczególności wymaga to jasnego zdefiniowania, czym są nośniki wartości w procesie, jak zmienia się ich stan w miarę postępu prac, jakie są kryteria przejścia pomiędzy tymi stanami (co trzeba zrobić, bo kolejny stan osiągnąć) i w jaki sposób kontrolowana będzie ich liczba tak, by powstał wspomniany wcześniej pull system.
2. Zespołu, który odpowiada za sposób działania Kanbana, którym się posługuje, a w związku z tym musi mieć prawo o tym decydować (bo nie ma mowy o odpowiedzialności bez decyzyjności).
3. Monitorowania przepływu w sposób transparentny tak, by Zespół miał faktyczną kontrolę nad pracą w toku i sposobem jej wykonania.

Zwracam uwagę, że Kanban nie jest metodą, czyli nie definiuje żadnego procesu, a jedynie reguły postępowania w ramach procesu, jakim posługuje się Zespół. To oznacza w praktyce, że nie da się „pracować wyłącznie w Kanbanie”, bo nawet wtedy musi istnieć jakiś proces, który poddawany jest optymalizacji.

Podobieństwa

Wbrew powtarzanym przez niedouczonych „propagatorów” Scruma i Kanbana (bo nie brak i jednych i drugich) Scrum i Kanban nie są wykluczającą się alternatywą, bo łączy je bardzo wiele.

Po pierwsze, celem tak Scruma, jak i Kanbana jest uzyskiwanie wartości dla interesariuszy.

Po drugie, Scrum i Kanban w specyficzny dla swoich definicji sposób wymagają od Zespołów, które się nimi posługują, by dążyły do ciągłego eliminowania marnotrawstwa rozumianego w bardzo szeroki sposób. Niepożądana jest przewlekłość działań, niepotrzebne zatrzymywanie prac, robienie rzeczy zbędnych, używanie niewłaściwych narzędzi itd.

Po trzecie, Scrum i Kanban w równym stopniu wymagają od Zespołów ciągłego poszukiwania sposobów na ponoszenie efektywności i skuteczności w działaniu. I co ważne, dzieje się tak z tych samych powodów: aby dostosowywać proces i sposób działania Zespołu do bieżących warunków, w jakich odbywa się praca, dzięki czemu rzadziej dochodzi do losowych problemów wynikających z braku kompetencji lub dostępności ludzi oraz narzędzi, jakimi się posługują.

Po czwarte, choć nie jest to oczywiste, Scrum, podobnie jak Kanban, zmusza Zespoły do ograniczania ilości pracy wykonywanej jednocześnie. Każda iteracja (Sprint) ma taką samą długość, a skład Zespołu w ich trakcie jest stały, co pozwala na realizację jedynie ograniczonej liczby elementów Backlogu Produktu.

I z tego wynika piąte podobieństwo między Scrumem i Kanbanem: konieczność nieustannego dbania o postęp rozpoczętych prac tak, by udało się je ukończyć w możliwie najkrótszym czasie. Jest to jeden z powodów, dla których w Scrumie iteracje nie mogą trwać dłużej niż miesiąc. Zamiast realizować w nieskończoność jedną rzecz, Zespół dokonuje jej dekompozycji na kilka mniejszych problemów, które rozwiązywane są sekwencyjnie, używając pozyskiwanej w ten sposób wiedzy do lepszego radzenia sobie z tym, co pozostało do zrobienia.

Szósta rzecz: i Scrum i Kanban skupiają się na przetwarzaniu nośników wartości. Ani w poprawnie skonstruowanym Backlogu Produktu Zespołu Scrum, ani na prawdziwej tablicy Kanbanowej pojedynczy element nie jest nigdy zadaniem, czyli opisem jakiejś czynności, którą ma wykonać ta czy inna osoba. Takie elementy zawsze definiują problem, którego rozwiązanie przyniesie korzyść interesariuszom. Mogą też być opisami potrzeb, których zaspokojenia interesariusze oczekują. Dzieje się tak, bo rozwiązywanie problemów i zaspokajanie potrzeb przynosi korzyści, a samo wykonywanie zadań może prowadzić donikąd, jeśli zadania te są źle zdefiniowane i skupiają się na rzeczach zbędnych.

A skoro już o tym mowa, to jest i siódma rzecz, a więc miary postępu prac, jakimi posługuje się Scrum i Kanban. Nie bez przyczyny w Kanbanie mówi się o stanach przepływu, które odwzorowane są na tablicy – chodzi o pokazanie, jak zmienia się wraz z upływem czasu kondycja nośnika wartości, a nie to, czy i jakie prace już zostały wykonane. Podobnie rzecz wygląda w Scrumie: liczy się wytworzenie działającego rozwiązania, które może faktycznie być użyte, a nie wykonanie zestawu zadań po to, by postęp realizacji planu wzrósł o kolejnych kilka procent.

Po ósme: ani Scrum, ani Kanban nie służą do zarządzania pracą Zespołów, bo są agnostyczne w stosunku do kwestii organizacyjnych. Nie oznacza to oczywiście, że w fatalnie zarządzanym Zespole Kanban albo Scrum mogą być dobrze użyte. Oznacza to natomiast, że należy dobrać sposób zarządzania Zespołem, który na to dobre użycie pozwoli.

Z tym wiąże się kolejne, dziewiąte podobieństwo między Scrumem a Kanbanem: nie tylko da się je uzupełniać innymi praktykami i metodami, ale wręcz trzeba to robić. Kanban Guide i Scrum Guide nie zawierają wymogu posługiwania się konkretnymi narzędziami, a jeśli definiują praktyki, to ich opis zatrzymuje się na bardzo wysokim poziomie: określenia celu i zasad postępowania, bez wskazania konkretnej implementacji.

I wreszcie po dziesiąte, Scrum i Kanban nie będą dobrze działać w Zespole, który wyzuty jest z zaangażowania, pozbawionym chęci zrobienia czegoś sensownego i niezbędnych do tego kompetencji. Inaczej mówiąc, to nie są magiczne różdżki, którymi wystarczy machnąć, by zbieranina leniwych partaczy przerzucająca rzadkie szambo widłami wykreowała w ten sposób dla kogokolwiek korzyści. Zespół musi mieć sensowny cel i składać się z ludzi, którzy mają ochotę i możliwości ten cel osiągnąć.

Lista podobieństw, jakie wymieniłem, jest zapewne niekompletna, a znajdą się i tacy, którzy z aptekarską dokładnością zaczną wykazywać, że dopatruję się analogii zupełnie niesłusznie. Cóż, każdy ma prawo mieć dowolne poglądy, choć zachęcam do szukania części wspólnych zamiast różnic, bo to pozwala bardziej elastycznie korzystać z różnych narzędzi i dokonywać ich fuzji.

Jakie są różnice?

O różnicach pomiędzy Scrumem i Kanbanem oraz tym, co z tych różnic wynika, napiszę w kolejnym artykule, który ukaże się już wkrótce. Pochylę się również nad twierdzeniem o tym, jakoby nie dało się poprawnie używać Scruma w Zespole, który chciałby jednocześnie posługiwać się Kanbanem.