Kanban i Scrum często traktowane są jako wykluczające się alternatywy, przez co konieczny ma być wybór, której z tych metod użyjemy. W zależności do tego, jak pracuje zespół i co ma do zrobienia, powinniśmy się posłużyć Scrumem albo Kanbanem. A bywają i tacy, którzy uważają, że stosowanie tych metod wynikać powinno z sekwencji: najpierw coś wytwarzamy (Scrumem), a potem utrzymujemy (Kanbanem); ewentualnie zaczynamy z niedojrzałym zespołem w Scrumie (narzucającym sporo reguł), by po pewnym czasie wprowadzić Kanbana (kiedy reguły Scruma zaczną nas ograniczać).

To wszystko niemal prawda, a dokładniej ta trzecia prawda, o której mówił Tischner. I już wyjaśniam, dlaczego tak jest.

Pochodzenie Kanbana

Kanban wywodzi się z Leana, którego początki wiążą się z systemami produkcyjnymi (uwaga, nie „produktowymi”, ale produkcyjnymi – wytwarzaniem różnych dóbr). W ogromnym uproszczeniu, za co pewnie dostanę po głowie od znawców Leana, celem jest eliminacja marnotrawstwa i optymalizacja procesu tak, by optymalizować koszty i sam proces. Optymalizować koszty, niekoniecznie minimalizować – to ma znaczenie, ponieważ nadmierna redukcja kosztów może prowadzić do degradacji jakości i w konsekwencji zaburzenia (albo zatrzymania) procesu.

Marnotrawstwem może być to, co oczywiste (skrawki materiału, użytego do produkcji jakiegoś przedmiotu), ale może nim być również koszt magazynowania części, jakie „czekają na wykorzystanie”, w tym straty spowodowane zamrożeniem kapitału w takich półproduktach. Chodzi o to, żeby robić jak najszybciej to, co jest naprawdę potrzebne, w minimalnej ilości, jakiej tego czegoś potrzebujemy. Aby uzyskać taki efekt, konieczne jest ciągłe usprawnianie procesu, a co za tym idzie jego monitorowanie i wyciąganie wniosków z uzyskiwanych w ten sposób danych.

Tu jako ciekawostkę warto wspomnieć, że Lean ma kuzyna, jakim jest Teoria Ograniczeń. Chętnych odsyłam do książek nieżyjącego już niestety Eliyahu Goldratta.

Wracając do Kanbana: to metoda, która jest hybrydą podejścia Lean z empiryczną kontrolą procesu, będącą podstawą metod zwinnych. Ten empiryzm jest użyty jako mechanizm napędzający ciągłe usprawnianie. Jest więc gwarantem adaptacyjności całego systemu wytwarzania wartości.

W tym sensie więc Kanban jest metodą Agile, podobnie jak Scrum. Przy czym, w odróżnieniu od Scruma, empiryczna kontrola procesu jest w Kanbanie związana z samym procesem (eliminacją marnotrawstwa) i może, ale nie musi być użyta, do poszukiwania odpowiedzi na pytanie „co ma największą wartość”. Scrum natomiast wprost używa empiryzmu na poziomie zarówno procesu (jak przebiega praca), jak i wartości (co jest efektem tej pracy).

Pochodzenie Scruma

Metoda powstała jako odpowiedź na pytanie o to, jak zacząć dostarczać wartościowe rozwiązania problemów biznesowych (lub szerzej: dowolnych problemów złożonych) i wyeliminować ryzyko. Chodzi o ryzyko, jakie niesie podejście tzw. projektowe, w którym kryteria sukcesu ustalane są z góry, a działanie oparte jest o planowanie poczynione na bazie przede wszystkim założeń, często długoterminowych i obciążonych sporym błędem.

Twórcy Scruma zaproponowali, by użyć empiryzmu do rozwoju produktu małymi krokami (inkrementalnie), w krótkich Sprintach (iteracyjnie). To redukuje ryzyko biznesowe – w ciągu miesiąca (lub szybciej) następuje sprawdzenie wartości, więc maksymalna strata to koszy miesiąca pracy zespołu. Daje to też możliwość dostosowania planów i kierunku rozwoju produktu często, co pozwala nadążać za zmianą potrzeb interesariuszy, uwarunkowaniami rynkowymi, ewolucją prawa itd.

Istotą podejścia produktowego zaproponowanego w Scrumie jest skupienie na realizacji tego, co jest niezbędne do osiągnięcia bieżących celów i zaprzestanie prac nad tym, co nie przynosi istotnej wartości. Priorytetem jest przy tym nie tyle płynny proces, ile przede wszystkim optymalizacja efektów działań zespołu pracującego w Scrumie.

