SCRUM w praktyce — Scrum Guide kontra cargo-cult agile

SCRUM to zestaw reguł zarządzania pracą zespołu produktowego, opisany w Scrum Guide przez Kena Schwabera i Jeffa Sutherlanda. Pierwsza wersja wyszła w 1995 roku, najnowsza w 2020. Cały dokument ma 13 stron. Większość firm, które wdrażają SCRUM, używa go niepoprawnie — i nie dlatego, że nie znają tych 13 stron, tylko dlatego, że SCRUM kłóci się z większością nawyków, jakie organizacja ma od dwudziestu lat. W tym tekście zbieram, co naprawdę pisze Scrum Guide, jakie są typowe błędy wdrożeniowe i kiedy SCRUM nie jest dobrym wyborem.

Co naprawdę pisze Scrum Guide

SCRUM definiuje trzy role: Product Owner (decyzje co robimy i w jakiej kolejności), Scrum Master (usuwa przeszkody, dba o przestrzeganie procesu), Developers (jeden zespół, który wykonuje pracę). Pięć eventów: Sprint (timebox 1-4 tygodnie), Sprint Planning, Daily Scrum (15 minut), Sprint Review, Sprint Retrospective. Trzy artefakty: Product Backlog, Sprint Backlog, Increment.

Wszystko poza tymi 11 elementami nie jest SCRUM-em. Estymacje w story points nie są SCRUM-em (są techniką, którą część zespołów stosuje). Velocity nie jest SCRUM-em. Burndown chart nie jest SCRUM-em. Rola Project Managera nie istnieje w SCRUM-ie. Te elementy zostały dolepione do SCRUM-a w komercyjnych szkoleniach i certyfikacjach przez ostatnie 20 lat — i właśnie dlatego większość zespołów myśli, że SCRUM to coś znacznie bardziej skomplikowanego niż w rzeczywistości.

Pięć błędów wdrożeniowych, które widziałem najczęściej

1. Daily jako status meeting dla menedżera. Daily Scrum jest dla zespołu Developers, nie dla Project Managera ani CTO. Jeśli na Daily nawiedza się szef zespołu i ludzie raportują mu postęp, to nie jest Daily Scrum, to jest klasyczny stand-up control freaku. Sygnał alarmowy: developerzy mówią do menedżera, a nie do siebie nawzajem.

2. Product Owner bez mandatu decyzyjnego. Product Owner ma podejmować decyzje produktowe na bieżąco. W wielu polskich firmach PO jest osobą, która spisuje życzenia kierownictwa w Jirze i każdą decyzję musi konsultować z trzema poziomami w górę. To proxy-PO, nie PO. Konsekwencja: zespół czeka tygodniami na decyzje, sprinty stają się fikcyjne, retro nic nie zmienia.

3. Sprint planning bez odświeżonego backlogu. Backlog refinement (czasem nazywane backlog grooming) to praca, która powinna dziać się ciągle między sprintami, nie podczas planning. Jeśli zespół wchodzi w planning z brudnym backlogiem, gdzie połowa items wymaga doprecyzowania, planning zajmuje 6 godzin zamiast 2.

4. Retro jako rytuał bez konsekwencji. Retrospective bez konkretnych action items, bez przypisanej osoby odpowiedzialnej i bez sprawdzenia w następnym retro, czy zostało zrealizowane — to jest godzina pogadanki. Po sześciu retro w tym formacie zespół przestaje wierzyć, że proces cokolwiek zmienia.

5. Velocity jako KPI dla menedżerów. Velocity miało służyć zespołowi do planowania własnych sprintów. Gdy menedżer zaczyna porównywać velocity między zespołami albo wymagać, żeby ono rosło, zespół zaczyna inflować estymacje. Goodhart’s Law: każda metryka, która staje się celem, przestaje być dobrą metryką.

Kiedy SCRUM nie jest dobrym wyborem

