Czego nie lubimy w Scrumie?

Nie raz słyszałem, że najbardziej nielubianą częścią Scruma i najchętniej pomijaną jest Retrospekcja.

Dlaczego?

Bo to moment, w którym wychodzą na jaw słabości naszego zespołu.

Zacznijmy od wyjaśnienia.

Po co nam Retrospekcja w Scrumie?

Scrum składa się z odpowiedzialności, wydarzeń i artefaktów. W ramach Retrospekcji proces, w którym pracujemy, zespół oraz narzędzia, z których korzystamy poddajemy inspekcji i adaptacji. Można to lepiej zrozumieć, jeśli pomyślimy sobie o sytuacji, w której naszym produktem jest ogród, zespołem ekipa, która nam go realizuje, a procesem wszystko to, co ma miejsce w trakcie wykańczania ogrodu. A zatem na Retrospekcji nie chcemy rozmawiać o tym, że rabaty z kwiatami finalnie powinny być nieco większe, a konstrukcję tarasu możnaby pomalować ciemnobrązowym lakierem (to są kwestie związane z kształtem produktu, o których rozmawiamy na Sprint Review), tylko o tym, że np. połamała nam się łopata, właściciel nieruchomości wpuszcza nas do pracy dopiero od 10:00, a Zdzichu (jeden z Developerów) znowu jest odrywany od pracy przez innego klienta, który zawraca mu głowę.

Retrospekcja niekoniecznie na miękko

Biznes lubi konkretne, liczbowe wartości. Dlatego może patrzeć na Retrospekcje zespołów jako przepalanie pieniędzy.

To, o czym za chwilę przeczytasz może też być argumentem dla nieprzekonanych członków zespołu.

Skuteczność retrospekcji jest mierzalna. I warto z tej cechy korzystać.

Możemy użyć twardych metryk

• zredukowanie liczby awarii,
• konkretny zysk z tytułu wdrożenia nowych rozwiązań,
• spadek bounce rate’u na serwisie.

Zauważ , że skupiamy się na celach biznesowych. Nie ustawiamy tutaj celu np. na wzrost velocity zespołu, bo samo velocity nie mówi nam nic o wartości, jaką ten zespół generuje.

Usprawnienia

Żeby dokładniej zrozumieć ideę Retrospekcji to powinienem powiedzieć Ci jeszcze o jej celu. To NIE jest szukanie winnych, to JEST poszukiwanie okazji do usprawnień.

Te możesz wprowadzać w formie eksperymentów.

Przykładowo polecam skorzystać z zasady “Two bites”.

Wdrażamy nasz pomysł na usprawnienie i korzystamy z niego przez dwa najbliższe Sprinty. Dopiero wtedy, na kolejnym Retro wspólnie je oceniamy.

Chodzi o to, żeby złapać pełniejszy obraz tej praktyki, a nie oceniać ją zbyt pochopnie.

“Complex problems don’t have simple or obvious solutions. Befor you make a major investment in particular solution, make sure that you understand the problem and have a viable solution for fixing it.” – Mastering Professional Scrum, Reindl Simon

“To move forward without being paralyzed by […] unknowns, you can try some experiments to see what might work or to gather information.” – Mastering Professional Scrum, Reindl Simon

Eksperymenty

W jaki sposób możesz razem z zespołem podejść do tego typu eksperymentów? Poniżej przedstawiam Ci kolejne kroki do zastosowania:

1. Zidentyfikujcie problem, który staracie się rozwiązać w zespole. Pomoże tutaj analiza root cause (np. 5xWhy).
2. Stwórzcie hipotezę wokół rozwiązania (“Zakładamy, że XYZ pomoże nam zlikwidować ABC…”).
3. Ustalcie, w jaki sposób przetestujecie tę hipotezę.
4. Odpalcie eksperyment (uwaga! musicie na to znaleźć przestrzeń w Sprincie – porozmawiajcie o tym na Planowaniu Sprintu).
5. Przeanalizujcie rezultaty eksperymentu
   1. Udało się poprawić sytuację?
   2. Na co liczyliście?
   3. Co udało się zmienić?
6. Ustalcie dalsze kroki.
   1. Czy coś należy poprawić w eksperymencie?
   2. Czy wypracowane rozwiązanie utrzymujecie, czy jednak z niego rezygnujecie?

Dobrym pomysłem może być utworzenie backlogu usprawnień. Jest to praktyka poboczna w stosunku do Scruma, ale pozwoli Wam utrzymywać historię usprawnień, które wdrożyliście lub chcecie wdrożyć. To zwiększy transparentność i po prostu ułatwi Wam życie 🙂

“In the same way that Scrum uses an empirical approach to solve complex problems and deliver valuable products, you can use an empirical approach to solve complex problems and maximize the benefits of Scrum. You can do this at the Scrum Team level and at other levels of the organization beyond the Scrum Team. For an individual Scrum Team, this cycle of continues improvement is already built into the cadence of a Sprint and the use of a Sprint Retrospective to inspect and adapt as a Scrum Team. In addition, it is up to each Scrum Team to determine the amount of time that needs to be devoted to improvement each Sprint and how to organize and validate the improvements made each Sprint.” – Mastering Professional Scrum, Reindl Simon