W odróżnieniu od Kanbana, który nie wymusza zastosowania empiryzmu do optymalizacji wartości tego, co robi zespół, Scrum wyposażony został nie w jedną, ale aż trzy obowiązkowe pętle zwrotne. Jedna związana jest jak w Kanbanie, z procesem. Druga dotyczy wartości produktu. Trzecia (najciaśniejsza) przebiegu iteracji (Sprintu).

Uważny czytelnik już dostrzega, że Scrum ma wbudowane mechanizmy, które mają eliminować marnotrawstwo (robienie mało wartościowych rzeczy), oraz optymalizujące sposób wytwarzania wartości. Ten związek z Leanem nie jest przypadkowy, więc już choćby z tego powodu dziwić powinny twierdzenia o wzajemnym wykluczaniu się Scruma i Kanbana.

Prawo Little’a

Zgodnie z tym prawem, podstawowym dla Kanbana, średni czas realizacji zleceń (czas wykonania pracy przez zespół) jest wprost proporcjonalny do średniej ilości pracy wykonywanej jednocześnie (ang. work in progress, w skrócie WIP), a odwrotnie proporcjonalny do średniej przepustowości zespołu (jego możliwości). Zwracam uwagę, że to prawo operuje na wartościach średnich, więc niekoniecznie dla każdego zlecenia (pracy do wykonania) będzie w pełni zachowane.

Z prawa Little’a płynie prosty wniosek: przyjmując, że możliwości wytwórcze zespołu ciężko zmienić w krótkim czasie (bo wymaga to często czasochłonnych usprawnień), im więcej zespół robi na raz (WIP), tym dłużej będzie to robił. Jeśli kolejne zlecenia będą przyjmowane, czyli WIP będzie rósł, system przetwarzania tych zleceń utonie pod ilością pracy, która ciągnęła się będzie wtedy w nieskończoność.

Stąd idea, by ograniczyć ilość pracy w toku do takiej ilości, która realnie może być przez zespół wykonywana bez generowania strat i wydłużania czasu realizacji. Kanban wprowadza limity pracy w toku (ang. work in progress limits) właśnie po to, aby zbudować taki system, który zabezpieczony jest przed „utonięciem”. To pozwala uzyskać możliwie niezaburzony i stały przepływ pracy przez system realizacji zleceń. A po ludzku: to pozwala zespołowi wykonywać pracę bez miotania się między dziesiątkami napoczętych tematów, bez kończenia żadnego z nich w rozsądnym czasie.

Limitowanie WIP w Scrumie

Wiele zespołów pracujących w Scrumie wprowadza sobie limity WIP, choć metoda tego nie wymaga (inspirują się przy tym Kanbanem). Natomiast każdy zespół, który posługuje się „czystym” Scrumem i tak limituje ilość pracy w toku. Mechanizmem, który to spowoduje, jest stała długość iteracji (Sprintu): nie można jej zmienić w trakcie, więc konieczne jest ograniczenie ilości pracy, jaką zespół zaplanuje do realizacji w Sprincie. To daje szansę na jej ukończenie w rozsądnym czasie.

Mało tego: skład zespołu w trakcie Sprintu w Scrumie musi być stały, co powoduje, że nie da się „dorzucić” nowej pracy do iteracji o stałej długości wraz z dodatkowymi ludźmi, którzy tę pracę mieliby wykonać.

To niejawne limitowanie WIP ma oczywiście zabezpieczyć system realizacji pracy przed „utonięciem”, ale też ma spowodować, że w krótkim czasie pojawi się produkt (zmiana w produkcie), którą możną będzie poddać ewaluacji pod kątem wartości. Gdyby Sprinty mogły „płynąć” w nieskończoność, szansa na uzyskanie czegoś namacalnego, dającego się zweryfikować i poddać walidacji, byłaby dużo mniejsza.

„Sprinty nas ograniczają…”

Wiele zespołów pracujących w Scrumie decyduje się na porzucenie tej metody ze względu na „uwierające granice Sprintów”. Uważają, że arbitralne przerywanie pracy tylko dlatego, że Sprint powinien się skończyć, jest niepragmatyczne. I postulują, by zacząć pracować w Kanbanie, bo tam takich „sztucznych ograniczeń” nie będzie. Cóż, trafiają kulą w płot.

