Kanban vs Scrum: szczegółowe porównanie

Wprowadzenie do Kanban i Scrum

Kanban jest metodą optymalizacji i zarządzania procesami, pozwalającą na wizualizację procesów na tablicy Kanban i ciągłe przetwarzanie elementów pracy. Limit prac w toku w każdej fazie procesu pozwala zespołowi na optymalne wykorzystanie swoich mocy realizacyjnych. Innymi słowy: Kanban pomaga optymalizować istniejące procesy za pomocą zbioru zasad.

Kanban ma 2 typy zasad i 6 kluczowych praktyk:

Zasady:

Praktyki:

1. Wizualizacja procesu 
2. Ograniczanie prac w toku 
3. Zarządzanie przepływem 
4. Sprecyzowanie transparentnych zasad procesu 
5. Stworzenie mechanizmów informacji zwrotnych 
6. Doskonalenie we współpracy 

Scrum – w porównaniu do Kanban - to dalece preskryptywny framework. Scrum wymaga szczegółowego i restrykcyjnego planowania, ma też predefiniowane procesy i role.

Scrum oparty jest o 3 następujace filary:

1. Transparentość 
2. Inspekcja 
3. Adaptacja

W Scrum praca dzielona jest na mniejsze zadania, który muszą być ukończone w predefiniowanym przedziale czasu, nazywanym sprintem. Ponadto dodanie nowego elementu pracy podczas sprintu jest niezalecane. Taki nowy element pracy będzie czekał na następny sprint, co zmniejsza możliwości zespołu reagowania na zmianę.

Teraz, gdy znamy podstawowe różnice pomiędzy tymi dwoma podejściami, sięgnijmy nieco głębiej i przyjrzyjmy się podobieństwom i różnicom między rozwiązaniami software’wymi Kanban i Scrum. Czy możemy wręcz powiedzieć: Kanban vs. sprint?

Kanban vs. Scrum – role i odpowiedzialności

Scrum zakłada wprowadzenie lub raczej przypisanie następujących odpowiedzialności:

• Właściciel Produktu 
• Scrum Master 
• Zespół Deweloperski

Właściciel Produktu odpowiedzialny za rejestr produktu (ang. backlog) udziela wskazówek zespołowi. Scrum Master ustala sposób realizacji procesu, a zespół realizuje prace, które zostały uzgodnione podczas planowania sprintu.

Kanban pozwala na zachowanie aktualnej struktury bez dokonywania drastycznych zmian. Istnieją jednak dwie role w Kanban, które można wprowadzić, lecz nie są one w żadnym razie obowiązkowe:

• Menedżer dostarczania usług (ang. Service Delivery Manager) 
• Menedżer zasilania usług (ang. Service Request Manager)

Menedżer dostarczania usług jest odpowiedzialny za zapewnienie, że elementy pracy są płynnie realizowane w procesie, dzięki obserwowaniu tablicy Kanban i wspomaganiu członków zespołu w rozwiązywaniu napotkanych problemów. Osoba w tej roli facylituje ciągłe doskonalenia dotyczące pracy zespołu i proponuje działania doskonalące.

Menedżer zasilania usług jest rolą pomocniczą. Osoba ta jest odpowiedzialna za zarządzanie zasadami dotyczącymi procesów i ich spójność, za doskonalenie ładu projektowego w firmie oraz za ograniczenie różnego typu ryzyk. 

Planowanie w Scrum a planowanie w Kanban

Planowanie w Scrum realizowane jest iteracyjnie na początku każdego sprintu, podczas spotkania dedykowanego temu celowi. W jego trakcie Zespół deweloperski, Właściciel Produktu oraz Scrum Master spotykają się by dokonać podziału historyjek użytkownika na zadania.

Następnie szacują, ile czasu będzie wymagane do ukończenia wszystkich prac z listy. Gdy osiągają porozumienie, zespół zobowiązuje się do ukończenia tych wszystkich uzgodnionych elementów w nadchodzącym sprincie i rozpoczyna nad nimi pracę. Jeśli w trakcie sprintu następuje zmiana priorytetów, aktualnie realizowany sprint może być przerwany, a proces planowania musi zacząć się od początku.

