Wyobraźmy sobie retrospektywę po szóstym sprincie. Zespół siedzi w sali, Scrum Master pyta, co poszło nie tak, a wszyscy patrzą w sufit. Product Owner milczy, bo właśnie dowiedział się, że połowa backlogu jest nieaktualna. Ktoś w końcu mówi: „chyba za rzadko rozmawiamy o tym, co naprawdę się dzieje”. I tu jest clue: Scrum Guide od 2010 roku mówi dokładnie to samo, tylko innymi słowami. Ken Schwaber i Jeff Sutherland opisują trzy filary, na których stoi cały framework, a przynajmniej powinien stać. Przezroczystość, inspekcja, adaptacja. Brzmi jak slogan z banera na konferencji agile, ale za każdym z tych słów kryje się konkretny mechanizm, który albo działa, albo nie działa, i wtedy sprint po sprincie sypie się coraz więcej.
Przezroczystość, czyli kto naprawdę wie, co się dzieje
Scrum Guide (aktualna wersja pochodzi z 2020 roku) definiuje przezroczystość jako wymóg, by wyłaniający się proces i praca były widoczne zarówno dla tych, którzy ją wykonują, jak i dla tych, którzy z niej korzystają. W teorii jest to oczywiste. W praktyce wygląda to mniej więcej tak: Product Backlog istnieje, ale jest dostępny tylko dla Product Ownera, Daily Scrum odbywa się za zamkniętymi drzwiami, a Definition of Done to dokument, który ktoś skopiował z internetu i nikt nigdy nie sprawdził, czy zespół go stosuje.
Przezroczystość jest raczej trudna do utrzymania nie dlatego, że ludzie kłamią, ale dlatego, że organizacje nagradzają pozory postępu. Jeśli status na tablicy Jira zawsze świeci zielono, a kierownik dostaje raporty, które wyglądają dobrze, to nikt nie ma interesu, żeby psuć ten obraz. Problem pojawia się przy Sprint Review, kiedy ktoś pyta o działający inkrement i okazuje się, że „prawie gotowe” to trochę inaczej niż gotowe. Wyobraźmy sobie ośmioosobowy zespół, który przez trzy sprinty raportował postęp na 80 procentach, po czym przy deliveries okazało się, że integracja z zewnętrznym API w ogóle nie była testowana. Osiem tygodni pozornej przezroczystości.
Inspekcja, czyli patrzenie na to, co naprawdę jest
Drugi filar to inspekcja, a Scrum Guide wyposażył nas w cztery formalne momenty, w których powinna się ona odbywać: Sprint Planning, Daily Scrum, Sprint Review i Sprint Retrospective. Cztery eventy, każdy z określonym celem. Daily Scrum to 15 minut, nie status meeting. Sprint Review to inspekcja inkrementu ze stakeholderami, nie prezentacja PowerPointa z wykresem Burndown. Retrospective to inspekcja sposobu pracy zespołu, nie sesja narzekania przy kawie.
Problem w tym, że te cztery eventy bardzo łatwo zamienić w rytuał bez treści. Daily Scrum, w którym każdy po kolei recytuje trzy zdania do Scrum Mastera, a potem wraca do Slacka i robi swoje, spełnia formalne wymagania i nie spełnia żadnego innego. Jeff Sutherland pisał o tym w kontekście tego, co sam nazywał „zombie Scrumem” – frameworku, który zachowuje formę, ale traci sens. Inspekcja wymaga odwagi zadawania pytań, które są niewygodne, i co ważniejsze, wymaga, żeby odpowiedzi miały jakieś konsekwencje. Jeśli Sprint Review kończy się zawsze słowami „super, jedziemy dalej”, to albo wszystko faktycznie jest w porządku, albo nikt naprawdę niczego nie sprawdza.
Jeśli zastanawiasz się, jak w ogóle ocenić gotowość organizacji do prowadzenia Scruma zanim zaczniesz, warto przeczytać: Zanim wdrożysz Scruma, upewnij się że jesteś gotowy na porażkę.
Adaptacja, czyli zmiana, zanim jest za późno
Trzeci filar jest w pewnym sensie wypadkową dwóch poprzednich. Jeśli nie ma przezroczystości, inspekcja jest ślepa. Jeśli inspekcja jest ślepa, adaptacja nie ma podstaw. Scrum Guide mówi wprost: gdy inspekcja wykryje odchylenie poza dopuszczalne granice, które sprawi, że produkt będzie nieakceptowalny, trzeba dostosować proces lub materiał jak najszybciej. To zdanie brzmi biurokratycznie, ale kryje w sobie coś zasadniczego: Scrum nie zakłada, że plan będzie dobry. Zakłada, że plan będzie zły i że to jest normalne, jeśli tylko reaguje się wystarczająco szybko.
Adaptacja jest trudna, bo wymaga przyznania, że coś nie działa. W organizacjach, gdzie Scrum jest wdrożony głównie po to, żeby można było powiedzieć, że się jest agile, adaptacja zatrzymuje się na poziomie kolorów w Jirze. Backlog refinement przynosi nowe story pointy, ale nikt nie pyta, czy w ogóle buduje się właściwą rzecz. Sprint Retrospective generuje listę action items, która ląduje w Confluence i nikt do niej nie wraca przed następną retrospektywą. Trzy sprinty po trzech tygodniach każdy to dziewięć tygodni bez realnej zmiany, a to już prawie kwartał, w którym organizacja przekonuje siebie, że pracuje w sposób adaptacyjny.
Te trzy filary to raczej nie ozdobnik teorii empirycznej, to mechanizm sprzężenia zwrotnego. Przezroczystość dostarcza danych, inspekcja je interpretuje, adaptacja wyciąga wnioski. Jeśli jedno z ogniw jest zepsute, reszta systemu pracuje w ciemno. Widziałem projekty, które miały Scrum Mastera z certyfikatem PSM I, backlog w Jirze i Daily Scrum o 9:30, a mimo to dostarczyły produkt po osiemnastu miesiącach zamiast po sześciu. Nie brakowało im ceremonii, brakowało im sprzężenia zwrotnego. Ciekawostka: ten sam mechanizm opisuje się w kontekście czterech filarów zarządzania projektami IT, gdzie pętla kontrolna jest równie fundamentalna jak w Scrumie.
Pytanie, które warto postawić przed każdą retrospektywą, brzmi nie tyle „co możemy poprawić”, ile „czy w ogóle wiemy, co naprawdę się tutaj dzieje”. A jeśli nie wiadomo, to pierwszy filar właśnie się posypał.
Źródła
- Schwaber K., Sutherland J., „Scrum Guide”, scrumguides.org, 2020.
Zdjęcie: Janzen_5050_Creations / Pixabay
