Wyobraź sobie firmę, która właśnie zatrudniła Scrum Mastera, kupiła licencje na Jirę i zarezerwowała salę z tablicą. Wszyscy przeszli dwudniowe szkolenie, Product Owner zna pojęcie Sprint Backlogu, deweloperzy wiedzą, że Daily Scrum trwa 15 minut. I nic. Po trzech miesiącach zespół goni własny ogon, Sprinty regularnie się nie domykają, a zarząd zaczyna pytać, gdzie są efekty tej “zwinnej transformacji”. Scrum nie zawiódł. Wdrożenie zawiodło.
Czym jest Scrum – i czego nim nie ma
Scrum to ramy pracy, nie metodologia w klasycznym sensie. Schwaber i Sutherland zdefiniowali to precyzyjnie w Scrum Guide z 2020 roku: framework jest celowo niekompletny, zostawia miejsce na procesy, techniki i narzędzia, które pasują do konkretnego kontekstu. Dokument liczy zaledwie 13 stron. Trzy role, pięć wydarzeń, trzy artefakty – i tyle. Reszta to twoja robota.
Jeśli chcesz zrozumieć, skąd w ogóle wzięła się ta nazwa i co łączy rugby z zarządzaniem projektami, warto zacząć od historii samego frameworku. Ale wdrożenie Scruma to inny temat niż jego geneza. Tutaj sprawy się komplikują.
Scrum Guide mówi, że Scrum Team powinien liczyć najwyżej 10 osób. Nie jest to twarda granica, ale praktyka pokazuje, że powyżej tej liczby ceremonie zaczynają się rozrastać, a Daily Scrum z 15-minutowej synchronizacji zmienia się w godzinne spotkanie z agendą. Efekt Ringelmanna – opisany przez Maxa Ringelmanna już w 1913 roku – nie jest specyficzny dla Scruma, ale ujawnia się w nim szczególnie wyraźnie: im więcej osób w zespole, tym mniejszy indywidualny wkład każdej z nich.
Trzy filary, które wszyscy znają i połowa zespołów ignoruje
Przejrzystość, inspekcja, adaptacja – brzmią jak slajd z konferencji. W praktyce wyglądają tak: Product Backlog jest nieaktualny od sześciu tygodni, Sprint Review odbywa się bez żadnego klienta ani interesariusza, a retrospekcje kończą się listą punktów, do których nikt nie wraca. Jeśli chcesz zobaczyć, jak te trzy zasady funkcjonują w rzeczywistości, przeczytaj, co się z nimi dzieje w zespołach, które już “wdrożyły” Scruma.
Problem z filarami nie jest problemem wiedzy. Każdy, kto siedział przez dwa dni na szkoleniu CSM, potrafi wymienić wszystkie trzy. Problem jest organizacyjny: Scrum wymaga od organizacji zgody na rzeczywistą przejrzystość, a to często boli. Transparentny Sprint Review oznacza, że zarząd widzi, co nie zostało dostarczone. Szczera retrospekcja oznacza, że ktoś musi przyznać, że proces jest zepsuty. Niektóre firmy wolą udawać, że Scrum działa, niż przyznać, że coś jest nie tak.
Skąd się bierze opór i dlaczego jest racjonalny
Wyobraź sobie team leadera z dziesięcioletnim stażem, który przez ostatnią dekadę budował swoją pozycję na tym, że rozdziela zadania, zbiera statusy i raportuje do góry. Scrum mówi mu, że Scrum Master nie jest jego przełożonym, a Deweloperzy sami planują Sprint. Jego rola właśnie zniknęła z diagramu. Trudno się dziwić, że na kolejnym Sprint Planning nagle okazuje się, że “musimy jednak omówić kilka kwestii technicznych” i spotkanie trwa trzy godziny.
Opór wobec Scruma rzadko jest ideologiczny. Raczej wynika z prostego rachunku: ktoś traci coś konkretnego, coś, co miał wcześniej. Zakres kontroli, tytuł, dostęp do informacji. Transformacje agile, które ignorują ten wymiar, wdrażają ceremonię bez zmiany struktury władzy. I właśnie dlatego po sześciu miesiącach Scrum istnieje na papierze, a decyzje nadal zapadają w gabinetach.
Skalowanie – kiedy jeden zespół przestaje wystarczać
Scrum zaprojektowano z myślą o jednym zespole. Kiedy organizacja rośnie i pojawia się potrzeba koordynacji między kilkoma zespołami, zaczyna się zabawa z frameworkami skalowania. SAFe (Scaled Agile Framework) to najpopularniejszy wybór w dużych korporacjach – jego struktura obejmuje poziomy Team, Program, Large Solution i Portfolio. Kniberg i Ivarsson opisali w 2012 roku model Spotify oparty na Squadach, Tribes, Chapters i Guilds, który stał się inspiracją dla dziesiątek organizacji. Tyle że sam Spotify od tamtego czasu znacząco zmodyfikował swoje podejście, a firmy, które skopiowały model bez rozumienia kontekstu, nierzadko skończyły z bardziej skomplikowaną biurokracją niż ta, którą chciały zastąpić.
Standish Group w kolejnych edycjach CHAOS Report od lat dokumentuje, że projekty IT częściej kończą się opóźnieniem lub przekroczeniem budżetu niż sukcesem. Scrum sam w sobie nie jest odpowiedzią na ten problem – jest narzędziem, które może pomóc, jeśli wiesz, dlaczego go używasz.
Zanim zaczniesz – pytanie, które warto zadać wcześniej
Nie każdy projekt nadaje się do Scruma. Scrum Guide wprost mówi, że framework sprawdza się przy złożonych problemach, gdzie wymagania i rozwiązania nie są z góry znane. Jeśli twój projekt ma z góry określony zakres, stały budżet i nieprzekraczalny termin, klasyczne podejście waterfall albo PRINCE2 może okazać się rozsądniejszym wyborem niż dwa tygodniowe Sprinty z Daily Scrumem o dziewiątej rano.
Scrum nie jest dla wszystkich i nie musi być. Jeśli zastanawiasz się, czy twoja organizacja jest gotowa na to, co naprawdę niesie ze sobą wdrożenie, zacznij od tej lektury, zanim podejmiesz decyzję.
Pytanie, które zwykle zadaje się za późno, brzmi mniej więcej tak: czy organizacja jest gotowa działać inaczej niż działała do tej pory? Nie inaczej na tablicy w Jirze. Inaczej naprawdę.
Źródła
- Schwaber K., Sutherland J., “Scrum Guide”, scrumguides.org, 2020.
- Kniberg H., Ivarsson A., “Scaling Agile @ Spotify”, blog.crisp.se, 2012.
- Standish Group, CHAOS Report, cykliczne wydania.
- Ringelmann M., badania nad efektem próżniactwa społecznego, 1913.
Zdjęcie: Alexas_Fotos / Pixabay