Metoda Kanban wykorzystuje do planowania podejście probabilistyczne, czyli prognozowanie bazujące na danych historycznych dotyczących procesu. Musi ono uwzględniać typy prac, ich wielkość, klasy usług i wiele innych czynników wpływających na samą pracę, a nie tylko te powiązane z realizującym je zespołem.

W Kanban mamy do czynienia z ciągłym przepływem prac. Dlatego też częstą praktyką jest rozszerzenie sekcji „Requested” tablicy Kanban o kolumny mapy drogowej, typu „Ten miesiąc”, „Następny miesiąc”, etc., pozwalające na wizualizację planowanej pracy.

W rezultacie, gdy istnieją moce realizacyjne, zespół wprowadza (stosując zasadę “Pull”) nowy element pracy  do kolumny “W toku”, trzymając się ustalonych priorytetów. Jeśli znany jest średni czas ukończenia elementu pracy oraz liczba elementów pracy dostarczanych przez zespół w ciągu tygodnia, możliwe jest zaplanowanie terminów rozpoczęcia i zakończenia pracy każdego zadania.

Zobowiązanie w Kanban i Scrum

Kanban propaguje tzw. opóźnione zobowiązanie (ang. deferring commitment), tak długo, jak to możliwe. Celem jest zapewnienie zwinności oraz dostarczanie wartości często i we właściwym momencie. Ponieważ limity prac w toku (ang. WIP limits) uniemożliwiają członkom zespołu pracę nad wieloma zadaniami jednocześnie, każdy zobowiązuje się do ukończenia rozpoczętej pracy, przed rozpoczęciem następnej.

W Scrum zobowiązanie dotyczące Sprintu ma formę prognozy. W sytuacji, gdy zespół nie określa precyzyjnie swoich mocy realizacyjnych lub gdy powstają nieprzewidywane problemy, sprint nie kończy się sukcesem lub potrzebne są heroiczne wysiłki członków zespołu w celu ukończenia planowanych prac na czas.

Kluczowe wskaźniki (KPI)

Porównując argumenty za Scrum i za Kanban nie można pominąć kluczowych wskaźników (ang. KPI – Key Performance Indicators), gdyż po dokonaniu wyboru będą one nam stale towarzyszyć.

KPI w Scrum

Scrum ma dwa konkretne wskaźniki, na których należy się skoncentrować:

• Prędkość (ang. Velocity) 
• Planowane moce realizacyjne (ang. Planned capacity)

Prędkość bazuje na rzeczywiście zrealizowanych punktach, będących zwykle średnią wszystkich poprzednich sprintów. Służy ona do zaplanowania liczby elementów rejestru produktu, które zespół powinien ukończyć w następnym sprincie.

Moce realizacyjne określają dostępność zespołu w sprincie. Mogą one być zmienne, przykładowo, gdy członkowie zespołu są na urlopie lub na zwolnieniu lekarskim, etc. Zespół powinien wziąć pod uwagę swoje moce realizacyjne przy określaniu liczby elementów rejestru produktu zaplanowanych do realizacji w sprincie. Jeśli moce realizacyjne dostępne w sprincie będą mniejsze, to zespół powinien rozważyć wzięcie mniejszej liczby elementów rejestru produktu do sprintu. Analogicznie, gdy zwiększona zostanie liczba członków zespołu, to mogą oni wziąć większą liczbę elementów rejestru produktu do realizacji w sprincie.

Scrum do monitorowania stanu prac i omawianych wskaźników wykorzystuje następujące wykresy:

• Wykres wypalania (ang. Burndown chart) 
• Wykres prędkości (ang. Velocity chart)

