W 1968 roku NATO zorganizowało konferencję w Garmisch-Partenkirchen, żeby nazwać problem, który dusił branżę od dekady. Oprogramowanie rosło w złożoności szybciej niż zdolność zespołów do jego opanowania, a projekty padały jeden po drugim z tego samego powodu: ktoś planował wszystko na początku, potem przez osiemnaście miesięcy budował zgodnie z planem i na końcu dostarczał coś, czego nikt już nie potrzebował. Ta konferencja ukuła termin “kryzys oprogramowania”. Odpowiedzią na ten kryzys okazała się iteracja, choć do powszechnego użycia weszła dopiero kilkanaście lat później.
Czym jest iteracja – definicja, której nikt nie lubi czytać
Iteracja to powtarzalny cykl: planujesz mały kawałek pracy, robisz go, sprawdzasz co wyszło, wyciągasz wnioski i zaczynasz od nowa z poprawioną wiedzą. W Scrum Guide Schwabera i Sutherlanda z 2020 roku Sprint to iteracja trwająca od jednego do czterech tygodni, po której zespół ma działający przyrost produktu. W SAFe te same zasady działają na poziomie Program Increment, czyli kwartałów. W XP mówi się po prostu o iteracji bez specjalnej nazwy. Różne słowa, ten sam mechanizm.
Skąd pomysł, że warto w ogóle tak pracować? Walter Shewhart w Bell Telephone Laboratories w latach 20. XX wieku zaproponował cykl Plan-Do-Check-Act jako metodę ciągłego doskonalenia produkcji. Deming spopularyzował go w Japonii w latach 50. i nikt wtedy nie myślał o oprogramowaniu, ale logika była ta sama: uczysz się przez robienie, nie przez planowanie.
Prawo Hofstadtera i problem z projektami “na jeden rzut”
Douglas Hofstadter sformułował w 1979 roku w “Godel, Escher, Bach” zasadę, która od tamtej pory nie przestała być aktualna: wszystko trwa dłużej niż się spodziewasz, nawet gdy uwzględniasz, że wszystko trwa dłużej niż się spodziewasz. To zdanie jest trochę zabawne, ale opisuje śmiertelną pułapkę projektów waterfall. Jeśli zaplanujesz osiemnaście miesięcy pracy i przez osiemnaście miesięcy nic nie pokażesz klientowi, to Prawo Hofstadtera uderzy cię z pełną mocą w ostatnim kwartale, gdy okaże się, że czegoś nie przewidziałeś w maju roku poprzedniego.
Iteracja nie sprawia, że projekty trwają krócej. Ona sprawia, że błędy wychodzą na powierzchnię po dwóch tygodniach, nie po osiemnastu miesiącach. Wyobraź sobie zespół dziesięciu programistów budujący przez rok system ERP bez żadnego pokazu pośredniego. Pierwsza prezentacja zarządowi to właściwie rodzaj hazardu: albo trafiono w cel, albo nie. Historia Standish Group CHAOS Report od lat 90. dokumentuje, że projekty realizowane metodami iteracyjnymi mają wyraźnie wyższy wskaźnik powodzenia niż te prowadzone klasycznym waterfallem – i choć konkretne liczby zmieniają się z edycji na edycję, kierunek pozostaje ten sam.
Retrospektywa – moment, który odróżnia iterację od kręcenia się w kółko
Iteracja bez refleksji to po prostu powtarzanie tych samych błędów w krótszych odcinkach czasu. Kluczowy element, który odróżnia prawdziwą iterację od udawanej, to retrospektywa – ustrukturyzowana rozmowa zespołu po każdym cyklu o tym, co poszło nie tak i co można zmienić. Scrum Guide traktuje ją jako obowiązkowe zdarzenie, nie opcjonalne ćwiczenie. W praktyce jest pierwsza do skreślenia, gdy projekt się spóźnia, co jest mniej więcej równie rozsądne jak rezygnacja z hamulców, gdy samochód jedzie za szybko.
Projekty, w których retrospekcja rzeczywiście działa, wyglądają trochę dziwnie z zewnątrz. Zespół otwarcie mówi o tym, że sprint był chaotyczny, że backlog był nieczytelny, że ktoś nie wiedział, czego się od niego oczekuje. To nie jest przyjemna rozmowa, ale to jedyna rozmowa, po której następuje poprawa. Bez niej każda iteracja startuje dokładnie z tego samego miejsca co poprzednia.
Kiedy iteracja przestaje działać
Iteracja jako koncepcja pada ofiarą własnego sukcesu. W pewnym sensie stała się tak modna, że organizacje wdrażają ją jako rytuał bez rozumienia mechanizmu, który za nią stoi. Firma robi dwutygodniowe sprinty, organizuje Sprint Review, prowadzi Daily Standup – i po roku pracy backlog jest większy niż na początku, a zespół jest zmęczony bardziej niż przy waterfallu. To nie jest problem iteracji, to problem braku sprzężenia zwrotnego między tym, czego uczy jedna iteracja, a tym, jak planuje się następną.
Brooks w “The Mythical Man-Month” z 1975 roku pisał o czymś raczej podobnym w kontekście złożoności systemów: dodawanie zasobów nie rozwiązuje problemu strukturalnego. To samo dotyczy iteracji – dodawanie sprintów nie naprawia procesu, który nie zbiera i nie przetwarza informacji z poprzednich rund. Iteracja to mechanizm uczenia się, a nie harmonogram dostaw podzielony na mniejsze kawałki.
Pozostaje pytanie, które zadaje sobie każdy project manager po pierwszym roku pracy w modelu iteracyjnym: skoro ciągle się uczysz i ciągle poprawiasz, to kiedy właściwie projekt jest skończony?
Zrodla
- Schwaber K., Sutherland J., “Scrum Guide”, scrumguides.org, 2020.
- Brooks F.P., “The Mythical Man-Month”, Addison-Wesley, 1975.
- Hofstadter D.R., “Godel, Escher, Bach: An Eternal Golden Braid”, Basic Books, 1979.
- Standish Group, “CHAOS Report”, Standish Group International, publikowany cyklicznie od 1994.
- Shewhart W.A. / Deming W.E., cykl PDCA – opisany pierwotnie w Bell Telephone Laboratories, lata 20. XX w.; spopularyzowany przez Deminga w Japonii w latach 50. XX w.
Zdjęcie: Hans / Pixabay
