W świecie Agile główne nurty to Scrum i Kanban. Często rozmawiając z kandydatami do pracy pytałem ich: “Jak wygląda sposób pracy w Twoim aktualnym projekcie?”. Częstą odpowiedzią był opis czegoś, co było zaadaptowanym Scrumem z jakimiś dodatkowymi elementami. Oznaczało to dla mnie, że albo zrozumienie Scruma było niedoskonałe, albo wdrożenie metodyki zwinnej do organizacji napotkało jakieś przeszkody.
Do napisania tego artykułu skłoniło mnie pewne zbliżenie pomiędzy oficjalnym Scrumem a Kanbanem na stronach scrum.org, a zwłaszcza artykuł “Scrum with Kanban: It’s time to cross the bridge” z 26 lutego 2018 oraz oficjalny guide “Kanban Guide for Scrum Teams”. Tak, właśnie tak. Na stronach Scrum.org mamy Kanban Guide.
Kanban w Scrumie
Osobiście z takiego zbliżenia jestem zadowolony z dwóch powodów. Pierwszy, to fakt, że coś się dzieje i nie trzymamy się kurczowo Scrum Guide, tylko jesteśmy Agile. Drugi to taki, że adresujemy problemy albo przynajmniej staramy się je zaadresować z przystawaniem Scruma do projektów stricte utrzymaniowych, gdzie zamiast time-boxów mamy ciągły flow i ciągłe dostarczanie.
Jedna rzecz bije jednak po oczach po przeczytaniu “Kanban Guide for Scrum Teams”. W tym przewodniku zaraz na początku mamy odniesienie do “Scrum Guide” wraz z informacją, że absolutnie niniejszy guide go ani nie unieważnia, ani nie zastępuje. Następnie mamy definicję Kanbana oraz wyjaśnienie jak się ma do teorii Scruma. Po przeczytaniu tego mam nieodparte wrażenie, że ktoś na siłę stara się przedstawić Kanban jako podzbiór praktyk Scruma, no bo cały ten workflow oraz tablica to w zasadzie są elementy Scruma, które wspierają inspekcję, adaptację i transparentność. Potem jest już trochę o praktykach kanbanowych, ale to jest mniej istotne w kontekście tego, o czym chcę powiedzieć.
Quo vadis Scrum?
Na lokalnym Agile Community poruszyłem temat, zadając pytanie “Co sądzisz o Kanban Guide for Scrum Teams?”, następnie zaczepiłem jeszcze jedną osobę o której wiem, że ma agile’owy mindset i wniosek był z dyskusji zgoła odmienny. Zdarza się, że to Scrum ewoluuje w kierunku Kanbana. Widać to, jeśli wprowadza się Scruma i jest to dla mnie pewnego rodzaju dowód “ewolucyjno-archeologiczny”. Według mnie Scrum po jakimś czasie swojego życia często przeradza się po prostu w Kanban.
Krok pierwszy. Jeszcze nie Scrum.
Wprowadzamy Scruma do organizacji. Wszyscy się cieszą. Mamy sprinty i daily meetingi. Spotykamy się codziennie, zadajemy wciąż te same pytania. Hurrra! Mamy Scruma! Pierwszy sprint, następnie drugi i kolejny. Dzieli je planowanie. Dokładnie sprawdzamy, czy wszystko mamy wyestymowane, czy nie za dużo wzięliśmy do backlogu sprintu. Czasem potrzebujemy jeszcze dzień lub dwa. Pomiędzy sprintami bywa, że powstają przerwy. Nie mamy jeszcze tej zwinności ani oczekiwanej samoorganizacji. Niemniej jednak działamy. Na końcu deployment trochę czasu zabrał, bo poszło jak po grudzie. Były problemy, coś wybuchło. Tak bywa. Czy dostarczamy większą wartość biznesową szybciej, za mniej, z wyższą jakością rezultatów w zrównoważonym tempie? No właśnie.
Krok drugi. Prawie Scrum, ale…
Jedno z pytań na egzaminie PSM I brzmi: “Kiedy zaczyna się sprint?”. Prawidłowa odpowiedź na nie to: “Natychmiast po zakończeniu sprintu poprzedniego”. Teraz mamy wprawę i idzie nam już sprawnie. Sprint goni za sprintem bez żadnych przerw. Product Owner się angażuje, a Scrum Master facylituje. To już prawie jest Scrum taki jak w Scrum Guide. Najważniejszy w tym wszystkim zespół nabrał doświadczenia i nie tylko rozumie, ale i czuje ten proces i sam potrafi to już pociągnąć, nawet jeśli Scrum Master pójdzie na urlop albo zostawi większą swobodę dla zespołu (zyska większe zaufanie). Oczywiście nadal zdarza się, że coś poszło nie tak. Po prostu przeszło do kolejnego sprintu i tyle. Nadal limit pracy wynika z planowania, proces mamy dosyć dobrze zdefiniowany, a retrospektywa na końcu pomaga nam w ciągłym doskonaleniu.
Krok trzeci. Scrum i co dalej?
Dochodzimy do sytuacji, gdy:
- podczas sprintu zdarzają się dodatkowe releasy,
- jak zwykle dokładane są rzeczy pilne, “bo coś tam”, które przeciągają się na następny sprint. Logiczne, skoro nie było to planowane.
W rezultacie mamy sytuację taką, że część zadań w sprincie rozpoczęła się w poprzednim, ukończy być może w następnym. Deploymenty są częstsze. Jest to moment kiedy Scrum Master może zacząć próbować przeciągnąć zespół w kierunku kroku drugiego, wychodząc z założenia, że Scrum przestaje działać. Chociaż, z drugiej strony, może próbować dalej adaptować się do sytuacji, zmierzając do kroku czwartego. Jest to jakiś pośredni stan, pomiędzy Scrumem a Kanbanem, który możemy określić mianem Scrumban. Iteracje się zlewają, choć nadal mamy stałe ceremonie takie jak retrospektywa czy planowanie. Ale zaczynamy skupiać się nad tym gdzie mamy przestoje, “pull” przeważa nad “push”, a Scrum board, który do tej pory po każdorazowym sprincie był “resetowany” teraz tylko jest może trochę mocniej sprzątany ze starych elementów, ale na końcu sprintu jest wiele rzeczy, które nadal są w trakcie.
Krok czwarty. Już nie Scrum.
Kolejne elementy dodawane są cały czas, cały czas jest też gotowość do deploymentu rzeczy “ukończonych”. Zespół skupia się na optymalizacji swojej pracy, dalszym usuwaniu przeszkód, wyszukiwaniu i eliminowaniu przestojów. Sprinty zlewają się w jeden ciągły i wydajny tok pracy. Zaczyna mieć sens mierzenie nie tyle velocity (prędkość) zespołu, co lead time (czas wytwarzania produktu)1). Mamy przepływ pracy, który maksymalizuje wartość i minimalizuje czas wytwarzania produktu. Jest przewidywalny. Tu pojawia się Kanban.
Scrum-ewolucja!
Zdarza się więc, że Scrum ewoluuje w stronę Kanbana, a nawet się w niego finalnie przeradza. Po prostu w niektórych sytuacjach Kanban sprawdza się lepiej i nie ma w tym nic złego, choć często da się zauważyć nieudolne próby trwania przy Scrumie, a naturalna ewolucja w innym kierunku traktowana jest jako zagrożenie dla procesu. To nawet dobrze, że zespoły, wychodząc z założenia, że Agile to coś więcej niż Scrum, modyfikują Scruma i potrafią wyewoluować w innym kierunku. Dzięki takiej ewolucji, przypomnę, mamy przecież Spotify. Świat projektów zaczyna porzucać sztywne ramy. Dążymy do tego, aby pracować wydajnie, jakkolwiek ten sposób pracy będzie się nazywał. Istotne, aby nie stracić z oczu agile’owej mentalności oraz okazji do zmian na lepsze.
1) Lead Time – czas wytwarzania produktu jest to czas liczony od momentu złożenia zamówienia do chwili, kiedy produkt jest gotowy do odbioru.
