Blog

Na początku tego roku Scrum Masterka w jednym z zespołów, z którym rozpoczynałem współpracę jako Agile Coach, opowiedziała mi o problemie z organizowaniem retrospektyw na koniec sprintu. Bo jest to zgrany team, ludzie pracują ze sobą już od dawna, znają swoje możliwości i przywary – nie wydaje się, by retrospektywa miała ujawnić cokolwiek, o czym jeszcze nie wiedzą. Z drugiej strony zespół jest dojrzały (a przynajmniej przekonany o własnej dojrzałości) i nie zamierza zwlekać z dokonywaniem usprawnień, tylko podejmuje je na bieżąco, więc jak pomoże w tym retro na koniec sprintu?

Rozmówczyni liczyła na radę, co zrobić w tej sytuacji. Całkiem serio obawiała się, że jedno z kluczowych zdarzeń scrumowych nie będzie się odbywać, lub realizowane będzie na odczepnego. Czy pomogłem? Do tego wrócę, najpierw skupmy się na problemie „umierającej” retrospektywy.

Degradacja Scruma krok po kroku

Scrum jest metodą prostą do zrozumienia (choć czasami mam wątpliwości co do prawdziwości tego stwierdzenia), ale trudną w praktycznym stosowaniu. Nie dlatego, że jest niepraktyczny – wręcz przeciwnie, wyrósł z doświadczeń jego twórców głównie w domenie wytwarzania oprogramowania. Trudność w stosowaniu Scruma bierze się z konieczności usuwania dysfunkcji i problemów, które ta metoda w bezwzględny sposób ujawnia, żeby nie powiedzieć obnaża. To wymaga odwagi do powiedzenia, jaka jest rzeczywistość, nazwania problemu, zmierzenia się z nim. Są organizacje, które zwalniają pracowników za takie „sianie defetyzmu” i tam Scrum nie ma szans zadziałać.

Są jednak sytuacje, gdzie organizacja opieszale i bez przekonania, ale wspiera dokonywanie usprawnień, a mimo to maksimum tego, co udaje się osiągnąć, to tak zwany mechanistyczny Scrum. Są w nim wszystkie elementy metody, ale żaden z nich nie pełni funkcji, dla której został zdefiniowany.

Schemat jest mniej więcej taki: pełni entuzjazmu wprowadzamy Scruma, gotowi na poniesienie kosztów związanych z nauczeniem się jak go stosować. Jest determinacja, by dbać o przejrzystość, by dążyć do maksymalnej zgodności z definicją metody, eliminować zauważone niedociągnięcia i dysfunkcje. Dużo się dzieje, głównie na poziomie zespołów, często zresztą to one są głównym inspiratorem wprowadzenia metody zwinnej w organizacji.

Gdy już rozwiąże się najpoważniejsze problemy, gdy proces pozwala otrzymywać działający produkt praktycznie co sprint, gdy nie zdarzają się spektakularne wpadki – przychodzi stagnacja. Ma ona różne przyczyny: w niektórych zespołach pojawia się przekonanie, że działają już na tyle dobrze, że pora przyspieszyć prace nad produktem a dalsze usprawnianie to strata czasu; w innych pojawia się przekonanie, że stały się w pełni dojrzałe; jeszcze gdzie indziej wydaje się, że dalsze usprawnienia są niemożliwe bez fundamentalnych zmian w organizacji – a to jest poza zasięgiem pojedynczego zespołu.

Dlatego zazwyczaj pierwszym elementem Scruma, jaki „umiera” jest retrospektywa sprintu. Niezależnie od przekonań członków zespołu, kontekstu organizacyjnego, jaki do tego prowadzi, jeśli Scrum zaczyna się psuć, to najczęściej właśnie od retrospektyw. Następnym zdarzeniem jest Daily Scrum, potem zaczyna się erozja ról i związanych z nim odpowiedzialności. Wreszcie rozmywać zaczynają się granice sprintów, planowanie zaczyna być robione „on the fly”, podobnie przegląd sprintu… Wraz z zanikającym empiryzmem pojawia się wtedy radosna myśl, że „lepszą metodą dla nas byłby Kanban”, choć tak naprawdę to desperacka próba ucieczki przed przyznaniem, że właśnie pochowaliśmy zwinność w płytkim grobie.

Kurtyna, wieńce.

Retrospektywa to nie pręgierz

Gdy podłubie się w tym, co zostało ze Scruma tak potraktowanego, najczęściej wyciągnie się na powierzchnię brutalną prawdę: od samego początku retrospektywy były traktowane jako mechanizm do naprawiania błędów i usuwania problemów. W miarę jak ilość pierwszych i dolegliwość drugich malała, zdarzenie stawało się coraz mniej przydatne dla zespołu. Albo, będąc bardziej precyzyjnym, wartość retrospektyw realizowanych w tym celu zaczęła być niewarta poświęcanego na nie czasu i wysiłku.

