Dzisiaj w ostatnim dniu roku, my ludzie, mamy często skłonność do robienia różnorakich podsumowań. Podobnego rodzaju podsumowanie powinniśmy robić na koniec każdej iteracji. Tak zwane podsumowanie powinno składać się z serii dwóch spotkań: sprint review czyli przeglądu dostarczonych funkcjonalności i zebrania feedbacku od interesariuszy projektu oraz sprint retrospective czyli cofnięcia się do początku trwania iteracji i przeglądu jej trwania nakierowanego na proces wytwórczy (wszystkie casy które są warte dyskusji zespołowej)
Każdy, nawet dobrze zgrany i wyśmienicie współpracujący zespół scrumowy powinien dążyć do doskonałości poprzez ulepszanie stosowanych technik tworzenia produktu, współpracy, komunikacji czy końcowej jakości produktu. Zazwyczaj spotkanie podsumowujące proces i współpracę w zespole odbywa się zaraz po przeglądzie funkcjonalnym i zebraniu feedbacku od product ownera, klienta czy użytkownika końcowego. Jest to z pewnością właściwy moment ponieważ zespół posiada w tym momencie wiedzę o wszystkich aspektach związanych z daną iteracją włączając w to pracę zespołu, spełnienie wszystkich zobowiązań oraz co najważniejsze feedback zwrotny oraz stopień zadowolenia klienta. Mając te informacje zespół powinien spróbować wskazać odpowiednie miejsca w procesie wytwórczym i postarać się zastosować poprawki. Diagnozy zazwyczaj dokonuje cały zespół deweloperski włączając product ownera i scrum mastera. Następnie zespół dokonuje wyboru jednej lub kilku najważniejszych bolączek i decyduje o krokach potrzebnych do naprawy sytuacji.
Wobec powyższego chciałbym przedstawić Wam kilka praktykowanych przeze mnie metod i sposobów na uatrakcyjnienie spotkania sprint retrospective, tak aby po kilku iteracjach nie stał się nudną rutyną. Oto kilka z nich:

- Standard – pierwsze, wywodzące się z frameworku rozwiązanie jakiego używałem. Taka forma na pewno sprawdzi się na początku drogi zespołu scrumowego tak aby wszyscy zrozumieli jaką rolę spełnia to spotkanie i jak wiele zależy od aktywności wszystkich członków zespołu. Na dłuższą metę rozwiązanie może okazać się nużące. Jest to rozwiązanie proste składające się z trzech obszarów w których zespół poprzez wspólną rozmowę umieszcza elementy procesu, decydując o tym co:
- zrobiliśmy źle/co nie działało i nie chcemy już tego kontynuować
- zrobiliśmy dobrze i chcemy kontynuować
- chcemy sprawdzić i zacząć stosować (nowe praktyki, eksperymenty)

- Ulepszony standard -idąc dalej w las, standardowy szablon uległ małym modyfikacjom w oparciu o feedback który wyszedł od zespołu. Co się zmieniło, poza 3 obszarami opisanymi powyżej dołożyłem czwarty obszar który nazwałem parkingiem. Na parkingu, w nowym obszarze umieszczaliśmy ciekawe inicjatywy których nie byliśmy w stanie zrealizować w najbliższej iteracji ale jednocześnie nie chcieliśmy aby nam umknęły z radaru. Dodatkowo wszystkie 4 obszary podzieliłem poziomo na 3-4 zakresy odpowiedzialności jak np. development, testy, narzędzia. Dzięki temu podziałowi łatwiej było całemu zespołowi diagnozować problemy i co za tym proponować dedykowane poprawki.

- Rozgwiazda – kolejna, zmodyfikowana forma rozwiązania standard, do której ponad trzy standardowe obszary dokłada się dwa kolejne które wskazują czego robić więcej oraz czego robić mniej. Poprzez owe dwa dodatkowe obszary zespół flaguje elementy procesu które wymagają często mało energii i mogą okazać się szybkim sukcesem (tzw. quick win). Po zdefiniowaniu poprawek należy sporządzić plan jak poprawki możemy szybko wdrożyć w życie.

