Gdzieś w połowie lat dziewięćdziesiątych kierownik projektu w średniej wielkości firmie ubezpieczeniowej zebrał swój zespół na kickoffie. Rozłożył na stole harmonogram: osiem miesięcy pracy, trzy kamienie milowe, dokumentacja wymagań gruba jak Encyklopedia Britannica. Projekt miał dostarczyć nowy system obsługi polis. Osiemnaście miesięcy później nikt nie pamiętał już pierwszej wersji wymagań, bo biznes zdążył zmienić zdanie cztery razy. System powstał, ale tylko w połowie pasował do tego, czego faktycznie potrzebowali agenci. Awantura była, premii nie było.
To nie jest historia wyjątkowa. To jest historia, którą Standish Group zaczął dokumentować od swojego pierwszego raportu CHAOS w 1994 roku i dokumentuje do dziś. Projekty IT mają kłopot ze strzałką, która leci prosto od wymagań do gotowego produktu. Rzeczywistość działa inaczej, trochę jak spirala.
Co to właściwie znaczy “iteracyjny”
Proces iteracyjny to podejście, w którym praca przebiega w powtarzalnych cyklach, a każdy cykl kończy się czymś, co można zobaczyć, ocenić i poprawić przed następnym cyklem. Nie ma tu mowy o jednorazowej dostawie po osiemnastu miesiącach, kiedy okazuje się, że wymagania z dokumentu sprzed roku już nie obowiązują. Każda pętla to miniaturowy projekt, ze swoim planowaniem, realizacją i przeglądem.
Scrum Guide Schwabera i Sutherlanda ujmuje to wprost: Scrum stosuje podejście iteracyjne i inkrementalne, żeby optymalizować przewidywalność i kontrolować ryzyko. To zdanie brzmi sucho, ale kryje w sobie coś ważnego. Ryzyko nie jest eliminowane przed startem projektu, tylko kontrolowane w trakcie, przez regularne momenty, w których można powiedzieć “to nie działa, zmieńmy kurs”.
Scrum jako framework formalizuje to w Sprintach trwających od jednego do czterech tygodni. Sprint Review, czyli przegląd przyrostu, to właśnie ten moment, w którym interesariusze widzą działający kawałek produktu zamiast slajdu z wykresem Gantta. Retrospekcja po Sprincie to z kolei miejsce, w którym zespół przygląda się samemu procesowi, nie tylko produktowi. Dwie różne pętle refleksji, jedna nad tym co budujemy, druga nad tym jak to robimy.
Dlaczego waterfall wygląda tak kusząco
Podejście kaskadowe, czyli waterfall, ma tę elegancję, że wszystko jest z góry zaplanowane. Wymagania, projekt, kodowanie, testy, wdrożenie, jeden za drugim. Zarząd lubi to zobaczyć na prezentacji, bo wygląda jak mapa z zaznaczoną trasą. Problem zaczyna się wtedy, gdy ktoś musi tę mapę skonfrontować z terenem.
Frederick Brooks w “The Mythical Man-Month” z 1975 roku opisał mechanizm, który obserwował przy budowie systemu OS/360 w IBM. Opóźniony projekt nie przyspiesza po dodaniu ludzi, bo nowi członkowie zespołu potrzebują czasu na wdrożenie, a komunikacja rośnie nieproporcjonalnie. Ale Brooks dotknął też głębszego problemu: złożone projekty są z natury trudne do zaplanowania w całości na początku, bo wiedza o projekcie rośnie w trakcie jego realizacji, nie przed nią.
Prawo Hofstadtera mówi, że wszystko trwa dłużej, niż się spodziewasz, nawet jeśli uwzględnisz prawo Hofstadtera. Douglas Hofstadter sformułował to w 1979 roku i od tamtej pory każdy project manager mógł się w tym zdaniu przejrzeć jak w lustrze. Iteracyjność nie usuwa tej tendencji, ale sprawia, że błąd estymacji wychodzi na jaw po dwóch tygodniach, nie po osiemnastu miesiącach.
Jak to wygląda w praktyce
Wyobraźmy sobie 10-osobowy zespół, który dostaje zadanie zbudowania wewnętrznego portalu raportowego dla działu finansów. Przy podejściu kaskadowym przez pierwsze dwa miesiące analizują wymagania i piszą dokumentację. Przy podejściu iteracyjnym po dwóch tygodniach mają działający prototyp jednego raportu i siadają z finansami do rozmowy. Finanse mówią: “ten wykres jest bez sensu, nam chodzi o coś innego”. Korekta kosztuje tydzień pracy. W wersji kaskadowej ta sama korekta, odkryta na etapie testów po pięciu miesiącach, kosztuje przepisanie sporej części systemu.
Spotify opisał swoją odmianę podejścia iteracyjnego w 2012 roku, kiedy Henrik Kniberg i Anders Ivarsson opublikowali dokument o organizacji inżynierii. Squady działające autonomicznie, każdy z własnym rytmem pracy i możliwością szybkiej zmiany kierunku. Tribes, czyli grupy powiązanych squadów, jako warstwa koordynacji. Model ten jest teraz cytowany przez firmy na całym świecie, choć sam Spotify wielokrotnie podkreślał, że to był opis pewnego momentu w ich historii, nie gotowy przepis do skopiowania.
Manifest Agile z 2001 roku, podpisany przez 17 praktyków w Snowbird w stanie Utah, skodyfikował to, co wielu z nich robiło intuicyjnie od lat. Działające oprogramowanie ponad wyczerpującą dokumentację, reagowanie na zmiany ponad realizację planu. Iteracyjność jest w tym podejściu wbudowana, bo bez krótkich pętli zwrotnych nie ma sensu mówić o reagowaniu na zmiany.
Czy to znaczy, że każdy projekt powinien działać w dwutygodniowych Sprintach? Niekoniecznie. Są projekty infrastrukturalne, migracje danych, wdrożenia ERP, gdzie iteracyjność wygląda zupełnie inaczej niż w Scrumie, ale zasada pozostaje ta sama. Sprawdzaj jak najwcześniej, koryguj jak najtaniej. Zanim w ogóle sięgniesz po Scruma, warto wiedzieć, czego naprawdę wymaga od organizacji, bo iteracyjność bez kultury feedbacku to tylko zmieniona nazwa na tym samym chaosie.
Przy okazji warto pamiętać, że teoria optymalizacji procesów to nie jest oddzielny świat od iteracyjności. Procesy iteracyjne i ich doskonalenie to dwie strony tej samej monety. A jeśli zastanawiasz się, jak te mechanizmy wpisują się w szersze zarządzanie usługami IT, to ta rozmowa jest warta oddzielnego artykułu.
Spirala zamiast strzałki nie jest przyznaniem się do bałaganu. To po prostu uczciwy opis tego, jak naprawdę powstaje wiedza o tym, co budujemy. Pytanie nie brzmi, czy chcemy pracować iteracyjnie, tylko ile razy możemy sobie pozwolić na to, żeby dowiedzieć się za późno.
Źródła
- Brooks F.P., “The Mythical Man-Month”, Addison-Wesley, 1975.
- Schwaber K., Sutherland J., “Scrum Guide”, scrumguides.org, 2020.
- Beck K. i in., “Manifesto for Agile Software Development”, agilemanifesto.org, 2001.
- Hofstadter D., “Gödel, Escher, Bach: An Eternal Golden Braid”, Basic Books, 1979.
- Kniberg H., Ivarsson A., “Scaling Agile @ Spotify”, blog.crisp.se, 2012.
- Standish Group, “CHAOS Report”, pierwsza edycja 1994, wydania cykliczne.
Zdjęcie: Serhat Beyazkaya / Unsplash