Jeśli bowiem zespół faktycznie użyje Kanbana i zdefiniuje limity WIP takie, które realnie zabezpieczać będą przed wciąganiem do realizacji za dużej ilości pracy i pomogą utrzymać niskie czasy realizacji, to… zmiana metody nic nie da. W Scrumie niewydolność zespołu objawiała się nieukończeniem prac przed końcem Sprintu, w Kanbanie objawi się rosnącymi czasami realizacji i puchnącą kolejką wejściową: po wyczerpaniu limitów WIP nie będzie można nic zacząć, jeśli czegoś się nie skończy.

Oczywiście wiele zespołów tej migracji dokonuje od Scruma do „Kanbana” (celowy cudzysłów), czyli jakiegoś wykrawka praktyk kanbanowych bez jakichkolwiek sensownych limitów WIP (albo wręcz bez limitów).

Problemem tak naprawdę nigdy nie są granice Sprintów, ale brak umiejętności zespołów, by w rozsądnym czasie ukończyć pracę. Zmiana metody nie rozwiąże tego problemu, zmieni jedynie sposób, w jaki będzie się on manifestował.

„Scrum to metoda produktowa, Kanban służy do wykonywania powtarzalnych prac”

To nieporozumienie wynikające z pochodzenia obu metod i naszego przyzwyczajenia do tego, jak obie metody są stosowane. Nie ma żadnych przeszkód, by przy pomocy Kanbana budować produkt i wiele zespołów to robi. Pewna trudność polegać będzie na tym, że metoda ta nie ma wbudowanych obowiązkowych mechanizmów optymalizacji wartości produktu, więc trzeba będzie samemu o to zadbać. W praktyce zapewne powstanie coś, co bardzo będzie przypominało… Scruma.

Z drugiej strony powtarzalne prace da się wykonywać z użyciem Scruma, choć może okazać się, że niektóre z jego mechanizmów nie będą dawały pełnej wartości. Nie chodzi tu przy tym o charakter prac (czy one są powtarzalne, czy nie), ale raczej o możliwość selekcji pracy, jaką wykonamy. Już wyjaśniam, co mam na myśli.

Jeśli spośród zbioru rzeczy, które potencjalnie można zrobić, wybierane są te, które faktycznie zrobimy (bo przyniosą największą korzyść), to nawet jeśli jest to praca powtarzalna, Scrum będzie miał nadal sens. Ma bowiem zdarzenia, w ramach których ustala się, co robić a czego nie robić, ma też Product Ownera, który podejmuje decyzje odnośnie tego, co i w jakiej kolejności będzie realizowane.

Jeśli natomiast właściwie każde zlecenie trzeba wykonać i jedyne, czym da się żonglować, to kolejność, w jakiej zostaną one wykonane, elementy Scruma zdefiniowane po to, by pomóc w selekcji wartości (i odrzuceniu tego, co mało wartościowe) nie będą potrzebne. Przy czym nadal da się Scruma użyć, nawet jeśli być może Kanban w tym przypadku byłby bardziej naturalnym wyborem.

Wspólnota pracy

Tym, co różni Kanban i Scrum, jest podejście do kwestii wspólnoty pracy zespołu, a dokładniej do tego, czy jest ona potrzebna (i w ogóle może zaistnieć), czy nie. Scrum opiera się o założenie, że do rozwiązania złożonego problemu trzeba połączyć różne kompetencje, a praca jest na tyle złożona i jest jej na tyle dużo, że jedna osoba nie zdoła sama jej wykonać. Tak jest z reguły w przypadku budowania złożonych produktów (np. oprogramowania) i stanowi to drugi powód, dla którego Scrum dobrze do takich zastosowań pasuje.

Kanban wspólnoty pracy nie wymaga, ale jej nie zabrania. Dlatego, jeśli zespół zechce użyć Kanbana do budowania produktu, może nadal robić to z użyciem tej metody, oczywiście wspólnie.

Nie działa to natomiast za dobrze w drugą stronę. Jeśli praca, jaką wykonuje zespół, polega na realizacji zleceń, które trzeba wykonywać jednoosobowo, albo wręcz wymagana jest specjalizacja (wymuszona np. prawem) – wtedy lepiej użyć Kanbana. Właśnie dlatego, że może on funkcjonować bez wspólnoty pracy. Zespół wciąż koordynuje swoje działania, ludzie udzielają sobie pomocy w miarę potrzeb, ale co do zasady pracują niezależnie od siebie.

