Jeżeli interesuje Cię temat zwinnego wytwarzania oprogramowania, zapewne nie jest Ci obcy Scrum, FFD, Extreme Programming czy Kanban. Coraz częściej pojawiają się pytania oraz konflikty o najlepszą metodykę pracy. Zazwyczaj są one wynikiem poszukiwań efektywniejszych sposobów wytwarzania systemów, które zostały podjęte ze względu na problemy, z którymi spotykano się stosując podejścia klasyczne (np. Waterfall).

Poniższy wykres przedstawia popularność wykorzystania konkretnych zwinnych praktyk w Polsce na podstawie badania przeprowadzonego przez Scrum Alliance.

Z powyższego wykresu wynika, że Scrum oraz Kanban to dwie najpopularniejsze zwinne metody zarządzania procesem dostarczania systemów IT w Polsce. Zatem czy coś stoi na przeszkodzie, aby połączyć cechy obu, czyli mocno opisowej natury Scrum oraz szansy na ciągłe usprawnianie procesu typowej dla Kanban?

Artykuł ten nie ma na celu przedstawienia, ani szczegółowego opisania praktyk Scrum i Kanban. Aby w pełni zrozumieć metodykę Kanban wymagana jest chociaż podstawowa znajomość Scrum i Kanban. Dla przypomnienia, poniższy rysunek przedstawia główne cechy obydwu praktyk.

Scrum to zwinny proces, który z założenia pomaga dostarczać wartość biznesową dla klienta w jak najkrótszym czasie. Posiada wiele zdefiniowanych przez Scrum Guide reguł i artefaktów. Podkreśla pracę zespołową, określone rolę i iteracyjny postęp prac. Jego celem jest dostarczanie nowych funkcjonalności co 2-4 tygodnie.

Kanban to system zarządzania pracą. Wizualizuje zarówno proces, jak i rzeczywistą pracę przechodzącą przez ten proces. Głównym zadanie Kanban to identyfikacja potencjalnych wąskich gardeł w procesie i ich eliminacja. Celem Kanban jest to, aby przepływ pracy przebiegał płynnie z optymalną wydajnością zespołu.

Zestawienie najważniejszych zalet i wad poszczególnych praktyk zostało przedstawione poniżej.

Jak widać, niektóre z tych elementów w zależności od specyfiki projektu czy kontekstu są dla jednych zaletą, a dla innych wadą. Warto jest mieć tutaj na uwadze, że ani Scrum, ani Kanban nie jest metodyką totalną i nie rozwiąże wszystkich problemów z jakimi potyka się zespół. Wybierając pomiędzy Scrum a Kanban, trzeba się zastanowić z jakimi problemami będziemy mieli do czynienia i na czym najbardziej nam zależy. Czy jest to czas realizacji, inkrementalny rozwój produktu czy jego częsta walidacja?

Zapewne zauważyłeś już, że możliwe jest połączenie tych praktyk i korzystanie z nich hybrydowe tam, gdzie ma to największy sens. Taka hybryda została nazwana ScrumBan. Powstała dosyć niedawno jako próba zastosowania procesu Scrum rozbudowanego o praktyki Kanban i powoli zdobywa coraz większą rzeszę zwolenników. Jak widać na wykresie, ScrumBan jest wciąż jedną z niszowych i bardzo rzadko stosowanych praktyk w Polsce (zaledwie 6% projektów korzystających metodyk zwinny wykorzystuje ScrumBan).

Co to jest ScrumBan?

Już sama nazwa zawiera w sobie odpowiedź. Jest to powiązanie zasad Scrum i Kanban. Pomysł prosty, jednak na tyle rewolucyjny, że dość szybko zyskał nowych naśladowców. Co stoi na przeszkodzie, aby wyjść poza ograniczenia narzucone przez Scrum czy ograniczyć lekki niepokój w świecie niezdefiniowania Kanban (role, sprinty, pływający zakres)? Odpowiedź brzmi ‘NIC’ – zarówno w projektach, w których odgórnie narzucony jest Scrum czy Kanban, możemy spokojnie skorzystać ze wszystkich dobrodziejstw, jakie oferuje Kanban przy jednoczesnych rozluźnieniu praktyk Scrum (przegląd kodu, typowe spotkania, ściśle określone sprinty).