- Łódka – graficzna prezentacja na papierze (zazwyczaj używałem flip charta) w postaci łódki z żaglem lub motorówki z silnikiem, która poprzez swoją formę prezentacji ma pokazać to co w ramach iteracji było dla zespołu wiatrem w żagle/sprawnym silnikiem a co kotwicą hamującą ruch/skałami na wodzie. Metoda ciekawa o tyle, że retrospektywa jest realizowana w luźnej formie rysowania rysunku i przedstawiania na nim detali dotyczących sprintu. Zespół nieco łatwiej może wyrażać opinie i prezentować nieznane innym szczegóły sprintu. Możemy się również postarać ulokować na rysunku dwie dodatkowe kwestie:

- człowieka za burtą prezentującego palący problem na który zespół musi szybko poszukać koła ratunkowego które ma oznaczać szybkie rozwiązanie
- możemy poprosić kogoś z zespołu o dorysowanie prezentacji pogody nad łódką (słońce lub chmury). Słońce symbolizuje dobrą atmosferę, zmotywowany zespół, brak problemów, chmury natomiast symbolizują problemy, konflikty, itp. Zazwyczaj są to rzeczy które wymagają akcji naprawczych.
- Ankieta online – przypadek sprawił, że od początku mojego życia zawodowego miałem do czynienia wyłącznie z zespołami dystrybuowanymi geograficznie. Jednakże dopiero w obecnej organizacji w której pracuje w roli scrum mastera na mnie spoczęła organizacja spotkań. Chcąc zebrać dane od wszystkich członków zespołu przez spotkaniem a później aktywnie wszystkich zaangażować stworzyłem ankietę online na https://www.surveymonkey.com/ gdzie zbierałem anonimowo od wszystkich członków zespołu dane o których rozmaiwaliśmy podczas spotkania retrospective.
- Interakcje/badania/gry zespołowe

- 5 Dysfunkcji Zespołu – mając predefiniowaną piramidę z 5 podstawowymi dysfunkcjami zespołu prosimy z osobna każdego członka zespołu o przypięcie karteczki na poziomie na którym mu się wydaje że aktualnie znajduje się cały zespół. Dodatkowo osoba która decyduje się na przypięcie karteczki na danym poziomie powinna zapisać na karteczce sugerowane rozwiązanie tak aby cały zespół mógł podnieść się p jeden poziom wyżej.
- Analiza 5 Why’s – poszukiwanie źródła problemu zadając pytania dlaczego coś się stało, analiza została dokładnie opisana w jednym z wcześniejszych postów – „Wykorzystanie metody 5 why do analizy przyczyn problemów podczas sprint retrospective”
- Poziom zadowolenia zespołu – przedstawiony w formie graficznej poziom zadowolenia każdego członka zespołu w trakcie trwania iteracji. Może mieć formę oceny całej iteracji jednorazowo bądź możemy również prosić każdego z członków zespołu o pokazywanie swojego nastroju i poziomu zadowolenia podczas codziennych spotkań. Zazwyczaj przedstawiany w oparciu o dostarczony zakres, zaangażowanie, pracę zespołową, entuzjazm. Skala zależy od zespołu może być od 1 do 5, może mieć formę buzi. Chodzi o to aby znając poziom zadowolenia zespołu móc ewentualnie określić akcje które pozwolą podnieść poziom zadowolenia o jeden level.
Podsumowując musicie wiedzieć, że tworząc zespół i rozpoczynając projekt, uruchamiamy niekończący się proces poprawy. Przy okazji każdego ze spotkań podsumowujących iterację powinniśmy starać się całym zespołem zawsze robić krok do przodu, choćby niewielki…..
0 komentarzy