Przykładem takiego środowiska jest zespół administratorów systemów informatycznych, którzy obsługują zlecenia serwisowe (np. zakładają konta w różnych systemach, instalują oprogramowanie itd.). Wbrew pozorom to nie „powtarzalność zleceń” powoduje, że sensowniej tu użyć Kanbana, ale właśnie brak potrzeby ciągłej pracy zespołowej.

To znacząco różni się od zespołu prawników, który na zlecenie klientów (dużych korporacji) opracowuje umowy handlowe. Prawdopodobnie każdy z członków tego zespołu będzie znał się na innych aspektach prawa, ale ich produkt jest wspólny – żaden z nich sam od początku do końca takiej umowy nie opracuje.

Możliwości planowania iteracji

Czasami mówi się, że Kanban to metoda „do obsługi serwisowej” np. wsparcia klientów czy rozwiązywania błędów. W szczególności rzekomo Scrum nie pozwala pracować z błędami, bo przecież nie da się zaplanować, jakie błędy zostaną zgłoszone. I dlatego trzeba użyć Kanbana, który pozwala planować „na bieżąco”.

Najpierw drobna uwaga: Scrum też pozwala planować w znacznym stopniu „na bieżąco”, bo jedyną rzeczą niezmienną w Sprincie jest Cel Sprintu (powód, dla którego realizowana jest iteracja). Niekoniecznie na początku Sprintu musi być ustalone w detalach co, jak i kiedy zostanie zrobione – wiele takich decyzji podejmuje się już w trakcie iteracji.

Ale faktycznie, jeśli zespół miałby wyłącznie rozwiązywać błędy, to Kanban może być lepszym wyborem, bo jest od Scruma siłą rzeczy bardziej elastyczny. Tyle że to może spowodować wyspecjalizowanie się w naprawianiu marnego produktu, podczas gdy dla organizacji lepiej byłoby doprowadzić ten produkt do stanu, w którym ilość błędów będzie minimalna. A wtedy Scrum, wymuszający skupienie na wartości produktu, może być jednak skuteczniejszą metodą.

Czy niezbędna jest dojrzałość zespołów?

Nie, nie jest. Zarówno Scrum, jak i Kanban mogą być użyte przez całkowicie niedoświadczone zespoły, które dopiero uczyć będą się jak korzystać zarówno z tych metod, jak i innych praktyk. Oczywiście początki będą trudne i warto, by zespoły te dostały solidne wsparcie. I tu, faktycznie, objawia się różnica między Scrumem a Kanbanem.

W Scrumie zdefiniowana została odpowiedzialność Scrum Mastera, który ma obowiązek zadbać o efektywność działania zespołu, a w szczególności ma zapobiegać próbom ukrycia problemów pod dywanem i przejścia nad nimi do porządku dziennego. W Kanbanie nie ma obowiązku definiowania takiej odpowiedzialności przez wskazanie konkretnej osoby, przez co ta odpowiedzialność rozkłada się na cały zespół. Jest niezerowe ryzyko, że nie będzie wtedy realizowana.

Można więc powiedzieć, że to nie dojrzałość, ale zdolność do samodyscypliny zespołów jest kluczowa. Te, które mają problem z dbaniem o swój proces, być może łatwiej poradzą sobie w Scrumie, który „zmusi ich” do wielu rzeczy, bo będą one wynikać wprost z definicji metody. Te bardziej zdyscyplinowane, być może dobrze poradzą sobie w Kanbanie – co znamienne, najpewniej dodając różne praktyki wzorowane na Scrumie, choć przecież niewymagane w Kanbanie.

Scrum suplementowany praktykami kanbanowymi

Domykając klamrę, napiszę o łączeniu obu metod. Istnieje wiele zespołów, które korzystają ze Scruma, ale dołożyły do niego praktyki zaczerpnięte z Kanbana. Przykładem takiej praktyki może być organizacja pracy Developerów z użyciem tablicy kanbanowej, na której zwizualizowany jest proces, zdefiniowane są reguły oraz limity WIP. Innym przykładem jest posługiwanie się miarami przepływu do aktywnego zarządzania pracą w toku, np. codzienne sprawdzanie jak długo już trwa praca nad każdą rozpoczętą zmianą w produkcie (ang. work item age), monitorowanie jaki jest poziom WIP (czy nie przekracza limitów) czy sporządzanie skumulowanego wykresu przepływu (ang. cumulative flow diagram).