SCRUM jest zaprojektowany dla pracy złożonej (complex w sensie ramy Cynefin Dave'a Snowdena) — gdzie nie wiemy z góry, co ma być produktem ani jak go zbudować. Jest mniej dobry dla pracy:

Operacyjnej i powtarzalnej — utrzymanie infrastruktury, support, raportowanie. Tu lepiej działa Kanban z WIP limitami i klasami obsługi.
Z bardzo krótkimi cyklami feedbacku (godziny, nie tygodnie) — np. zespoły response na incydenty bezpieczeństwa. Sprint dwutygodniowy jest tu absurdem.
O dużej zewnętrznej zależności — gdy więcej niż połowa pracy zależy od czynników poza zespołem, SCRUM staje się teatrem: planujemy sprint i okazuje się, że trzeba czekać na decyzję klienta przez tydzień.
W bardzo małym zespole (1-2 osoby) — overhead procesowy SCRUM-a przekracza wartość, jaką wnosi.

W praktyce, którą widzę w fintechach i SaaS B2B, najlepsze efekty daje hybryda: SCRUM dla feature teams (gdzie złożoność jest wysoka), Kanban dla operations i support, oraz bardziej swobodne formaty dla zespołów R&D na bardzo wczesnym etapie produktu.

Co działa nawet w niedoskonałym SCRUM

Nawet gdy organizacja nie pozwala na pełne wdrożenie SCRUM-a, kilka praktyk daje wyraźną wartość praktycznie zawsze:

Timeboxing. Stała kadencja sprintów (np. dwutygodniowa) wymusza priorytetyzację. Bez timeboxa praca rozlewa się na czas dostępny — to klasyczne prawo Parkinsona.
Definition of Done. Pisemnie ustalone kryterium, kiedy item jest skończony. Eliminuje 80% sporów między zespołem a PO o to, czy coś zostało dostarczone.
Daily standup. Nawet bez pełnego SCRUM-a 15-minutowe spotkanie zespołu o tej samej porze synchronizuje pracę i wcześnie wyłapuje przeszkody.
Retrospektywa, ale z action itemami. Co dwa-trzy tygodnie zespół ogląda swój proces i zmienia jedną rzecz. Nawet bez całego SCRUM-a daje to skumulowaną poprawę przez kilka miesięcy.
Pisemny backlog priorytetowy. Lista pracy w jednej kolejności, jeden właściciel decyzji co priorytetem. Bez tego organizacja walczy o uwagę zespołu wieloma równoległymi kanałami.

SCRUM a kultura cargo-cult

Termin cargo-cult agile pochodzi od Martina Fowlera. Opisuje organizacje, które wdrażają rytuały SCRUM-a (sprinty, daily, retro) bez zrozumienia, dlaczego one istnieją. Efekt: forma bez treści. Ludzie spotykają się punktualnie, ale nikt nie podejmuje decyzji. Sprinty są planowane, ale wymagania zmieniają się w połowie. Retro odbywają się, ale wnioski znikają.

Najtrudniejsza prawda o SCRUM-ie jest taka: nie da się go wdrożyć w organizacji, która chce zachować tradycyjną hierarchię decyzyjną i kontrolę menedżerską nad pracą zespołu. SCRUM jest narzędziem dla zespołów, które naprawdę mają autonomię nad tym, jak realizują cele. Bez tego fundamentu cała reszta jest teatrem — i lepiej oszczędzić zespołowi tygodni rytuału, który niczego nie zmienia.

Czym SCRUM różni się od Kanbana?

SCRUM jest oparty na sprintach (timebox 1-4 tygodnie), które dostarczają increment w każdym cyklu. Ma sztywno określone role, eventy i artefakty opisane w Scrum Guide. Kanban skupia się na ciągłym przepływie pracy z ograniczeniami WIP (work in progress) i nie wymaga sprintów ani ról. SCRUM lepiej działa przy pracy złożonej z planowaniem na 2 tygodnie, Kanban przy pracy operacyjnej i powtarzalnej.

Czy mały zespół (2-3 osoby) potrzebuje SCRUM-a?

Najczęściej nie. Overhead procesowy SCRUM-a (ceremonie, role, artefakty) w małym zespole przekracza wartość, jaką wnosi. Małe zespoły lepiej radzą sobie z prostym backlogiem priorytetowym, krótkim daily standupem i Definition of Done — bez pełnej struktury SCRUM-a. Pełny SCRUM zaczyna mieć sens przy 4-9 osobach pracujących nad tym samym produktem.

Po czym poznać, że SCRUM w mojej firmie jest cargo-cult?

Sygnały: Product Owner musi konsultować każdą decyzję z górą (proxy-PO), Daily jest raportowaniem do menedżera, sprint scope zmienia się w połowie, retro odbywają się, ale nic z nich nie wynika, velocity jest porównywane między zespołami przez kierownictwo, role Scrum Mastera jest pełniona przez Project Managera bez zmiany odpowiedzialności. W każdej z tych sytuacji forma jest, treści brakuje.

Powiązane artykuły

Źródła i dalsza lektura

(Visited 69 times, 1 visits today)

SCRUM w praktyce — co naprawdę pisze Scrum Guide i pięć typowych błędów wdrożeniowych