Co to jest Scrumban?

Co to jest Scrumban?

Scrumban jest hybrydą Scruma i Kanbana. To mieszanka ceremonii używanych w Scrumie z elementami charakterystycznymi dla Kanbana: wizualizacją, limitami WIP, systemem pull i stałym przepływem zadań. Kombinacja ta jest szczególnie przydatna dla zespołów przechodzących z używania Scrum do Kanban lub takich, które nigdy nie próbowały metod zwinnych, ale są zainteresowane organizacją pracy w myśl strategii pull.

Sam termin Scrumban ma źródło z książce Corey Ladasa pt. „Scrumban: Essays on Kanban Systems for Lean Software Development”.

Scrum i Kanban w pigułce

Scrum został opracowany jako platforma programowania równoległego. Jej celem było zwiększenie szybkości dostarczania produktów oraz lepsze dostosowanie do zmieniających się wymagań i warunków rynkowych. W Scrumie, pracę dzieli się na 1-4 tygodniowe iteracje zwane sprintami. Po każdym sprincie dostępny powinien być działający produkt. Zespoły są małe i wielofunkcyjne, a całość prac dla danej iteracji określa osoba wyznaczona na właściciela produktu.

Kanban ma korzenie w produkcji, a jedną z jego kluczowych cech są limity pracy w toku. Zespoły korzystające z Kanbana koncentrują się na utrzymaniu ciągłego przepływu pracy, wizualizowanego jako karty Kanban na tablicy podzielonej wg etapów ukończenia. Dla lepszego zarządzania przepustowością, każdy etap ma wyznaczony limit WIP. Limity są regularnie monitorowane w celu zapewnienia maksymalnej wydajności i przewidywalności procesu.

Czym jest Scrumban?

Hybrydowa metoda Scrumban pozwala zespołom wykorzystać najlepsze elementy obu metod w celu zaspokojenia konkretnych potrzeb. Doświadczonym zespołom często zaleca się by przeszły ze Scruma do Kanbana, a Scrumban jest dobrym sposobem na dokonanie tego przeskoku. Niejednokrotnie jednak zespoły decydują się po prostu pozostać przy procesie Scrumban. Scrumban jest bliższy Kanbanowi niż Scrumowi, jeśli wziąć pod uwagę, że – jako system mniej restrykcyjny niż Scrum – łatwiej go dostosować do różnorakich celów.

Początki Scrumbana: Wdrożenie Scruma jest trudne

Adopcja metod zwinnych jest dla większości zespołów mozolna, jako, że często wymaga trudnej do zdefiniowania zmiany myślenia. Ponadto, ze względu na popularność Scruma, wielu menadżerów rozważając Agile myśli o tylko o nim, mimo że dostępnych jest wiele innych - potencjalnie prostszych - metod, np. Kanban, XP, DSDM itp.

Choć istnieje wiele przykładów udanej adopcji Scruma, osiągnięcie sukcesu zazwyczaj jest kłopotliwe. W najlepiej prosperujących firmach, opracowanie dyscypliny umożliwiającej działanie Scruma zabiera od 12 do 16 tygodni. Nierzadko zdarza się też, że firmy te potrzebują pomocy konsultantów z zewnątrz. Często pojawiają się też trudności z obsadzeniem nowo wymaganych ról właściciela produktu, scrum mastera i zespołu programistów, co może prowadzić do większych problemów kadrowych.

Co więcej, obliczanie punktów historyjek użytkownika i mierzenie prędkości – choć, według oficjalnego przewodnika po Scrumie, niewymagane w ramach stosowania metody – w praktyce jest niemal koniecznością. Większość zespołów ma trudności ze zrozumieniem tych wymagań, a Scrum masterzy podkreślają, jak trudne jest zrobienie tego dobrze. Scrumban pozwala uniknąć tego zbędnego zamieszania.

Menadżerowie projektów są przyzwyczajeni do pracy z przedsięwzięciami, które mają ustalone daty rozpoczęcia i zakończenia. Projekty wykonywane są przez wielofunkcyjne zespoły, które mogą współpracować przez rok lub krócej. Zespoły takie mogą się dobrze odnaleźć w Scrumbanie, przejmując struktury komunikacyjne oparte na niektórych ceremoniach Scrum, z dedykowanymi sesjami planowania ukierunkowanych na omówienie wymagań projektu.

W przypadku wielu projektów, szczególnie tych związanych z budową i utrzymaniem infrastruktury, nie zawsze z końcem sprintu dostępny będzie produkt, co jest jednym z wymagań Scrum. Zespoły pracują w sposób ciągły i przechodzą z testu do produkcji lub następnej iteracji wtedy, gdy są na to gotowe. Podejście Scrumban uwzględnia taki istniejący cykl życia systemu lub produktu i dodatkowo wyposaża go w obrazowość Kanbana z niektórymi ceremoniami Scrum.