Odpowiedzialnością Scrum Mastera jest zapewnienie, że zespół będzie rozumiał cel retrospektywy sprintu. Ma ona służyć empirycznemu usprawnianiu procesu, a zatem prowadzić do doskonalenia narzędzi, komunikacji, sposobu działania, praktyk, wreszcie podnoszenia kwalifikacji. Nie powinna być nastawiona na poszukiwanie negatywów i (wbrew nazwie) oglądanie się wstecz. Należy poszukiwać możliwości, patrzyć do przodu, określać cele, ku którym świadomie będziemy zmierzać małymi kroczkami.

Jeśli przejrzy się proponowane przez różne książki i źródła w Internecie schematy retrospektyw łatwo zauważyć, że zbieranie obserwacji to jedynie punkt wyjścia, ustalenie jaki jest stan spraw. Kolejne kroki to poszukiwanie obszarów do usprawnień, możliwych zmian tego, co już być może jest dobre, ale może być lepsze.

Trzeba mierzyć siły na zamiary

Krytyczna ocena wartości retrospektyw rośnie, jeśli nie dają one rezultatów odczuwalnych i mierzalnych dla zespołu. Dlatego tak ważne jest, by dla każdego usprawnienia określić „co nam to da”, najlepiej wraz ze sposobem zmierzenia, że oczekiwana wartość rzeczywiście się pojawiła.

Wciąż jednak pojawiać będą się obszary możliwych usprawnień tak ogromne, że zespół w pojedynkę, w czasie jednej czy dwóch iteracji niczego nie zdoła zmienić. Co wtedy? Pamiętając, że nawet najdłuższa podróż rozpoczyna się od pierwszego kroku, dokładnie tak samo powinniśmy postąpić. Chcemy dokonać przełomowej, ogromnej zmiany, która może trwać długo – więc od czegoś trzeba zacząć. Co będzie tym pierwszym krokiem? Pierwszym etapem?

Inspect & Adapt

Wróćmy do rozmowy ze Scrum Masterką, od której rozpocząłem ten wpis. Jej zespół być może był wtedy bardzo dojrzały, być może zgrany, być może rzeczywiście potrafił dokonywać usprawnień na bieżąco, jednej rzeczy wszakże robić dobrze nie potrafił. Tak, zgadliście: retrospektyw. Nie potrafili użyć tego narzędzia aby świadomie stymulować swój dalszy rozwój i zmieniać rzeczywistość, w jakiej funkcjonowali.

Jako Agile Coach nie dałem rozmówczyni gotowych rozwiązań, bo prawdę mówiąc za mało wiedziałem wtedy o tym zespole i organizacji. Ale zadałem pytania, które i ona mogła wykorzystać w rozmowie z zespołem, aby sprowokować go do poszukiwania odpowiedzi. A podpowiadając, że retrospektywa nie służy wyłącznie rozwiązywaniu problemów, wskazałem inny obszar, do tej pory nie eksplorowany przez ten zespół: zróbmy coś nowego i zobaczmy, co nam to da; zróbmy to nie dlatego, że musimy, ale dlatego, że możemy i chcemy.

Tu przypomnę o tym, że retrospektywa jest mechanizmem dającym zespołowi jego dedykowaną dawkę empiryzmu. Dlatego dobrze jest omawiać, co się zdarzyło, dobrze jest analizować potknięcia i niedociągnięcia, ale czasami należy po prostu zrobić coś, co nie wynika z tego, co już robiliśmy, ale może dać nam nowe możliwości, nauczyć nas czegoś. Kłania się nam stary, dobry eksperyment, którego rezultat (pozytywny lub negatywny) będzie stymulujący.

Forma ma znaczenie

Niedocenianym, ale zabójczym dla wszelkiego rodzaju zdarzeń procesowych (nie tylko retrospektyw) czynnikiem jest znudzenie nimi. Jeśli każda retrospektywa sprintu wygląda tak samo, prowadzi ją zawsze ta sama osoba, a zdarzenie jest do bólu przewidywalne, ciężko wykrzesać z uczestników jakąkolwiek iskierkę motywacji do działania.

Dlatego należy zmieniać formułę zdarzenia: sposób prowadzenia, miejsce w jakim retrospektywa się odbywa, prowadzącego. Korzystajmy z książek, artykułów w sieci, poradników, konferencji, i wykorzystujmy poznane w ten sposób techniki, ćwiczenia, gry integracyjne. Wymyślajmy własne, jeśli potrafimy.

Przepis na dobrą retrospektywę

Podsumowując:

1. Poszukujmy usprawnień, nie problemów do rozwiązania.
2. Dokonujmy dużych usprawnień małymi kroczkami, iteracyjnie i inkrementalnie (brzmi znajomo, prawda?).
3. Eksperymentujmy, róbmy rzeczy nowe, poszukujmy możliwości.
4. Dbajmy o formę, aby zaangażowania nie wyparło znudzenie.

Natomiast elementem najbardziej podstawowym jest wyjaśnienie, czemu retrospektywy służą (w Scrumie jest to wręcz obowiązkiem Scrum Mastera) i dbanie, by każda dawała mierzalne, odczuwalne rezultaty. Nic bowiem nie motywuje do działania lepiej niż świadomość, że realizujemy to, co sami zaplanowaliśmy.