Jak ta retrospekcja ma przebiegać?

Jeśli zastanawiasz się jak zorganizować dobrą, efektywną retrospekcję to polecam się do niej po prostu przygotować. Możesz sobie zapisać poniższy fragment tego artykułu i korzystać z niego podczas wydarzenia.

• Przed Retro możemy jako SMowie przeanalizować konkretne rzeczy, które miały miejsce w tym Sprincie:
  • jakie PBI (Product Backlog Item) nie dojechały,
  • z czym konkretnie mieliśmy największy problem,
  • jak wygląda burndown chart.

Warto sobie wszystko wypisać przed startem retrospekcji. Chodzi o to, żeby nie przypominać sobie tych rzeczy w trakcie trwania spotkania, kiedy jesteśmy skupieni na facylitacji.

• Retro rozpoczynamy od otworzenia i przypomnienia, jaki jest cel tego eventu, ile mamy czasu i czym będziemy się zajmować. Dobra praktyką jest przypomnieć zespołowi, że Retro to event zespołowy i okazja do zmienienia i poprawiania sposobu w jaki pracujemy.
• Jeżeli mamy przed sobą tematy mocno emocjonalne, to warto skorzystać z odpowiednich technik jak np.: “Check In” z The Core Protocols.

Struktura Retrospekcji

Teraz będzie ten fragment, który możesz zastosować podczas retrospektywy. Jest to struktura zaproponowana w książce „Agile Retrospectives: Making Good Teams Great” napisana przez Esther Derby i Diane Larsen

1. Ustawienie sceny. To moment na sprawdzenie sali, ustawienie krzeseł i tablicy – 6 minut
2. Zbieranie danych (Data Gathering): Pierwszym krokiem jest zebranie danych na temat ostatniego okresu pracy. Może to obejmować zarówno pozytywne, jak i negatywne aspekty projektu lub iteracji. – 40 minut
3. Generowanie wglądu (Generate Insights): Na podstawie zebranych danych zastanawiacie się nad tym, co te dane oznaczają i jakie wnioski można wyciągnąć. Istotne jest, aby przeanalizować, co działało dobrze, a co można poprawić. To etap generowania wglądu w przyczyny problemów i możliwe rozwiązania. – 25 minut
4. Decyzje (Decide What to Do): Na tym etapie zespół podejmuje decyzje dotyczące działań, które zostaną podjęte na podstawie wniosków z poprzednich etapów. Może to obejmować zarówno konkretne zmiany w procesie, jak i działania mające na celu wzmocnienie silnych stron zespołu. – 20 minut
5. Zamknięcie retrospekcji (Close the Retrospective) – Podsumowanie Retro i ustaleń. Prosimy członków zespołu, żeby to oni opowiedzieli, co się zadziało podczas Retro własnymi słowami. Jakaś forma zebrania wrażeń ze spotkania. – 12 minut
6. Czas na zmiany 10–15% Na zakończenie retrospektywy, zespół podsumowuje, co zostało osiągnięte na etapie realizacji działań i jakie są plany na przyszłość. To także okazja do wyrażenia wdzięczności i docenienia zaangażowania zespołu. – 17 minut

Dobre punkty do omówienia na Retro

• Omówienie action pointów z poprzednich Retrospekcji wciągniętych w zakończony właśnie Sprint.
• Co z celem Sprintu? Dowieźliśmy? Jeśli nie, to dlaczego? Czy był precyzyjny, czy prześlizgaliśmy się w jego ogólności? Czy zaczęliśmy się nim przejmować pod koniec Sprintu?
• Czy Przyrost spełnia Definition of Done? Jeśli nie,, to dlaczego? Których elementów DoD nie spełnia? Co możemy z tym zrobić? Czy DoD powinno zostać rozbudowane?
• Jeśli zespół współpracuje z dostawcą, porozmawiać o tej współpracy. Jakie mamy obserwacje? Co można poprawić? Co nam przeszkadza w integrowaniu się i identyfikowaniu zależności?
• Czy wjeżdżamy na Sprint z PBI w stanie Ready? Jeśli nie, to co możemy zrobić, żeby tak było?
• Przejść przez Impediment Board (tablica służąca do identyfikowania, śledzenia i zarządzania przeszkodami) i przegadać tematy na niej umieszczone. Co się z nimi dzieje? Czy jest postęp w usuwaniu przeszkód?
• Przejść z zespołem przez checklistę dojrzałości Scrumowej i zacząć budować na jej podstawie backlog usprawnień.

Materiały dodatkowe

• https://engineering.atspotify.com/2017/12/spotify-retro-kit/ – Retro Kit od Spotify
• https://appliedframeworks.com/blog/check-in-check-out-core-protocols – Check In