W 2018 roku w Warszawie na spotkaniu Project Management Association ktoś zapytał prelegenta, ile firm rzeczywiście kończy wdrożenie Scruma sukcesem. Odpowiedź była brutalna: może połowa. Może mniej. Nikt dokładnie nie wie, bo większość organizacji woli nie mówić głośno, że zainwestowała pół roku w wprowadzenie metodologii, która skończyła się na trzech Sprintach i powrotem do tego, co było.
Wdrażanie Scruma to nie kurs certyfikacyjny, nie dwudniowe warsztaty i nie nowy szablon w Jirze. To próba zbudowania maszyny, która działa inaczej niż wszystko, co firma znała wcześniej. I w większości przypadków kończy się tak, jak próba nauczenia słonia tańca breakdance.
Dlaczego wdrożenie Scruma wygląda jak ceremonia pogrzebowa
Fred Brooks w latach 70. napisał w „The Mythical Man-Month”, że dodawanie ludzi do spóźnionego projektu tylko go opóźnia. Melvin Conway już w 1968 roku pokazał, że organizacja projektuje systemy będące kopią jej struktury komunikacji. Obie te prawdy spotykają się w jednym punkcie: sposób, w jaki ludzie ze sobą rozmawiają, określa to, co zbudują.
Scrum w teorii brzmi prosto. Pięć wydarzeń: Sprint, Sprint Planning, Daily Standup, Sprint Review, Sprint Retrospective. Trzy role: Product Owner, Scrum Master, Development Team. Trzy artefakty: Product Backlog, Sprint Backlog, Increment. To wszystko jest opisane w oficjalnym Scrum Guide, który Ken Schwaber i Jeff Sutherland aktualizują od 2010 roku.
W praktyce wdrożenie wygląda tak: zespół dostaje polecenie, że od poniedziałku „pracujemy w Scrumie”. Ktoś wykupuje licencję Jiry. HR wysyła maila o obowiązkowych Daily Standupach o 9:00. I nagle okazuje się, że nikt nie wie, kto jest Product Ownerem, bo Product Manager ma siedem innych projektów, a Development Team składa się z ludzi rozrzuconych po trzech działach, którzy nigdy wcześniej ze sobą nie pracowali.
Sprint Planning trwa sześć godzin, bo każdy User Story wymaga akceptacji czterech osób z czterech różnych działów. Daily Standup zamienia się w raportowanie do managera, który siedzi w kącie i notuje, kto ile zrobił. Sprint Review to prezentacja PowerPoint dla dyrektora, który po dwóch slajdach pyta, dlaczego jeszcze nie ma funkcji X. Retrospective? Nie ma czasu, bo trzeba zacząć kolejny Sprint.
Gdzie to wszystko się sypie
Badania nad efektem Ringelmanna pokazują, że ludzie w grupach pracują mniej efektywnie niż sami. Dodaj do tego Prawo Conwaya i masz sytuację, w której zespół próbujący pracować cross-functionally natrafia na strukturę organizacyjną podzieloną na silosy. Frontend raportuje do jednego managera, backend do drugiego, design do trzeciego. Jak ma działać zespół, który teoretycznie jest autonomiczny, ale każdy jego członek dostaje zadania z innego miejsca?
W 2023 roku w British Computer Society opublikowano raport o tym, że projekty stosujące praktyki Agile Manifesto mają wyższy wskaźnik niepowodzeń niż te, które w ogóle nie używają żadnej metodologii. Brzmi absurdalnie, ale ma sens: gorsze niż brak metodologii jest jej połowiczne wprowadzenie. Zespół dostaje ceremonię, ale nie autonomię. Dostaje Backlog, ale nie prawo do podejmowania decyzji. Dostaje Daily Standup, ale nie możliwość powiedzenia „nie”.
I jeszcze jedno: ludzie nie lubią zmian. Szczególnie gdy te zmiany wymagają, żeby przestali robić to, co robili przez ostatnie dziesięć lat. Manager, który przez lata rozliczał zespół z godzin, nagle ma przestać? Developer, który zawsze dostawał szczegółowe specyfikacje, ma sam decydować, jak coś zrobić? Product Manager, który zarządzał pięcioma produktami, ma się skupić na jednym?
Czy da się to zrobić dobrze?
Czasami. W 2019 roku firma informatyczna w Krakowie wdrożyła Scruma w zespole, który tworzył nowy produkt od zera. Przez trzy miesiące nie wypuścili ani jednej funkcji. Management wściekał się. Ale zespół konsekwentnie budował infrastrukturę, automatyzację testów, pipeline CI/CD. Po czwartym Sprincie zaczęli dostarczać funkcje co tydzień. Po roku mieli najszybszy czas wdrożenia w całej firmie.
Co zrobili inaczej? Po pierwsze, dostali prawdziwą autonomię. Product Owner miał mandat do odrzucania próśb stakeholderów. Scrum Master nie był notującym sekretarzem, tylko osobą, która blokowała zewnętrzne zakłócenia. Development Team składał się z ludzi, którzy nie mieli innych zobowiązań.
Po drugie, nie próbowali wdrożyć Scruma w całej firmie naraz. Zaczęli od jednego zespołu, jednego produktu. Przez pół roku reszta organizacji patrzyła na nich jak na dziwadła. Ale gdy zaczęli dostarczać, inni przyszli sami.
Po trzecie, mieli czas. Nie oczekiwano, że po dwóch tygodniach wszystko będzie działać perfekcyjnie. Pierwsze Retrospectives trwały po trzy godziny, bo ludzie musieli się nauczyć rozmawiać szczerze. Pierwsze Sprint Planningi kończyły się kłótniami o to, co znaczy „Done”. Ale nikt nie powiedział „wracamy do starego”, bo management dał im przestrzeń na porażki.
Czy warto w ogóle próbować?
Jeśli firma nie jest gotowa na to, żeby oddać kontrolę, nie ma sensu udawać, że wdraża Scruma. Jeśli management chce mieć raportowanie co dwa tygodnie, ale nie chce dać zespołowi prawa do decydowania, lepiej zostać przy Waterfall i nie tracić czasu.
Jeśli organizacja ma strukturę, w której każdy developer raportuje do innego managera, każdy designer do innego dyrektora, a każdy tester do jeszcze innego VP, Scrum nie zadziała. Można wprowadzić ceremonie, można nazwać coś Sprintem, ale to będzie tylko nowa warstwa biurokracji na starym sposobie pracy.
Ale jeśli firma jest gotowa na rzeczywistą zmianę — jeśli jest gotowa na to, że przez pierwsze miesiące będzie wolniej, że będą błędy, że trzeba będzie zmienić sposób, w jaki ludzie raportują i podejmują decyzje — to Scrum może zadziałać. Nie dlatego, że to magiczna metodologia. Ale dlatego, że zmusza ludzi do rozmowy, do transparentności, do przyznawania się do błędów. A to jest coś, czego większość organizacji nie robi nigdy.
Źródła
- Schwaber K., Sutherland J., „Scrum Guide”, scrumguides.org, 2020.
- Brooks F.P., „The Mythical Man-Month”, Addison-Wesley, 1975.
- Conway M.E., „How Do Committees Invent?”, Datamation, 1968.
Zdjęcie: cottonbro studio / Pexels
