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 Retrospekcji Sprintu. Powiedziała, że jest to zgrany Zespół, ludzie pracują ze sobą już od dawna, znają swoje możliwości i przywary – nie wydaje się, by Retrospekcja 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ń i podejmuje je na bieżąco – jak więc pomoże w tym zdarzenie, które odbywa się 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 Retrospekcji Sprintu.

Degradacja Scruma krok po kroku

Scrum jest metodą prostą do zrozumienia (choć czasami mam wątpliwości co do prawdziwości tego stwierdzenia), ale nierzadko 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. Jej poprawne użycie wymaga odwagi, by powiedzieć, jaka jest rzeczywistość, nazwania problemów, zmierzenia się z nimi. 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 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 zaczynamy korzystać ze 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 udaje się budować 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 i dalszy ich rozwój jest po prostu niemożliwy. Jeszcze gdzie indziej wydaje się, że kolejne 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 Retrospekcja 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 Retrospekcji. Następnym zdarzeniem jest Daily Scrum, potem zaczyna się erozja odpowiedzialności. Wreszcie rozmywać zaczynają się granice Sprintów, Planowanie Sprintu przestaje się odbywać, bo Zespół planuje just-in-time, wreszcie znika i 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.

Retrospekcja Sprintu 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 Retrospekcje 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ść Retrospekcji 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 Retrospekcji Sprintu. Służy ona empirycznemu usprawnianiu procesu, a zatem prowadzić ma do doskonalenia narzędzi, komunikacji, sposobu działania, praktyk, wreszcie podnoszenia kwalifikacji. Nie powinna być nastawiona na poszukiwanie tego, co działa źle i (wbrew nazwie) na 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ę schematy przebiegu Retrospekcji proponowane przez różne książki i źródła w Internecie, łatwo zauważyć, że zbieranie obserwacji to jedynie punkt wyjścia i ustalenie, jaki jest stan spraw, a nie cel sam w sobie. Kolejne kroki to poszukiwanie obszarów do usprawnień, w tym również 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 Retrospekcji 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ć jaką pozytywną zmianę przyniesie jego realizacja, 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 – 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 artykuł. 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: Retrospekcji Sprintu. Nie potrafili użyć jej jako narzędzia do świadomego stymulowania swojego rozwoju i zmiany rzeczywistości, w jakiej funkcjonowali.

Jako Agile coach nie dałem rozmówczyni gotowych rozwiązań – prawdę mówiąc za mało wiedziałem wtedy o tym Zespole i organizacji. 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 Retrospekcja nie służy wyłącznie rozwiązywaniu problemów, wskazałem obszar do tej pory nieeksplorowany przez ten Zespół. Chodzi oczywiście o eksperymentowanie z nowymi podejściami i sprawdzenie, co mogą Zespołowi dać. I robienie tego nie dlatego, że jest to konieczne, ale dlatego, że ludzie chcą się rozwijać.

Tu przypomnę o tym, że Retrospekcja Sprintu 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 coś nowego, co może dać nam nowe możliwości albo nauczyć nas czegoś. Kłania się nam stary, dobry eksperyment, którego rezultat (pozytywny lub negatywny) będzie stymulujący.

Forma ma znaczenie

Czynnikiem zabójczym dla wszelkiego rodzaju zdarzeń procesowych jest znudzenie. Jeśli każda Retrospekcja 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 Retrospekcja 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ą Retrospekcję Sprintu

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, co jest celem Retrospekcji Sprintu (w Scrumie dostarczenie takiej wiedzy Zespołowi jest obowiązkiem Scrum Mastera). Równie ważne jest dbanie o to, by każda Retrospekcja dawała mierzalne, odczuwalne rezultaty. Nic bowiem nie motywuje do działania lepiej niż świadomość, że realizujemy to, co sami zaplanowaliśmy i przynosi nam to korzyści.