Ponadto, dzięki Scrumbanowi kierownicy projektów nie muszą na siłę wyznaczać właściciela produktu, aby kontrolować rejestr zadań. Rola właściciela produktu jest kluczowa w Scrumie, jednak w korporacjach często będzie wielu właścicieli z różnymi rodzajami żądań, co skutecznie uniemożliwi jednej osobie ustalenie priorytetów historyjek. Scrumban nie wymaga zunifikowanych w rozmiarze zadań, ani jednego właściciela rejestru, nakazuje jedynie, by kolejka zadań widoczna była dla wszystkich.

Przeskok z iteracji na stały przepływ

Scrumban pozwala zespołom porzucić cykliczne planowanie pracy na rzecz planowania tylko wtedy, gdy jest konieczne. Nowe rzeczy do zrobienia mogą być regularnie odkrywane na produkcji. W przeciwieństwie do Scruma, Scrumban nie zmusza zespołów do ograniczenia zakresu sprintu do 1-4 tygodni, dzięki czemu proces produkcji może trwać tak długo jak to konieczne dla uzyskania najlepszych wyników. Podczas gdy z perspektywy projektu tu proces się kończy, dla większości firm koniec projektu to dopiero początek. Projekty prowadzone są tak, aby zainicjowana przez nie zmiana mogła dalej funkcjonować i przynosić korzyści. Scrumban jest w tym bardzo przydatny.

Zespołom, które dotychczas korzystały ze Scruma, najłatwiej będzie wdrożyć Scrumban w późniejszej części projektu - kiedy przechodzą od rozwoju produktu do utrzymania, adoptując stały przepływ zadań.

Co w takim razie różni Scrumban od Kanbana?

Zazwyczaj zespoły dzielą przepływ pracy na tablicy Scrumban na więcej etapów, niż wydzieliłyby na tablicy Kanban. Wynika to z potrzeby pokazania bardziej stopniowego charakteru procesu, związanego z podejściem do planowania projektów opartym na sprintach. Bardzo często tablica Scrumban zawiera sam etap „sprint” lub klasę przedmiotów „Historyjki użytkowników”. Tablice Scrumban umożliwiają śledzenie postępów prac związanych z konkretną historyjką lub danym sprintem, pomimo tego, że zespół pracuje nieprzerwanie.

Zespoły Scrumban mają zazwyczaj większą swobodę w ustalaniu priorytetów pozycji w kolumnach, niż zespoły pracujące z Kanbanem, który zaleca trzymanie się zasady FIFO (first in – first out).

Podsumowanie

Scrumban jest dobrym rozwiązaniem dla firm zdających sobie sprawę, że muszą przejść na bardziej zwinny, szczupły sposób pracy. Łatwość adopcji Scumbana jest zasługą usunięcia ze Scruma niepotrzebnego bagażu, który do pracy wielu zespołów wniósłby niewiele. Metoda hybrydowa pozwala zespołom kontynuować pracę w sposób dla nich naturalny, jednocześnie wdrażając najlepsze praktyki Lean i Agile, typowe dla procesów opartych na stałym przepływie.

Scrumban może zapewnić firmie dyscyplinującą ilość rygoru, wraz z elastycznością, wydajnością i widocznością Kanbana i metodyki Lean.

Kluczowe korzyści wynikające z używania Scrumbana:

  • wyższa jakość pracy i podejmowanie decyzji dokładnie na czas (JIT)
  • zwiększona szybkość przetwarzania
  • zminimalizowane straty
  • lepiej zintegrowane, silniejsze i bardziej zadowolone zespoły
  • nieustannie ulepszane procesy


Cechy Scrumban
Role Niezdefiniowane. Zespół plus role wymagane, np. kierownik projektu itp.
Spotkania / sesje Dowolna liczba potrzebna do zapewnienia ciągłego postępu. Typowo codzienny stand-up, jako minimum.
Dema
i retrospektywy
W liczbie potrzebnej w konkretnym przypadku – nie są wymagane pod koniec każdego sprintu.
Iteracje Niezdefiniowane, praca odbywa się z założeniem stałego przepływu.
Strategia pracy Pobieranie (pull) z limitami pracy w toku.
Wykres spalania Nie, tylko tablica Kanban.
Śledzenie prędkości Nie, ale zaleca się koncentrację na usuwaniu wąskich gardeł.
Szacowanie Zadania na tablicy mają podobne wielkości, ale nie są ograniczane punktami historyjek.
Rejestr Kierowany przez JIT (produkcja dokładnie na czas).
Zakres Nieograniczony, tablica jest regularnie aktualizowana. Przepływ pracy nie jest przeciążony, ale oparty na JIT i przepustowości.