ScrumBan powstawał dość naturalnie dzięki zespołom zwinnym pracującym w Scrum jako eksperyment dołączenia najważniejszych praktyk Kanban:

• wprowadzenie limitów zadań w toku (WIP)
• zarządzanie przepływem zadań
• wizualizacja procesu
• zasada zero wyjątków – Sztywne trzymanie się zasad i polityki procesu dostarczania produktu.

Wiele osób może w tym momencie się zdziwić i powiedzieć, że Scrum i Kanban to dwa przeciwległe bieguny. To poniekąd prawda, jednak osobiście nie traktuje ScrumBan jak mix powyższych praktyk, czyli połączenia Agile oraz Lean, a raczej jako zmodyfikowanie procesu Scrum z nałożoną warstwą Kanban. O czym warto pamiętać w tym przypadku? Modyfikując proces Scrum poprzez narzucenie na niego ramy Kanban, przestaje on być ściśle procesem Scrum!

Poniższe zestawienie najważniejszych podobieństw i różnic, pomoże Ci lepiej zrozumieć założenia ScrumBan:

Patrząc na powyższe zestawienie, jak i przez pryzmat mojego doświadczenia (a prowadziłem już kilka projektów w metodyce ScrumBan) widać, że ScrumBan oferuje:

• większe możliwości adaptacyjne co do wymagań i zmian właścicieli biznesowych
• eliminuje zbędne zasady, metryki które nie przynoszą oczekiwanych efektów
• redukuje liczbę spotkań z których zespół świadomie może zrezygnować., przez co przyczynia się do oszczędności czasu i efektywności zespołu
• sprzyja ciągłemu doskonaleniu i usprawnianiu procesu
• minimalizuje straty i niepotrzebnie spalane MD.

Jak zacząć ze ScrumBan?

Rozpoczęcie pracy ze ScrumBan jest dość intuicyjne. Zaczynamy od prostej i generycznej tablicy, trzymamy się kilku podstawowych zasad, szukając możliwości ulepszenia i dopasowania tablicy do naszych potrzeb.

Krok 1 | Zacznij od stworzenia Tablicy ScrumBan

Utwórz podstawową tabelę składającą się z 4 podstawowych kolumn:

• Backlog – Rejestr
• To Do – Do zrobienia
• In Progress – Praca w toku
• Done – Gotowe

Pamiętaj, że kolumna In Progress może być podzielona na różne sekcje, co zostanie przedstawione w kolejnym rozdziale.

Krok 2 | Zapełnij i ustaw limit w Rejestrze

Sporządź listę zadań, umieść je w kolumnie Backlog i ustaw limit postępu prac dla tej kolumny. Z racji tego, że ScrumBan nie ma regularnych spotkań Planowania, limit ten będzie wykorzystany do tzw. planowania na żądanie. Zespół przesuwa zadania z kolumny Backlog w prawą stronę tabeli, aż stanie się ona pusta, co jest naturalnym sygnałem, że trzeba zaplanować kolejne zadania. Efektywniej i zarazem łatwiej jest planować kilka zadań na iterację. Możesz również stosować priorytety w poszczególnych zadaniach, co dostarczy zespołowi informacji, które zadania należy podjąć w pierwszej kolejności.

Krok 3 | Znajdź wąskie gardła

Podziel sekcję Work in Progress na mniejsze kolumny w zależności od specyfiki projektu, aby wdrożyć oddzielne limity WIP. Takie podejście pozwala odkryć wąskie gardła, które blokują przepływ procesu.

Krok 4 | Mierz i kontroluj