Wykres wypalania jest wizualnym przedstawieniem pracy pozostałej do ukończenia w stosunku do czasu pozostałego na jej realizację w sprincie.  Natomiast wykres prędkości ma zwykle formę histogramu, pokazującego rezultaty zespołu Scrum w przeszłości.

KPI w Kanban

W Kanban najważniejsze metryki to:

• Czas realizacji (ang. Lead time) 
• Czas wykonania (ang. Cycle time)

Wyjaśniając w zwięzły sposób: czas realizacji to okres od momentu wejścia nowego zadania do procesu do jego wyjścia z tego procesu. Myśl w ten oto sposób: czas realizacji zaczyna być liczony jak tylko zobowiążesz się do pracy nad zadaniem lub zleceniem klienta.

Z drugiej strony czas wykonania zaczyna się w momencie wejścia nowej pracy do fazy „W realizacji”, gdy ktoś zaczyna nad nią pracować.

Celem powinno być zmniejszanie wartości obu tych metryk (mierzonych zwykle w dniach) wraz z upływem czasu i zapewnienie, efektywności procesu przez cały czas. Do monitorowania stanu tych wskaźników wykorzystywane są dwa następujące wykresy:

• Skumulowany diagram przepływu (ang. Cumulative flow diagram (CFD)
• Histogram czasu wykonania (ang. Cycle time histogram)

Diagram CFD pokaże jak stabilny jest przepływ prac i pomoże zrozumieć, gdzie należy skoncentrować wysiłki mające na celu uczynić proces bardziej przewidywalnym. Natomiast histogram czasu wykonania pomaga monitorować funkcjonowanie procesu w czasie.

Spotkania i wydarzenia

Jak wspomnieliśmy wcześniej, spotkania w Kanban są opcjonalne. Jeśli jednak będą one organizowane, to możliwe są ich dwa rodzaje: spotkania na poziomie zespołu i spotkania dotyczące dostarczanych usług i produktów pomagające utrzymać spójną pracę zespołu oraz stabilny przepływ.

• Codzienne spotkania 
• Spotkanie dotyczące zasilania systemu i zobowiązań 
• Spotkanie planistyczne dotyczące dostaw 
• Przegląd dostarczania usług 
• Przegląd operacyjny 
• Przegląd ryzyk 
• Przegląd strategii

Omówienie szczegółów każdego z tych z tych spotkań wykracza poza zakres tego artykułu. Ważne jest natomiast zrozumienie, że te spotkania można łączyć lub pominąć, jeśli nie są potrzebne. My na przykład robimy co tydzień razem przegląd dostarczania usług i spotkanie dotyczące zasilania systemu i zobowiązań. Można więc eksperymentować, jeśli przynosi to korzyść zespołowi.

Każdy Sprint w Scrum obejmuje 4 obowiązkowe spotkania:

• Planowanie sprintu 
• Codzienny Scrum 
• Przegląd sprintu 
• Retrospektywa sprintu

* Doskonalenie rejestru produktu (choć nie jest to oficjalne spotkanie w Scrum Guide, wiele zespołów spotyka się przy końcu ich aktualnego sprintu w celu re-priorytetyzacji i prawidłowego określenia wielkości historyjek użytkownika)

Planowanie sprintu odbywa się na początku każdego sprintu. Jeśli sprint trwa 1 miesiąc, to zdarza się, że to spotkanie może trwać nawet 8 godzin. Następnie, gdy praca została rozdzielona i podjęto zobowiązanie jej ukończenia, zespół spotyka się każdego dnia dla przedyskutowania postępu prac i poinformowania o pojawiających się problemach. Na koniec sprintu zespół i zainteresowani interesariusze spotykają się, by dokonać przeglądu rezultatów sprintu. Ostatnie spotkanie – retrospektywa służy analizie sposobu pracy: co działało w sprincie i co powinno być udoskonalone w trakcie następnego sprintu.

Tablica Kanban vs. Тablica Scrum

Tablice wizualnego zarządzania są stosowane zarówno w Kanban, jak i w Scrum. Istnieją jednak między nimi pewne zasadnicze różnice.

Tablica w Scrum jest rozszerzeniem rejestru produktu. Gdy zespół zobowiąże się do ukończenia określonego zakresu prac, te prace są dodawane do rejestru produktu na tablicy, a następnie zespół umieszcza realizowaną pracę w kolumnie „w realizacji”. Celem jest ukończenie prac – przesunięcie ich do kolumny „Zrobione” przed końcem sprintu. Tablica jest czyszczona po każdym sprincie.

Tablica w Kanban jest natomiast stałą mapą procesu realizowanego przez zespół. Celem budowy takiej tablicy jest stworzenie trwałego systemu Kanban, który sprosta upływowi czasu. Poprawnie zbudowana tablica Kanban wizualizuje ograniczenia prac w toku. Celem jest bowiem kontrolowanie ilości pracy wchodzących do procesu i wychodzących z niego, tak by można było zwiększać tempo realizacji.

Rozwiązania software’owe Kanban vs. Scrum

Tak, jak metoda Kanban, również oprogramowanie Kanban w dużym stopniu opiera się na tablicach Kanban, na których zespoły mapują wszystkie swoje procesy oraz wszystkie elementy prac. Daje to bezprecedensową widzialność realizowanych prac oraz transparentność ich zaawansowania. 

Każdy element pracy staje się kartą na tablicy, której kolumny reprezentują wizualnie fazy prac, a wiersze mogą wizualizować priorytety lub typy prac.

Tablica Scrum

Oprogramowanie stosowane dla Scrum koncentruje się przede wszystkim na interfejsach tekstowych, przekształcających epiki w coś w rodzaju do folderów, zawierających elementy pracy. Ostatnio popularne narzędzia Scrum zaczęły mieć tablice podobne do tablic w oprogramowaniu Kanban, pozwalające na pokazanie faz realizowanych prac oraz samych elementów pracy.

Jednak na tablicy Scrum zespół będzie musiał dodać wszystkie historyjki (elementy pracy) na początku każdego sprintu i utrzymywać listę historyjek nie zmienioną do końca sprintu.

Przykład podstawowej tablicy Scrum

Sprint może być uważany za zakończony sukcesem, tylko wtedy, gdy wszystkie elementy prac są ukończone. Wtedy nowe prace mogą być przeanalizowane i rozpoczęte. Po każdym sprincie przeprowadzana jest retrospektywa, a tablica powinna być zresetowana i przygotowana na następny sprint. Właścicielem takiej tablicy Scrum jest zwykle wielofunkcyjny zespół, posiadający wszystkie kompetencje niezbędne do ukończenia sprintu.

W Scrum ograniczenie prac w toku są predefiniowane dla każdego sprintu, gdyż zespół zobowiązuje się do ukończenia w trakcie sprintu konkretnej liczby zadań. Stąd też ta predefiniowana liczba zadań stanowi limit prac w toku dla zespołu.

Tablica Kanban

Właścicielem tablicy Kanban nie musi być konkretny zespół wielofunkcyjny. Kanban bowiem jest zorientowany na efektywność przepływu.  Ponadto w Kanban limity prac w toku są określana na fazę procesu. Dzięki temu wąskie gardła nie powinny pojawiać się w procesie, a jeśli pojawią się, to mogą być łatwo zidentyfikowane, a działania dotyczące ich eliminacji mogą być podjęte. 

W dobrym oprogramowaniu Kanban, kolumny na tablicy posiadają etykiety opisujące poszczególne etapy procesu, a także limity prac w toku, ograniczające ilość pracy, jaka może znaleźć się w danej fazie.

Przykład podstawowej tablicy Kanban

Ponadto na tablicy Kanban nie ma żadnych restrykcji związanych z czasem (takich jak długość sprintu w narzędziach Scrum), a nowe karty (element pracy) mogą być dodane w dowolnym momencie, o ile pozwala na to limit WIP (określający optymalne moce realizacyjne zespołu. Dlatego też tablica Kanban nie musi być okresowo odnawiana.

Innymi słowy – narzędzia software’owe Kanban bazują i aktywnie wspierają ciągły przepływ. Zaawansowane tablice Kanban pozwalają także na zbieranie danych dotyczących każdego elementu pracy, pojawiającego się na tablicy i ich wykorzystanie do lokalizowania wąskich gardeł, zmniejszenia czasu wykonania, itp. 

Śledzenie i analizowanie prac w toku

Narzędzia software’owe Scrum zawierają rejestr produktu, w którym umieszczone są wszystkie elementy pracy zaplanowane do realizacji w sprincie. Natomiast do śledzenia czy przebieg odbywa się zgodnie z planem w tych narzędziach wykorzystywany jest wykres wypalania.

Jest on podstawowym wskaźnikiem stosowanym w Scrum, pokazującym, ile pracy pozostało do wykonania w projekcie.

Generalnie wykres wypalania może być zastosowany dla dokonania zwięzłego przeglądu stanu zaawansowania prac w stosunku do planu. Jeśli jednak istnieje luka w procesie, to jest ona trudna do zidentyfikowania przy pomocy tego wykresu, gdyż pokazuje on po prostu sumaryczną pracę wszystkich członków zespołu. Jeśli więc w trakcie sprintu pojawią się problemy z realizacją prac, będą one widoczne w postaci zmniejszenia liczby ukończonych prac.

Jednak identyfikacja przyczyn tego spadku jest zadaniem dla zespołu, gdyż większość narzędzi Scrum nie pomaga w określeniu prawdziwej przyczyny tych problemów. 

Oprogramowanie Kanban nie zawiera wykresu wypalania, gdyż w Kanban nie ma predefiniowanego okresu, w którym zadania z rejestru produktu powinny być ukończone.

Zamiast niego elektroniczna tablica Kanban wyposażona jest zwykle w skumulowany diagram przepływu, automatycznie zbierający dane dla każdego zadania wchodzącego do procesu.

Te dane są następnie wykorzystywane do analizy czasu wykonania wszystkich zadań.

W rezultacie skumulowany diagram przepływu może zwizualizować elementy pracy wraz z czasem, jaki spędzają one w poszczególnych fazach procesu. Dzięki temu zespół może natychmiast zauważyć, że konkretna faza zaczyna blokować zadania – im dłużej zadanie pozostaje w danej fazie, tym szersza jest sekcja dotycząca tej fazy na wykresie.

Oznacza to, że możliwe jest zidentyfikowanie tych faz procesu, które są źródłem problemów, a następnie podjęcie odpowiednich działań, a nie tylko uzyskanie informacji, że prace nie idą zgodnie z planem.

Szacowanie pracy

W rozwiązaniach software’owych Scrum, szacowanie jest zasadniczą częścią procesu, realizowaną przez cały zespół zwykle podczas doskonalenia rejestru produktu. Celem jest upewnienie się, że elementy pracy dla następnego sprintu są właściwie zwymiarowane i spriorytetyzowane. Następnie podczas planowania sprintu zespół szacuje swoje moce realizacyjne, by określić nad jakimi zadaniami może zacząć pracować.

Głównym celem procesu szacowania jest określenie wielkości elementu pracy (zwykle z wykorzystaniem ciągu Fibonacciego) oraz określenie, ile tych elementów może zostać ukończonych przez zespół w predefiniowanym odcinku czasu, czyli sprincie.

Oprogramowanie Scrum pozwala na przypisanie liczby punktów do każdej historyjki użytkownika i jej śledzenie.

Proces szacowania jest pracochłonny i często jego wartość jest kwestionowana. Wynika to z tego, że zespoły rzadko są w stanie przewidzieć dokładnie wielkość pracy, którą mogą ukończyć w ramach danego sprintu, a pierwotne oszacowania często okazują się być zupełnie błędne.

W podejściu Kanban rekomendowana jest dekompozycja większych prac na mniejsze zadania. Celem jest tu zachowanie możliwie małej wielkości zadań bez obniżania wartości finalnego produktu. Jest to pomocne podczas realizacji zadań, a ponadto wspiera stały przepływ, który jest bardziej niezawodny niż dostarczanie partiami różnej wielkości.

Zamiast szacowania Kanban propaguje zbieranie danych historycznych dotyczących czasu realizacji, czasu wykonania oraz przepustowości, wykorzystywanych przez profesjonalne oprogramowanie Kanban jako podstawę do prognozowania procesów. Na podstawie tych danych historycznych dotyczących rzeczywistych zadań, zaawansowane analityki Kanban mogą prognozować wielkość pracy, jaka może być ukończona w przyszłości w predefiniowanym czasie.

Moduł analityczny w Kanbanize realizuje na przykład symulację Monte Carlo. Jej wynikiem jest statystycznie poprawna aproksymowana liczba zadań, jaką zespół może ukończyć w określonym czasie Liczba ta jest wynikiem matematycznych obliczeń, wykorzystujących historyczne dane dotyczące pracy zespołu w przeszłości. 

W przeciwieństwie do narzędzi Scrum, oprogramowanie Kanban dostarcza prognoz, bazujących na danych historycznych, a nie na niewiarygodnych założeniach przyjętych przez zespół lub na błędnych oszacowaniach.

Kanban czy Scrum. Kto jest zwycięzcą?

Zarówno Kanban, jak i Scrum zostały stworzone by pomóc zespołom zwiększyć ich efektywność i produktywność.

Wybór jednego z tych podejść to indywidualna decyzja zespołu, gdyż należy pamiętać, że oba rozwiązania są oparte na jakiejś metodzie lub na frameworku.

Oprogramowanie Scrum jest pomocne zespołom, które podjęły decyzję o przeprowadzeniu pełnej transformacji Scrum, obejmującej wprowadzenie praktyk, framework’ów oraz odpowiedzialności (ról). Problem polega na tym, że oprogramowanie Scrum nie pomoże w lepszym szacowaniu pracy, lecz jedynie ułatwi dokumentowanie oszacowań.

Oprogramowanie Kanban, podobnie jak sama metod Kanban, jest znacznie łatwiejsze do wprowadzenia; łatwiej też rozpocząć z nim pracę. Oprogramowanie Kanban nie ma wymagań dotyczących procesu, czy też zmiany struktury zespołu, więc dlatego umożliwia rozpoczęcie z tym co aktualnie jest stosowane i następnie stopniowe doskonalenie systemu pracy.

Oprogramowanie Kanban jest w pewien sposób elastyczniejsze, jest też łatwiej adaptowalne do różnych środowisk. Pomaga też wizualizować i optymalizować procesy bez względu na kontekst.

In Summary

Zarówno Kanban, jak i Scrum mają swoich zwolenników, jak i swoje historie sukcesów. W odniesieniu do oprogramowania główne, istniejące różnice to:

• Oprogramowanie Kanban elastycznie adaptuje się do każdego zespołu, natomiast narzędzia Scrum bazują na sztywnym frameworku.
• Kanban opiera się na ciągłym doskonaleniu, a oprogramowanie Kanban pomaga w ciągłej analizie procesu. Scrum natomiast opiera się na planowaniu tzw. punktów (ang. story point), a oprogramowanie Scrum pomaga jedynie w mierzeniu stopnia dotrzymania oszacowań 
• Oprogramowanie Kanban pozwala ograniczać prace w toku, by zapewnić produktywność zespołu, dzięki zbilansowaniu pracy z możliwościami realizacyjnymi.  Oprogramowanie Scrum nie daje zespołowi możliwości rozpoczęcia nowego zadania lub zmiany kolejki prac po rozpoczęciu sprintu. Pomaga tym samym w koncentracji na bieżącym zadaniu, lecz uniemożliwia adaptacje do mian wykraczających poza ustalony zakres sprintu.