Czym jest ScrumBan? No cóż, jak sięgniemy do Wikipedii to znajdziemy takie podsumowanie: Scrumban to podejście do dostarczania produktów zgodne z zasadami Agile, które jest hybrydą Scrum i Kanban. Scrumban został pierwotnie zaprojektowany jako sposób na przejście ze Scrum do Kanban. Tak powstał pomysł na wystąpienie na webinarium Dolnośląskiej Grupy Regionalnej IPMA Polska.
Co w artykule:
- Scrum + Kanban = ScrumBan
- Czym dla nas jest ScrumBan?
- Czy u nas można zastosować ScrumBan? Kontekst organizacyjny.
- Czym jest Scrum?
- Czym jest Kanban?
- Porównanie Scruma i Kanbana
- Co daje nam ScrumBan?
Zapraszam do lektury.
Prezentacja z webinaru IPMA Polska, 10.12.2020.
Kiedy rozmawiałem z kolegami z IPMA o tematyce mojego wystąpienia, to w pierwszej kolejności pomyśleliśmy o SAFe, bo to jest temat który moim zdaniem robi wrażenie i jest zabawą dla dużych chłopców. Nie mniej jednak jest to tematyka dość specyficzna i nie każdy z potencjalnych uczestników konferencji i webinarów IPMA zetknął się z tematyką rozwijania dużych produktów i systemów, zwłaszcza w podejściu zwinnym. Wciąż dla wielu project managerów w Polsce tematyka agile w skali, w tym np. SAFe, jest dość abstrakcyjna. Kiedy jednak zacząłem się zastanawiać na temat tego, co z systemu w którym pracuje na co dzień jest przyjemne, pożyteczne i lekkostrawne, to jest fajnym usprawnieniem, to moje myśli szybko skierowały się do naszego specyficznego podejścia do ScrumBana. Na szczęście chłopaki z IPMy dali się przekonać do tego skromniutkiego zagadnienia i zgodzili się na razie zaparkować temat tłustego SAFe’a.
Na wirtualnym spotkaniu Dolnośląskiej Grupy Regionalnej IPMA Polska, które miało miejsce 10.12.2020 podzieliłem się swoimi doświadczeniami z wypracowania własnego podejścia do ScrumBana. Poniżej slajdy z tego webinara, z komentarzem.
Agile jest modny i sexi. Jest też trudniejszy niż mogłoby się to wydawać na pierwszy rzut oka. Łatwo się o nim czyta, dużo trudniej używa na co dzień, zwłaszcza w dużych środowiskach wytwórczych i w pracy przy złożonych rozwiązaniach. Nie jest trudne znalezienie przewodnika po Scrumie i przykładów jego implementacji. Nie stanowi wyzwania uczenie się o Kanbanie. To już praktycznie klasyka. Ze ScrumBanem jest nieco trudniej. Potocznie jest to połączenie Scruma z Kanbanem, w ramach którego czerpiemy z obu metod to, co najlepsze. Niewiele to jednak mówi tym, którzy rozważają wdrożenie tego podejścia. Można też wyczytać, że ScrumBan polega na tym, że używamy Scruma, ale w ramach sprintu monitorujemy postęp realizacji za pomocą tablicy Kanban. Owszem, wielu z nas tak robi (pewnie na przykłąd każdy kto używa Scruma w Jirze), ale czy na tym polega metoda ScrumBan? Nie sądzę.
Przez większość mojego życia zawodowego nie zaprzątałem sobie głowy roztrząsaniem tego, czym jest ScrumBan, używałem albo Scruma albo Kanbana w zależności od charakteru pracy i wyzwań zespołu. Zmieniło się to, kiedy w wielozespołowym środowisku, gdzie na poziomie zespołu używamy Scruma albo Kanbana a na poziomie programu i portfela SAFe’a, parę zespołów zwróciło się do mnie z takim wyzwaniem:
“Niby mamy Scruma, ale nie za bardzo spełniamy jego założenia. Myśleliśmy o Kanbanie, ale on też nie oddaje charakteru naszej pracy. Rozważamy ScrumBana, bo czujemy że czerpiemy po trochę z obu metod, ale nie wiemy tak dokładnie czym on jest i jak go stosować. Co Ty na to?”
Musiałem zatem zastanowić się, co w ekosystemie, w którym ponad trzydzieści zespołów pracuje nad jednym rozwiązaniem mógłby oznaczać ScrumBan. Nie znalazłem przekonujących mnie materiałów, więc po swojemu, we współpracy z zespołami i ich Scrum Masterami, ułożyliśmy czym dla nas może być ScrumBan.
Prezentacja była poprowadzona mocno z perspektywy praktycznego zastosowania. Mało było w niej teorii Scruma, Kanbana i SAFe’a. Skupiłem się na przedstawieniu naszego charakterystycznego podejścia do połączenia Scruma i Kanbana, zdeterminowanego naszym specyficznym środowiskiem wytwórczym.
Posłużyłem się studium przypadku z mojej współpracy z Trans Group S.A. właściciela platformy transportu drogowego https://www.trans.eu/pl/
Liczby, które charakteryzują środowisko omawiane podczas wystąpienia, dające zarys obrazu z jakiej skali produkcją mamy do czynienia, to:
- 30, to liczba zespołów pracujących nad jednym rozwiązaniem, z czego 25 stricte deweloperskich a 5 utrzymaniowych, tudzież rozwijających infrastrukturę,
- 2, to liczba dni potrzebne na przeprowadzenie PI Planningu, czyli SAFe’owego planowania iteracji na poziomie programu (takie powiedzmy kwartalne planowanie rozwoju produktu)
- 160+ oznacza ponad 160 (w porywach do prawie 200) ludzi zaangażowanych w trybie ciągłym w rozwój jednego produktu
Nie jest to jakaś wielka skala, ale jak na jeden dość prosty produkt, to już powoduje pewne komplikacje.
Scaled Agile Framework narzuca pewien sposób funkcjonowania dla grupy ludzi pracujących nad jednym rozwiązaniem (tzw. Agile Release Train na poziomie programu, czy Solution Train na poziomie naprawdę dużych rozwiązań), jednocześnie pozostawiając pewną swobodę wyboru frameworku używanego na poziomie zespołu.
Rysunek przedstawia zrzut z Confluence części planu zespołu na PI; dane zostały zaciągnięte z backlogu zespołu utrzymywanego w Jira.
Oczywiście mimo pewnej swobody w pracy z backlogiem zespołu, naturalne jest że pracując wspólnie nad dużym, złożonym rozwiązaniem pojawiają się zależności organizacyjne, funkcjonalne i technologiczne. Dlatego plan zespołu na daną iterację na poziomie programu (Program Increment) jest bardzo mocno powiązany z planem całego ART (Agile Release Train), a wręcz jest jego subsydiarną częścią. Przejawia się to nie tylko listą zależności, ale też koniecznością zaplanowania prac dla wszystkich zespołów, wchodzących w skład ART, na wszystkie sprinty danego Program Increment (zazwyczaj 5 lub 6 sprintów). Obrazek przedstawiający część planu zespołu na PI jest specjalnie zamazany, żeby nie obnażać zbytnio tajemnic TG S.A.
Podczas realizacji codziennych wyzwań okazuje się jednak czasem, że założenia metody nie do końca zbiegają się z rzeczywistością i wspólne zaplanowanie przez tyle zespołów wszystkich sprintów dla danego Program Incrementu stanowi pewne wyzwanie, a czasem nawet nie jest możliwe.
Wtedy okazać się może, że tradycyjne narzędzie nie mają zastosowanie i coś trzeba zmienić w podejściu. W naszych przypadku było to uregulowanie sposobu pracy zespołu, które nie jest do końca scrumowy, ani kanbanowy, choć przejawia wybrane cechy obu metod.
Na dobrą sprawę stosując strasznego, skomplikowanego i w ogóle potworzastego SAFe’a wykorzystujemy niemal jeden do jednego założenia Scruma, nie modyfikujemy go zbytnio, bardziej dodając pewne aspekty wynikające ze sporej skali rozwoju naszych produktów.
Zamiast naginać Scruma, weryfikujemy w jakich sytuacjach nie jest on zbytnio aplikowalny.
Kanban stosujemy głównie w zespołach utrzymaniowych, których wyzwania są nieco innej natury, a praca jest zgoła inaczej zorganizowana niż w przypadku zespołów deweloperskich.
Przez to nie możemy tak po prostu przyjąć że zespół, który nie może pracować w Scrumie z automatu przechodzi na Kanbana.
Skoro wiemy, że w niektórych przypadkach nie będzie to ani Scrum, ani Kanban, to pozostaje tylko uregulować czym jest hybryda obu podejść, żeby nie kazała się jakimś wyrwanym spod kontroli potworem.
Ze Scruma wzięliśmy zatem te mechanizmy, które pozwalają na zaplanowanie sprintów (zakres i cel) zapewniając posiadania planu bazowego obejmującego nie tylko prace „własne” zespołu a także zależności, ze szczególnym uwzględnieniem deadline’ów (zazwyczaj z dokładnością do sprintu). Z Kanbana pewien komfort pozwalający na nie planowaniu sprintów, tylko dobieraniu Product Backlog Itemów na bieżąco na bazie mocy przerobowych i priorytetów.
Przykładowa implementacja wyglądać może następująco, w krótkich żołnierskich bulletach:
- Zespół patrzy na wymagania przygotowane dla niego do zaplanowania na Program Increment Planningu
- leci wiązanka @^#%&@#^%@&#^%@
- część rzeczy jest lepiej opisana, część gorzej, część udało się zdekomponować a nawet oszacować, ale część będzie jeszcze doprecyzowywana w locie (tak już drzewiej w tym zespole bywało, to trzeba dorobić wymagania, a tu dodać kryteria akceptacji, a tam nie ma co szacować zanim będzie przygotowana makieta… życie)
- większość jednak nie nadaje się do zaplanowania prac na 5 sprintów do przodu
- jak zwykle spora część wymagań stanowi zależności od innych zespołów
- planujemy więc tylko część prac, które wymagają konkretnych dat dostarczenia (bo na przykład wspierają kamienie milowe w projektach biznesowych), chociażby te daty ograniczały się tylko do tego, czy zrobimy daną rzecz w sprincie 3 czy 4, żeby uzależniony od nas zespół wiedział, czy swoją częścią może się zająć w sprincie 4 czy 5
- dla tej zaplanowanej części prac pilnujemy dat
- nie planujemy jednak sprintów dla całej naszej pojemności, tylko dla tych właśnie kluczowych tematów, resztę PBIów (Product Backlog Item) dopieramy w trakcie realizacji sprintów, gdy pojawia się nam na nie przestrzeń, kierując się priorytetami.
Tak ja rozumiem ScrumBana.
Oczywiście nie bawilibyśmy się w ScrumBana jeśli nie przyniosłoby to nam konkretnych korzyści…
Mała rzecz, a cieszy.