Dwa najważniejsze wskaźniki w metodyce ScrumBan to średni czas oczekiwania (lead time) oraz średni czas wytworzenia (cycle). Czas oczekiwania to czas od momentu zgłoszenia wymagania przez klienta do momentu uzyskania w pełni działającej funkcjonalności na środowisku produkcyjnym. Inaczej to czas oczekiwania klienta. Czas wytworzenia to ilość czasu jaką zespół poświęcił na pracę nad danym wymaganiem. Nie jest wliczany tutaj czas w którym zadanie spędziło w kolumnie Rejestr. Jeśli kontrolujesz oba te wskaźniki, jesteś w stanie dość szczegółowo oszacować, ile czasu zajmie dostarczenie określonej wartości dla klienta końcowego.

Natomiast w sytuacji, gdy w Twojej organizacji czy projekcie działa już Scrum ogranicz się do podstawowych zasad opisanych poniżej:

• zacznij od takich ceremonii, tablic i ról w projekcie, jakie stosujesz teraz
• znajdź punkty procesu, które można ulepszyć
• szanuj aktualne role i obowiązki zespołu, jednocześnie mając na celu ich usprawnienie.

Jak stworzyć Tablicę ScrumBan?

Poniżej przedstawiłem tablicę ScrumBan, jaką używałem w jednym z projektów. Sekcja In Progress została podzielona na 5 mniejszych podsekcji odpowiadających statusowi w jakim znajduje się dane zadanie. Oczywiście wypracowanie takiego stanu tablicy zajęło mi trochę czasu. Początkowo była ona dużo prostsza – zawierała tylko 4 sekcje. Tak jak już pisałem wcześniej, Ty też zacznij od prostej tablicy i modyfikuj ją w zależności od potrzeb.

Na czerwono zostały przedstawione Limity WIP. Cyfra w kółku oznacza i przypomina o maksymalnej ilości otwartych zadań nad którymi może pracować zespół w danym momencie. Cyfry przedstawione w nawiasach wyznaczają limit zadań już w konkretnej podsekcji. Jak łatwo policzyć i zauważyć, rozkład zadań prezentuje świat idealny.

Jednak jak już się domyślacie, świat idealny nie istnieje. W kolejnym rozdziale przedstawię bardziej problemowy przypadek oraz sposób w jaki analizować tablicę i szukać ulepszeń.

Jak zarządzać ze ScrumBan?

No poniższej tablicy widzimy kilka sytuacji problemowych. Ta najbardziej oczywista, to taka, że straciliśmy kontrolę na punktami WIP w poszczególnych sekcjach. Łatwo również jest zidentyfikować problemy i wąskie gardła:

• developerzy nie mogą rozpocząć nowych zadań, bo przekroczą ogólny Limit WIP
• w przypadku, gdy ostatnie zadanie developerskie zostanie ukończone, developerzy nie będą mogli pobrać nowych zadań z podsekcji To_Dev, bo jest ona pusta – należałoby skupić się na analizie Backlog i ukończeniu analizy jednego z zadań, aby znalazło się w sekcji To_Dev
• w kolumnie To_Test oraz In_Test znajduje się w sumie 7 zadań z 9 dostępnych, zatem widzimy, że jest to wąskie gardło i trzeba alokować dodatkowe zasoby w te obszary tak, aby udrożnić przepływ i przepchnąć zadań w prawą stronę.

Analiza tablicy ScrumBan wymaga pewnej wprawy i doświadczenia, jednak widzimy, iż jest to na pewno łatwiejsze niż analizowanie wykresów Gantta czy popularnych wskaźników PM.

Jak wdrażać ze ScrumBan?

ScrumBan jest procesem ciągłym. Zatem co zrobić, gdy zbliżamy się do końca Sprintu, projektu lub konkretnego wydania i klient lub harmonogram wymaga, aby aktualny progres prac znalazł się na środowisku produkcyjnym? Praktyka ScrumBan wypracowała pewne elementy upraszczające wdrożenie. Najłatwiej jest mi to przedstawić na poniższym wykresie.

