„Kanban czy scrum?” to zwinne pytanie, które zadaje każdy nowy potencjalny klient, a które z najbardziej elastycznych treści udziela złych odpowiedzi. Szczera odpowiedź jest taka, że mają one różne kształty i są przeznaczone do różnych zastosowań; ani lepszy, ani gorszy, i rzadko zdarza się wybór typu „albo/albo”, gdy już zrozumiesz, co każdy z nich faktycznie zapewnia. Ten post to praktyczna wersja: czym naprawdę jest każdy z nich, cztery sygnały, które mówią, który z nich pasuje, oraz zespoły hybrydowe, które odnoszą największe sukcesy.
Różnica jednej linii
Scrum to kadencja. Kanban to przepływ.
Scrum mówi: podziel pracę na 2-tygodniowe iteracje, zaplanuj na początku, demo na końcu, powtórz cykl. Kadencja to jednostka.
Kanban mówi: ciągnij pracę w sposób ciągły, ogranicz liczbę rzeczy wykonywanych jednocześnie, zoptymalizuj przepływ. Przepływ to jednostka.
Obydwa są zwinne (w sensie wartości). Obydwa mogą tworzyć zespoły doskonałe lub dysfunkcyjne. Wybór dotyczy jaki kształt pracy, którą wykonujesz, a nie tego, czy Twój zespół jest „wystarczająco zaawansowany” do obsługi Kanban.
Czym właściwie jest scrum
Zdefiniowane w Przewodniku Scrum. Trzy role (właściciel produktu, Mistrz Scrum, Deweloperzy), pięć wydarzeń (sprint, planowanie, codzienny scrum, recenzja, retrospektywa), trzy artefakty (zaległości produktowe, zaległości sprintu, przyrosty).
Definiujące zobowiązanie: sprint jest jednostką wartości. Angażujesz się w zestaw prac na 2 tygodnie, wysyłasz go jako spójny przyrost, zastanawiasz się, zaczynasz od nowa.
To zobowiązanie ma sens, gdy:
- Bez większego zaskoczenia można przewidzieć 2 tygodnie pracy
- Praca ma charakter fabularny; dyskretny, projektowalny, możliwy do wykończenia
- Zainteresowane strony chcą regularnej częstotliwości demonstracji
- Zespół korzysta z wymuszonej refleksji (retro) w znanym przedziale czasu
Załamuje się, gdy:
- Praca jest reaktywna; zgłoszenia do pomocy technicznej, eskalacje operacji, pilne błędy
- Przedmioty różnią się znacznie pod względem wielkości i nie można z pożytkiem „zaangażować się” w sprint
- Zadaniem zespołu jest wchłanianie wszystkiego, co się pojawi, a nie dostarczanie nowych funkcji
Czym właściwie jest Kanban
Nie ma odpowiednika Kanban Guide; Kanban to metoda, a nie framework. Podstawowe praktyki zaczerpnięte z tradycji Lean to:
- Wizualizuj pracę: tablica z kolumnami dla każdego stanu przepływu pracy
- Ogranicz pracę w toku (WIP): wyraźne limity liczbowe na kolumnę
- Zarządzaj przepływem: zmierz, ile czasu zajmuje praca od początku do końca (czas cyklu, czas realizacji)
- Wyraźnie przedstawiaj zasady: jasne zasady określające, co oznacza „gotowe” lub „gotowe” w każdej kolumnie
- Udoskonalaj się w sposób ciągły: małe eksperymenty oparte na danych dotyczących przepływu
To wszystko. Żadnych sprintów, żadnych wymaganych ceremonii, żadnych wymaganych ról.
Definiujące zobowiązanie: limit WIP jest jednostką dyscypliny. Nie wyciągasz nowego przedmiotu, dopóki coś nie jest skończone. Czas cyklu i przepustowość to wskaźniki, które się nie liczą prędkość.
Ma to sens, gdy:
- Praca przychodzi nieprzewidywalnie i nie można wokół niej zaplanować sprintu
- Elementy mają mniej więcej podobny rozmiar lub czas ukończenia, dlatego przydatny jest widok przepływu skumulowanego
- Chcesz zoptymalizować dla czas wysyłki na pojedyncze przedmioty, a nie na pakiety
- Zespół jest na tyle dojrzały, że może się samoregulować bez wymuszonego rytmu ceremonii
Załamuje się, gdy:
- Zespół nie ma wewnętrznego pociągu do refleksji i doskonalenia (retro jest pomijane i nigdy nie jest przywracane)
- Praca wymaga jawnej synchronizacji między zespołami (np. wydania obejmujące wiele elementów)
- Zainteresowane strony oczekują regularnych aktualizacji „co dostarczono w tym okresie”.
Cztery sygnały, które wybierają za Ciebie
Kiedy zespoły pytają „scrum czy kanban?”, odpowiedź wypada z czterech sygnałów.
1. Przewidywalność przychodzącej pracy
- Przewidywalny, możliwy do zaplanowania w dwutygodniowych fragmentach → scrum
- Reaktywne, nie można zaplanować → kanban
Przykłady:
- Dostarczanie funkcji w planie działania produktu → scrum
- Obsługa klienta poziom 2 → kanban
- Zespół ds. platformy/SRE → kanban (głównie)
- Zespół ds. aplikacji mobilnych dostarczający comiesięczne wydania → scrum
2. Różnica w wielkości przedmiotu
- Elementy są mniej więcej podobnej wielkości → albo działa
- Przedmioty są bardzo zróżnicowane (od 1 dnia do 3 tygodni) → Scrum walczy, Kanban sobie z tym radzi
Punkty fabularne częściowo uwzględnij różnice w wielkości w Scrumie, ale tylko wtedy, gdy zespół dobrze to oszacowa. Jeśli Twój zespół w tym samym sprincie zdobędzie elementy za 1 i 13 punktów, będziesz stale angażował się w niedostateczne lub nadmierne zaangażowanie. Kanban z limitami WIP nie przejmuje się rozmiarem przedmiotu; to po prostu ogranicza liczbę latających osobników.
3. Oczekiwania interesariuszy dotyczące kadencji
- Interesariusze chcą rytmu „co nadejdzie w tym sprincie” + „co zostało wysłane”. → scrum
- Interesariusze chcą, aby poszczególne produkty były wysyłane jak najszybciej, bez grupowania → kanban
Zespół produktowy B2B SaaS sprzedający aktualizacje planów działania potrzebuje scruma (lub kształtu scruma). Zespół inżynierii wzrostu przeprowadzający testy A/B tak nie robi; chcą, aby eksperymenty były wysyłane pojedynczo i szybko.
4. Apetyt zespołu na ceremonię
- Zespół ceni ustrukturyzowany czas refleksji → scrum
- Zespół uważa spotkania za wyczerpujące i dobrze się samoreguluje → kanban
Bądź tu szczery. Wiele zespołów powiedz chcą Kanban, ponieważ nienawidzą ceremonii, a potem w ogóle nie zastanawiają się nad swoim procesem i powoli poniżają. Wymuszone retrospekcję Scrum wychwytują ten dryf; Praktyka Kanban dotycząca „zarządzania przepływem” działa tylko wtedy, gdy ktoś rzeczywiście to robi.
Hybryda, którą faktycznie prowadzi większość zespołów
Zarówno czysty scrum, jak i czysty kanban są rzadkie. Co sprawdza się w praktyce w przypadku większości zespołów inżynieryjnych produktu:
Scrumban: rytm scruma + dyscyplina przepływu kanbana.
- Zachowaj 2-tygodniowy sprint jako planowanie + kadencję retro
- Porzuć sztywne zaangażowanie w sprint; elementy można dodawać lub usuwać w trakcie sprintu po dyskusji
- Dodaj limity WIP na kolumnę na tablicy
- Śledź zarówno prędkość (w celu prognozowania), jak i czas cyklu (w celu sprawdzenia stanu przepływu)
- Biegaj 30-minutowy bieg retro w każdym sprincie, a nie co tydzień
To działa, ponieważ większość zespołów produktowych tak ma częściowo przewidywalna praca; funkcje, które chcą udostępnić, a także reaktywne błędy i drobne prośby. Czysty scrum wymusza nieprzewidywalne zatwierdzenie sprintu, do którego nie pasuje. Czysty Kanban pozwala zrezygnować z wymaganej przez interesariuszy rytmu planowania.
Co to oznacza w praktyce
Jeśli jesteś zespołem zajmującym się dostarczaniem funkcji (frontend, backend, pełny stos w planie rozwoju produktu): zacznij od scruma, a następnie po 6 sprintach przejdź do scrumbanu.
Jeśli jesteś zespołem zajmującym się platformą / SRE / ops: zacznij od Kanban. Przeprowadzaj comiesięczne retrospekcje zamiast sprintów retro.
Jeśli jesteś zespołem wsparcia lub jakimkolwiek zespołem, w którym> 60% pracy ma charakter reaktywny: Kanban, nie ma wątpliwości.
Jeśli tworzysz mały zespół inżynierów startupu (3–6 osób): scrumban zwykle ma rację. Kadencja pomaga, ale koszty całej ceremonii nie mieszczą się w małej skali.
Implikacje narzędziowe
Podstawowym błędem popełnianym przez zespoły jest wybór narzędzia wcześniej decydując o kształcie. Większość „zwinnych” narzędzi ma kształt scrum (sprinty, punkty historii, spalenie, prędkość) i przykręcić śrubę a kanban potraktuj to jako refleksję. Niektóre z nich mają kształt Kanban (ciągły przepływ, limity WIP, czas cyklu) i słabo radzą sobie z sprintami.
Jeśli jesteś scrumem lub scrumbanem, narzędzia w kształcie scrum będą właściwym wyborem. SprintFlint jest zbudowany wokół cyklu sprintu (automatyczna prędkość, natywne retro, spalanie uwzględniające sprint) z widokiem tablicy, który wspiera dyscyplinę WIP, jeśli tego chcesz.
Jeśli korzystasz wyłącznie z Kanbana bez sprintów, spójrz na narzędzia skupiające się na przepływie (Kanbanize, Samolot w trybie przepływu, Trello z Power-Upami). Narzędzia Scrum pasują niewygodnie.
TL;DR
- Scrum: najpierw kadencja. Zaplanuj sprint, wyślij go, retro, powtórz. Odpowiedni do przewidywalnej pracy z funkcjami.
- Kanban: najpierw przepływ. Limity WIP, czas cyklu, brak sprintów. Odpowiednie do pracy reaktywnej lub przedmiotów o dużej zmienności.
- Cztery sygnały: przewidywalność, rozbieżność w wielkości przedmiotu, oczekiwania interesariuszy dotyczące kadencji, apetyt zespołu na ceremonię.
- Najbardziej skuteczne zespoły produktowe uruchamiają scrumban; rytm sprintu z dyscypliną przepływu o smaku kanban.
- Najpierw wybierz kształt, potem narzędzie. Nie pozwól, aby Twoje narzędzie dokonało wyboru za Ciebie.