Tocząca się od wielu lat dyskusja, czy lepiej posługiwać się Scrumem, czy jednak sięgnąć po Kanban, jest o tyle bezprzedmiotowa, że są to uzupełniające się narzędzia (pisałem już o tym na przykład w tym artykule).
Tym razem chciałem pomóc tym, którzy zastanawiają się, czy warto inwestować w zdobycie wiedzy o Kanbanie i jego wprowadzenie do procesu, jakim posługuje się Zespół lub organizacja. Albo brak im argumentów, by uzyskać zgodę decydentów na przeprowadzenie takiej zmiany, lub choćby wybrać się na kanbanowe szkolenie.
Powód 1: framework to nie kompletny proces
Scrum to tylko framework, czyli szkielet procesu i trzeba go uzupełniać innymi praktykami. Nie da się używać wyłącznie Scruma. A Kanban jest właśnie dobrym zbiorem praktyk ułatwiających uzyskanie wartości.
Powód 2: efektywny Scrum potrzebuje przepływu
Kanban wprowadza ideę przepływu (ang. flow) i świadomego zarządzania nim, czyli dążenia do tego, aby proces był możliwie szybki, niezaburzony, a także by nie dochodziło w nim do przestojów i marnotrawstwa.
Dokładnie tego samego potrzeba w Scrumie w każdym Sprincie, jeśli Zespół ma mieć szansę z dużym prawdopodobieństwem osiągnąć ustalane Cele kolejnych Sprintów.
Powód 3: wyższa przewidywalność ułatwia realizację Sprintów
Kanban pozwala zwiększyć przewidywalność procesu, ponieważ zarządzanie przepływem wymusza (dzięki praktykom kanbanowym) szybkie reagowanie na to, co może proces zaburzać lub zatrzymywać i daje narzędzia (miary przepływu i ich wizualizacje), które pozwalają na szybsze zauważenie, że coś niedobrego się dzieje.
Sprint w Scrumie również służy ograniczeniu ryzyka i podniesieniu przewidywalności tego, jaki stan produktu zostanie osiągnięty na koniec iteracji. Warto oba te mechanizmy spiąć w jeden.
Powód 4: skupienie wymaga kontrolowania WIP-u
Stworzenie systemu typu wciągania pracy do procesu (ang. pull system) oraz ograniczanie ilości pracy w toku (ang. work in progress, w skrócie WIP) zwiększa skupienie Zespołu na tym, co aktualnie najważniejsze, a jednocześnie redukuje marnowanie czasu i środków na przełączanie się między nadmierną liczbą równolegle wykonywanych zmian w produkcie.
Jest to spójne z wartością Scruma, jaką jest skupienie, ale też z ideą Sprintu. Jego stała długość wymusza ograniczenie liczby elementów Backlogu Produktu, jakie Zespół będzie realizował. Jest to przy tym minimum wymagane dla działania Scruma, a dojrzałe Zespoły powinny ograniczać WIP nie tylko w kontekście całego Sprintu, ale również planując i organizując pracę developerską.
Powód 5: Kanban może być strategią działania w Scrumie
Kanban jest w istocie jedną z możliwych do zastosowania strategii pozwalających osiągnąć to, do czego służy Scrum: zwiększenie szansy na uzyskanie maksymalnych korzyści poprzez szybsze i regularne dostarczanie wartościowych rozwiązań.
Scrum daje pewną mechanikę (np. Backlog Sprintu, Cel Sprintu, zdarzenia scrumowe itd.), Kanban dokłada do tego kolejne praktyki służące temu samemu. Przykładowo, Daily Scrum może być zorganizowany z użyciem tablicy kanbanowej, na której widać co jest robione, jak długo, czy następuje realny postęp prac, jakie są blokady itd.
Powód 6: nie warto samemu wymyślać Kanbana
W praktyce każdy skuteczny Zespół Scrum musi zarządzać przepływem i może albo sam wypracować niezbędne do tego praktyki (wynajdując na nowo koło), albo sięgnąć po to, co już zostało zdefiniowane, od lat ewoluuje i jest w wielu miejscach stosowane.
Powód 7: pomysł, by użyć Kanbana, zawsze się pojawi
Niezależnie od Zespołu, jego aktualnej dojrzałości, produktu, jaki rozwija, wcześniej czy później ktoś w nim postawi pytanie: „a może Kanban byłby dla nas lepszy zamiast Scruma?”. Dobrze, by przynajmniej Scrum Master miał wiedzę, by ich Kanbana nauczyć i pokazać, że to nie alternatywa, ale Scruma.
Powód 8: Kanban to narzędzie dla całej organizacji
Scrum Master musi pracować z otoczeniem Zespołu, przynajmniej po to, by zapewnić temu Zespołowi możliwość efektywnego działania w Scrumie. A to często wymaga, by Zespół nie był rozszarpywany na wszystkie strony koniecznością realizowania ogromnej liczby rzeczy równocześnie, oczywiście wszystkich na wczoraj.
O ile nawet sam Zespół z Kanbana nie musi korzystać, może okazać się, że podejście kanbanowe przyda się do lepszej organizacji pracy nad przygotowaniem Backlogu Produktu, a przynajmniej można sięgnąć po miary przepływu i ich wizualizacje, by lepiej rozumieć, jak ten proces działa i go udoskonalić.
Powód 9: prognozowanie jest łatwiejsze z użyciem miar przepływu
Miary przepływu, a wśród nich przede wszystkim przepustowość (ang. throughput), dają dodatkowe narzędzia prognostyczne, bo choćby na ich podstawie da się zrealizować symulacje Monte Carlo, które są o wiele użyteczniejsze niż prognozowanie wyłącznie na bazie oszacowań lub wyliczania np. średniego velocity.
Powód 10: Kanban ułatwia usprawnianie procesu
Miary przepływu dają większą widoczność tego, jak działa proces, bo są to faktyczne informacje pozwalające analizować, gdzie marnowany jest czas.
Powód 11: tablica kanbanowa pozwala monitorować postęp prac
Wizualizacja procesu (tablica kanbanowa) ułatwia Zespołowi zarządzanie swą pracą, ale też monitorowanie postępów w Sprincie. Nie bez przyczyny większość narzędzi służących Zespołom do utrzymywania Backlogu Sprintu pozwala wyświetlić go właśnie jako tablicę kanbanową – dobrze więc wykorzystywać świadomie jej potencjał.
Powód 12: Definicja Ukończenia może być wbudowana w proces
Jawne zasady w Kanbanie (ang. explicit policies), czyli warunki zmiany stanu w procesie i same te stany, są zazwyczaj odzwierciedleniem większości lub wszystkich zapisów w Definicji Ukończenia, dzięki czemu Zespołom łatwiej dbać o jej spełnienie i staje się ona bardziej jednoznaczna. Nie ma też wątpliwości, czy była przestrzegana i trudniej działać wbrew jej zapisom.
Powód 13: proces skupiony na faktycznym kreowaniu wartości
Konieczność zdefiniowania, co będzie elementem tablicy kanbanowej (co jest tą karteczką, która przepływa przez poszczególne stany w procesie), a więc co ma wartość, a co jest tylko czynnością niezbędną do uzyskania tej wartości, ułatwia usprawnianie procesów tak, by nie generować pozornego postępu. Inaczej mówiąc, sięgnięcie po Kanban w Scrumie automatycznie wywiera presję na Zespół, by nie skupiać się na tzw. przepływie pracy (ang. flow of work), ale zacząć monitorować faktyczny przepływ wartości (ang. flow of value).
Powód 14: Kanban pomaga w zarządzaniu Backlogiem Produktu
Definicja tablicy kanbanowej i workflowu wymaga jawnego określenia, co powinno trafiać do procesu, co jest za duże lub niejasne i kiedy praca nad czymś może się rozpocząć. Pozwala to usprawnić proces pielęgnacji Backlog Produktu (ang. Product Backlog refinement), bo jasne jest, do jakiej kondycji trzeba doprowadzić elementy tego Backlogu, zanim będzie można je podjąć do realizacji w Sprincie.
Powód 15: mniejsze ryzyko nietrafionych optymalizacji procesu
Kanban, a dokładniej dane statystyczne z miar przepływu i ich wizualizacje, pozwalają na szybsze zidentyfikowanie, które elementy Backlogu Produktu sprawiają problem, np. tkwią w procesie zbyt długo lub wręcz go blokują.
Z jednej strony ułatwia to ustalenie, jaki jest bezpieczny rozmiar elementów Backlogu Produktu (czyli kiedy lepiej dzielić elementy na kilka mniejszych). Z drugiej Zespół może dokonywać usprawnień procesów bardziej świadomie i przy mniejszym ryzyku, że dokona tzw. lokalnej optymalizacji – rozwiąże jeden problem, a spowoduje spowolnienie w innej fazie używanego procesu.
Przykładem takiej sytuacji może być przyspieszenie procesu wytwarzania rozwiązań bez jednoczesnego zadbania o możliwości ich testowania, co powoduje, że ta część procesu staje się wąskim gardłem i niweczy efekty poczynionych usprawnień.
Powód 16: mniejsze ryzyko powstania i trwania silosów
Kanban używany świadomie z racji skupieniu na dążeniu całego Zespołu do uzyskaniu przepływu wartości sprzyja eliminowaniu silosów kompetencyjnych i wąskiej specjalizacji Developerów. Jest więc w pełni zbieżny z tym, do czego dążyć powinien Zespół Scrum.
Powód 17: dodatkowe możliwości dla Product Ownera
Z praktyk kanbanowych i powiązanych z nim narzędzi (np. miar przepływu czy ich wizualizacji) skorzystać może też Product Owner, choćby do sporządzania prognoz dat dostarczenia poszczególnych funkcjonalności produktu lub zakresów planowanych wydań.
Powód 18: brak ryzyka, można tylko zyskać
Kanban jest jednym z podstawowych narzędzi, które ułatwiają zapewnienie przejrzystości w procesie. Jednocześnie nie istnieje możliwość, że dołożenie praktyk kanbanowych do jakiegokolwiek procesu nastawionego na generowanie korzyści dla interesariuszy w jakikolwiek sposób zaszkodzi.
Oznacza to, że jeśli nie potwierdzi się buńczuczna teza stawiana w wielu organizacjach, że procesy już są optymalne i nie wymagają usprawnień, Kanban ujawni (niewielkim kosztem), gdzie konieczne są zmiany i ułatwi ich przeprowadzenie.
Warto wiedzieć więcej
Tematyce różnic i podobieństw między Scrumem i Kanbanem poświęciłem osobne teksty, w których opisałem, co łączy Scrum z Kanbanem i czym te dwa narzędzia się różnią. Zachęcam do zapoznania się również z nimi, a zainteresowanych praktycznymi aspektami łączenia Scruma z Kanbanem, zapraszam na szkolenie Professional Scrum with Kanban.