Powstał nawet Kanban Guide for Scrum Teams – zachęcam do jego przeczytania. Widać z niego wyraźnie, że nie istnieje żadna sprzeczność między Scrumem a Kanbanem, pod jednym warunkiem: jeśli używamy Scruma i Kanbana jednocześnie, to wciąż powinniśmy działać w pełni zgodnie ze Scrumem.

Czemu o tym piszę? Bo funkcjonuje przekonanie, że to łączenie obu metod może odbyć się na zasadzie wybrania z każdej z nich czegoś, a pominięcia innych kwestii. Co znamienne, prawie zawsze ze Scruma wywalane są wtedy granice Sprintów, a z Kanbana limity WIP (czyli eliminowane są dwa alternatywne mechanizmy zabezpieczające proces przed „utonięciem”). Taki twór jest w istocie czymś mało efektywnym, choć jeśli ktoś chce, może tak pracować – byleby nie nazywał tego ani Scrumem, ani Kanbanem.

Tu uwaga: niektórzy posługują się terminem „Scrumban” na taki wybiórczy zestaw elementów obu metod. To nadużycie, albowiem Scrumban polega na użyciu Scruma (poprawnym, bez pomijania elementów) z wykorzystaniem elementów Kanbana (praktyk kanbanowych). Jest tak dlatego, że połączenie obu metod wymaga działania w zgodzie z ich definicjami, a Scrum nie zawiera elementów opcjonalnych – trzeba używać go „w całości”, albo nie jest to już Scrum (a wtedy taki proces nie mógłby być nazywany Scrumbanem). Professional Scrum with Kanban, do którego definicji link załączyłem powyżej, jest właśnie Scrumbanem.

Zanim wybierzesz metodę

Przede wszystkim nie musisz wybierać – może da się użyć obu na raz? A jeśli już wybierasz, upewnij się, że robisz to świadomie. Dobrze jest znać obie metody i zderzyć z jej wymogami to, co wiemy o pracy, jaką ma wykonywać (albo już wykonuje) zespół.

Co brać pod uwagę?

  • Co jest celem? Optymalizacja wartości? Optymalizacja procesu? Obie te rzeczy?
  • Jak pracuje zespół? Konieczna jest wspólnota pracy? Jak wygląda typowy przebieg realizacji zlecenia, jakie wykonuje zespół?
  • Czy dokonywana jest selekcja tego, co będzie robione, czy nie? Czy można jakoś wpłynąć na to, co zlecane jest zespołowi, czy nie?
  • Czy da się zaplanować choćby krótką iterację? Jak i kto zarządza zleceniami? Ja często zmienia się kolejka tych zleceń?
  • Dla kogo pracuje zespół? Jak potwierdzana jest wartość tej pracy?
  • Jakich zdarzeń w procesie potrzeba, by działał empiryzm? Jakie pętle empiryczne są w ogóle potrzebne? Jak często trzeba dokonywać sprawdzeń i dostosowań?
  • Czym jest marnotrawstwo w rozumieniu tego, co robi zespół? Co jest miarą tego marnotrawstwa? Jakich mechanizmów potrzeba, by marnotrawstwo eliminować?

Mając odpowiedzi na te pytania (i kolejne, które wyłonią się w trakcie), często i tak trzeba po prostu eksperymentować. Prawdopodobnie z różnych perspektyw czasami Scrum a czasami Kanban wyda się lepszym wyborem. Z czymś należy zacząć, pozostawiając sobie otwartą drogę do zmiany metody. Przy czym dokonując takiej zmiany, warto pamiętać o paru kwestiach:

  • Powodem ma być dążenie do uzyskania nowych możliwości, a nie ucieczka od problemu lub chęć uczynienia go niewidocznym.
  • Wyczerpane zostały możliwości rozwiązania jakiegoś problemu w używanej metodzie lub zaczęła ona ograniczać zespół.
  • Migrujemy do innej metody dopiero wtedy, gdy potrafimy bardzo efektywnie użyć aktualnej metody – chyba że ewidentnie jest ona niewłaściwa i zmiana musi być zrobiona pilnie.

Ten ostatni punkt jest kluczowy. Wiele zespołów decyduje się bowiem na „skakanie” między różnymi metodami tak często, że w praktyce potencjału żadnej z nich nie ma szans ani doświadczyć, ani wykorzystać. Tymczasem zmiana ma sens dopiero wtedy, kiedy wiemy, co chcemy osiągnąć i potrafimy realnie ocenić, że aktualnie stosowana metoda na to nie pozwala. Dokonanie takiej oceny możliwe jest tylko na bazie dłuższego doświadczenia, najczęściej po dojściu do limitów możliwości.