Czym jest Scrumban? Nazwa sama w sobie zawiera odpowiedź, z pewnością jest to miks zasad Scrum i Kanban. Pomysł na tyle prosty, że aż genialny – czemu mam tkwić w ograniczeniach Scrum, czy pływać w nieoznaczoności Kanban (np. role w projekcie, czas retrospektyw), jeśli mogę wykorzystać te dwa narzędzia i zbudować trzecie – bardziej przyjazne użytkownikowi i silne jak dwa inne rozwiązania razem wzięte?
Jednak to nie mariaż dwóch metodyk był głównym bodźcem, który stworzył Scrumban. Corey Ladas w swojej książce Scrumban twierdzi, że bodźcem była chęć odpowiedzi na pytanie, co by się stało, gdyby zespół Scrumowy zaczął korzystać z dobrodziejstw Kanban przy jednoczesnym rozluźnieniu scrumowskich zasad niezmienności (zamknięte sprinty, timebox, przegląd kodu, retrospekcja itp.).
Osobiście nie patrzę na Scrumban, jako mix rozwiązań Agile i Lean, ale jak na zmodyfikowany proces podobny do Scrum z nałożoną warstwą Kanban. Kogoś może to zdziwić, przecież Scrum i Kanban zazwyczaj traktowane są jak przeciwległe bieguny. Twierdzę jednak, że Scrum nie wyklucza stosowania Kanban.
Definicja Scrum jest precyzyjna, wystarczy odnieść się do Scrum Guide, mamy tu pojęcia lekkości, łatwości zrozumienia, zespoły scrumowe, role, zdarzenia, artefakty i reguły, a same ramy opierają się na trzech filarach:
- Przejrzystości – proces musi być zrozumiały dla wszystkich zaangażowanych
- Inspekcji – scrumowe artefakty muszą być często przeglądane celem wykrycia niepożądanych rozbieżności
- Adaptacji – w momencie zauważenia rozbieżności, proces musi zostać natychmiast skorygowany.
Kanban natomiast jest zestawem praktyk do ulepszania procesu/produktu. Ma mniej obwarowań i zasad w porównaniu do Scrum i nie wyklucza używania procesów opartych o Scrum czy inne bardziej lub mniej zwinne metodyki. Tak jak pisałem wcześniej, Kanban jest dodatkową warstwą istniejącego procesu. Definicja Kanban jest mniej precyzyjna, ale bazując na książce Kanban (Anderson, 2007) oraz publikacjach w sieci można wyróżnić kilka cech:
- Wizualizuj
- Ograniczaj ilość zadań w toku (WIP, work in progress)
- Zarządzaj przepływem
- Twórz jasne polityki procesów
- Wdrażaj mechanizmy opinii
- Ulepszaj wspólnie z zespołem
- Rozwijaj doświadczalnie (modele i metody naukowe)
Można je zwinąć do trzech głównych pojęć: wizualizuj, ograniczaj ilość zadań w toku, poprawiaj. Mając te założenia w głowie, mogę odnieść się teraz do Scrum i nałożyć na niego płaszcz Kanban: jeśli swój proces Scrum postrzegasz jako przepływ, stosując adaptację modyfikujesz proces, by był bardziej dojrzały, i masz jasne reguły ograniczenia np. zadań w sprincie (choćby założenie Scrum, ograniczenia pracy w sprincie tak, aby była wykonalna przez Zespół) stosujesz Kanban.
Przykład: w trakcie wytwarzania oprogramowania w duchu Scrum, zauważasz, że jeśli rozdzielisz spotkania retrospektywne od przeglądów zdecydowanie usprawnisz ten proces. Kanban powiedziałby – rób tę zmianę, Scrum powiedziałby – w porządku, rób tą zmianę, ale nie jesteś już Scrum.
Docieram tu do sedna istoty, potwierdzającej moje stanowisko dot. Scrumban. Scrumban jest procesem, który został ulepszony wykorzystując ramy Kanban, przez co, najprawdopodobniej przestał być stricte Scrum.
Scrum kontra Kanban kontra Scrumban
ITERACJE
Scrum – timebox, ściśle zdefiniowane czasowo, nieprzekraczalne okresy zwane Sprintami.
Kanban – brak zdefiniowanych iteracji, proces jest ciągły.
Scrumban – połączenie dwóch podejść. Proces ciągły, w obrębie którego jest miejsce na krótkie okresy planowania i długie cykle wytwarzania produktu.
PROCEDURY PRACY
Scrum, Kanban i Scrumban są metodykami zwinnymi, w związku z czym wykorzystują metodę pull (czasami Scrum określany jest jako push). Oznacza to, iż członek zespołu przydziela sobie sam zadania. W Scrum przydział zadań odbywa się na początku Sprintu.
Kanban i Scrumban wykorzystują technikę późnego wiązania – zadania pobierane jest na bieżąco przez członka zespołu po wykonaniu przydzielonej mu pracy.
ZAKRES
Pojęcie to definiuje, w jaki sposób ograniczane jest obciążenie pracą.
W Scrum ilość pracy ograniczana jest poprzez zobowiązanie Zespołu do wykonania konkretnej ilości zadań w Sprincie. Zespół w Kanban i Scrumban nie mając z góry nałożonego, stałego zaangażowania ogranicza ilość zadań nakładając na kolumny limity WIP (work in progress) na tablicy zadań. Cały zabieg polega na przesuwaniu zadań zawsze z lewej strony w kierunku prawej (TODO -> IN PROGRESS -> DONE). Jeśli w kolumnie znajduje się za dużo zadań, Zespół może kończyć zadania, które będą miały bardzo słabą, jakość. Aby temu zapobiec, Zespół nakłada sobie limity na ilość zadań, które mogą znaleźć się w danej kolumnie. Jeśli liczba zadań kiedykolwiek przekroczy limit, cały zespół pomaga zredukować ilość zadań w tej kolumnie (rój). Swarming obejmuje każdego członka zespołu, bez oglądania się na role funkcyjne przez nich pełnione.
PLANOWANIE
Pojęcie definiuje, w jaki sposób planowana jest praca w trakcie procesu.
W Scrum zadania do pracy wyciągane są podczas rozpoczęcia każdego sprintu. Planowanie jest regularne.
Kanban i Scrumban nie definiują częstotliwości spotkań. Zakłada się, że organizowane są one wtedy, kiedy zachodzi potrzeba (np. wyczyszczenie backlogu).
OSZACOWANIE
Proces oszacowania czasu potrzebnego do zakończenia zadania.
Czas potrzebny na wykonanie zadania w Scrum określany jest zazwyczaj jeszcze przed startem Sprintu. Suma czasu potrzebnego na zakończenie wszystkich czynności w Sprincie, nie może przekroczyć z góry zdefiniowanego czasu Sprintu. Jeśli taka sytuacja ma miejsce, zadania dzielone są na mniejsze.
W Kanban i Scrumban szacowanie jest opcjonalne. W Scrumban powinno się mieć wszystkie zadania podobnej wielkości. Jednak nie jest to wymagane.
NOWE WYMAGANIA i ZMIANY
Scrum kategorycznie zabrania dodawania nowych wymagań do trwającego Sprintu. W momencie pojawiania się nowego wymagania, musi ono poczekać na decyzję do czasu Planowania Sprintu.
Kanban i Scrumban traktują ten istotny i nieunikniony fakt dość łagodniej – nowe pozycje mogą być dodane zawsze, o ile w kolejce zadań istnieje wolne miejsce (patrz WIP).
WSKAŹNIKI WYDAJNOŚCI
Wskaźniki wydajności są bardzo przydatne, często niestety nadużywane przez kierowników i stakeholderów. Najczęściej jest to chęć sprowadzenia złożonego problemu, jakim jest stan projektu, do prostej, nienaturalnej, jednowymiarowej liczby.
Takim wskaźnikiem w Scrum jest średnia prędkość Zespołu. Wartość ta często zmienia się pomiędzy sprintami, niepokojąc Stakeholderów. Kluczowym wskaźnikiem wydajności jest Spalanie (Burn-down), które pokazuje ile pracy pozostaje do wykonania w obrębie Sprintu.
Zamiast średniej prędkości i spalania, Scrumban wykorzystuje znacznie lepsze narzędzie – czas cyklu. Jest to czas, który wymagany jest, aby zakończyć zadanie. Pomiar rozpoczyna się w momencie rozpoczęcia pracy nad tym zadaniem. Wraz z upływem czasu, wykorzystując analizę statystyczną możliwe jest wyliczenie średniego czasu cyklu oraz odchylenie standardowe. Jest to wyśmienity, lepszy wskaźnik planowania w skali makro, łatwy do użycia (wystarczy zsumować wszystkie historyjki w backlogu i podzielić przez odchylenie standardowe).
ROLE
Scrum definiuje role: Product Ownera, Scrum Mastera i Zespół. Product Owner jest odpowiedzialny za wizję projektu, priorytetyzację, to on podejmuje decyzję dot., które elementy lub historyjki są najważniejsze do skończenia w sprincie. Scrum Master jest strażnikiem procesu Scrum, Zespół buduje produkt.
Kanban nie definiuje ról.
Scrumban, podobnie jak Kanban, nie ma jasno zdefiniowanych ról – role mogą być stworzone na potrzeby projektu, bądź w ogóle może ich nie być.
ZESPÓŁ
W Scrum członkowie zespołu powinni być międzyfunkcjonalni – innymi słowy, zespół musi posiadać umiejętności potrzebne do wytworzenia produktu. Z racji tego, że Scrum jest ograniczoną w czasie metodyką, scrumowi deweloperzy często pracują nad kilkoma zróżnicowanymi zadaniami, aby można było zakończyć sprint w czasie. Kanban woli, aby pracownicy byli wyspecjalizowani. Ponieważ praca ograniczana jest jedynie poprzez wskaźnik WIP (work in progress), developer mający zadania w backlogu może rozpocząć pracę nad kolejnym zadaniem, gdy tylko skończy pracę nad obecnym.
Scrumban: pracownicy mogą być międzyfunkcyjni bądź wyspecjalizowani.
PRAWO WŁAŚNOŚCI
Projekt w Scrum jest zorientowany na Zespół i w związku z tym właścicielem projektu jest również Zespół.
Scrumban, podobnie jak Kanban, nie przydziela całego projektu do jednego zespołu. Przykładowo, w różnych fazach wytwarzania oprogramowania proces może zmieniać właściciela (zespół deweloperski, zespół testerów, zespół wdrożeniowy).
SPOTKANIA
Scrum definiuje kilka spotkań, które muszą się odbyć. Planowanie Sprintu, podczas którego wybierane są do sprintu historyjki z backlogu, nadawane są priorytety. Codzienny Scrum, czyli piętnastominutowe, statusowe spotkanie, w trakcie którego każdy członekzespołu składa krótki raport, nad czym obecnie pracuje. Przegląd Sprintu to spotkanie na zakończenie każdego Sprintu, gdzie przeprowadzana jest inspekcja Przyrostu i dostosowanie backlogu. Retrospektywa Sprintu to spotkanie, którego zadaniem jest przeprowadzenie inspekcji działań Zespołu i opracowanie planu usprawnień (czy nie przypomina to ciągłego ulepszania Kanban?) na następny Sprint.
Kanban i Scrumban nie wymagają spotkań, są one opcjonalne. Mogą być całkowicie pominięte lub ustalone jako cykliczne lub na żądanie. W tych dwóch metodykach zaleca się korzystanie od czasu do czasu ze spotkań Kaizen (krótkie, w trakcie, których omawiane są ew. problemy i ich rozwiązania).
Scrumban bierze pod uwagę możliwość pojawienia się Codziennego Scrum, jako mechanizmu zapewnienia ciągłości pracy.
CIĄGŁE ULEPSZANIE
Pojęcie to opisuje, w jaki sposób zespoły reagują na napotkane problemy.
Scrum proces ten realizuje w formie Retrospektywy Sprintu. Proces ten odbywa się tuż po zakończeniu Sprintu.
Kanban i Scrumban nie ma konieczności.
PODSUMOWANIE
Scrumban daje Zespołowi znacznie większe możliwości adaptacyjne do wymagań Stakeholderów oraz oczekiwań produkcyjnych i robi to bez wprowadzania teorii i trudnych reguł. Eliminuje metryki, które, w wyniku błędnej interpretacji menedżera czy stakeholdera, nie przynoszą oczekiwanych efektów (dodatkowy stres Zespołu).
Jednak najważniejsze to odzyskanie czasu dla zespołu poprzez redukcję niepotrzebnych spotkań, ograniczenie pracy zespołu, dzięki czemu możliwe jest zakończenie zadania w wysokim standardzie. W dużej mierze redukowany jest też niezdrowy stres Zespołu, przez co możliwe jest zwiększenie efektywności. Dobra jakość produktu przekłada się na zwiększenie ogólnej satysfakcji klienta.