Limit WIP – aby upewnić się, że zespół działa z optymalną wydajności, metodyka ScrumBan zakłada, że członek zespołu powinien pracować na nie więcej niż jednym zadaniu w danym momencie. Praktycznie jest to limit nad sekcją In Progress (może również znajdować się nad każdą sekcją, mamy wtedy do czynienia z osobnymi limitami per określony status zadania) oznaczający, ile zadań może znajdować się w sekcji. Oczywiście, jak już pewnie dobrze zauważyłeś, limit WIP powinien być równy licznie członków zespołu, jednak może się on różnic w zależności od specyfiki i poziomu doświadczenia zespołu.

Freeze – używany jest w ScrumBan wtedy, gdy zbliża się koniec pewnego etapu realizacji, sprintu czy określonego wydania (release). Oznacza to, że od tego momentu nie dodajemy nowych zadań, ani nie wprowadzamy zmian. Pracujemy tylko na zadaniach w kolumnie In Progress.

Triage (Segregacja) – kluczowy moment w ScrumBan, stosowany jest zaraz po Freeze. Moment, w którym to Kierownik Projekt i/lub zespół ponownie ustala priorytety, biorąc pod uwagę stopień ukończenia i złożoności poszczególnych zadań, decydując które zadania zostaną ukończone przez wdrożeniem, a które nie. Gwarantuje to pełne skupienie zespołu na ukończenia zadań o najwyższym priorytecie.

Kiedy stosować ScrumBan?

Zastanawiasz się pewnie jakie przypadki, czy jakie środowisko pracy najbardziej nadaje się do prowadzenia ScrumBan. Podobnie jak w przypadku każdej metodyki, ScrumBan nie jest dla każdego. Jeśli projekt czy firma, dla której aktualnie pracujesz, jest już optymalnie dopasowana do Scrum; posiada doświadczonych i zaangażowanych w proces rozwoju pracowników, którzy znają pojęcie i wszelkie konsekwencje związane z User Story; a cała firma wydała worek złota na transformację i szkolenia Scrum, może lepiej będzie trzymać się Scrum.

Jeśli z kolei pracujesz głównie w środowisku serwisowym, czy utrzymaniowym bez jakichkolwiek prac rozwojowych; liczba zadań i usterek jest stosunkowo niewielka i rzadko zdarza się sytuacja, gdy ktoś rozwiązuje więcej niż jeden problem w danym momencie, to lepszy w tej sytuacji będzie Kanban.

Zatem powracamy do tego przypadku, gdy ScrumBan może okazać się bardziej wydajny i efektywny niż Scrum lub Kanban:

• problematyczne projekty pełne nieoczekiwanych zmian, nieplanowanych zadań, błędów czy nagłych zmian priorytetów
• stosujesz już Scrum, lecz zamiast przydzielania zadań chciałbyś skorzystać z pobierania zadań (push – pull)
• Scrum zakończył się niepowodzeniem (niewystarczające zasoby, ograniczenia czasowe sprintu czy inne problemy)
• utrzymanie i serwis aplikacji, gdzie praca nad rozwojem produktu ma również duże znaczenie
• praca sterowana wydarzeniami (event-driven), np. wsparcie albo stabilizacja
• w zwinnych zespołach startujących przy tworzeniu nowego.

Z doświadczenia dodam również, że jest do doskonała metoda do prac przy projektach, na których zakładane jest utworzenie rozwiązania typu POC (Proof of Concept) z późniejszymi iteracjami rozszerzającymi poszczególne funkcjonalności.

Jedną z często pomijanych korzyści ScrumBan jest to, że jego zasady i praktyki nie odnoszą się wyłącznie do rozwoju oprogramowania. ScrumBan może być wykorzystywany w innych obszarach, jak np. modelowanie procesów biznesowych.

Mam nadzieję, że udało mi się zachęcić Was do bliższego zapoznania się ze ScrumBan. W razie pytań czy wątpliwości, zapraszam do kontaktu.