Wprowadzanie wyników retrospektyw w życie

Zdarza mi się słyszeć od zespołów, że przestały przeprowadzać retrospektywy, ponieważ nie dostrzegały żadnych usprawnień. Często okazuje się wówczas, że nie wypracowywały wartościowych działań naprawczych albo że podjęte działania nie były realizowane i wracały na kolejne retrospektywy raz po raz.

Jeśli nie działamy, nie możemy niczego poprawić! Poniżej znajdziesz kilka wskazówek, jak uzyskiwać z retrospektyw konkretne, możliwe do wdrożenia działania i jak zadbać o to, by rzeczywiście były realizowane.

Retrospektywa

Zwinne retrospektywy pomagają zespołom stale się doskonalić. W czasie retrospektywy członkowie zespołu zastanawiają się, co mogą zrobić w kolejnej iteracji, aby poprawić swoją pracę. Wdrożenie tych działań w następnej iteracji ostatecznie poprawi pracę i wydajność zespołu.

Retrospektywy można stosować w Scrumie lub Kanbanie, by planować i śledzić pracę zespołu. Właśnie dlatego powinieneś przeprowadzać je regularnie. Tylko wtedy, gdy regularnie oceniasz korzyści z wdrożonych działań, osiągniesz lepsze wyniki.

Jak uzyskiwać z retrospektywy konkretne działania

Trwałe usprawnienia z retrospektyw zaczynają się od tego, by ich wyniki były możliwe do wdrożenia. Zawsze staram się dopilnować, żeby członkowie zespołu wychodzili ze spotkania z działaniami, które mogą i będą wdrożyć bezpośrednio w kolejnej iteracji. Te działania powinny zostać dodane do tablicy statusów i/lub Backlogu, tak by były zawsze widoczne i nie zostały zapomniane.

Dla mnie możliwe do wdrożenia działania są:

• małe, ale skuteczne
• jednoznaczne i zrozumiałe
• sformułowane tak, by wyraźnie widać było z nich wynikającą korzyść

Powinieneś też wyjaśnić „dlaczego":

• Dlaczego zdecydowano się na ten powód, na to działanie?
• Dlaczego to jest problem, który musimy rozwiązać?
• Jaka jest oczekiwana korzyść?

To zmotywuje zespół do rzeczywistego wdrożenia działań!

Same urozmaicanie retrospektyw – choć pomocne – w większości przypadków nie rozwiązuje problemów. Można w ten sposób oczywiście odkryć lepsze działania, ponieważ różne metody pozwalają uzyskać różne spostrzeżenia. Forma retrospektywy jest ważna, jednak musisz uświadamiać zespołom, że jako samozarządzający się zespół sami są odpowiedzialni za to, jak pracują i co chcą ulepszyć.

Wdrażanie działań z retrospektywy

Kiedy coahuję zespół, staram się pomagać, przypominając członkom zespołu o uwzględnieniu wyznaczonych działań w kolejnych iteracjach. Dzieje się to na przykład podczas Daily Standup, w rozmowach z członkami zespołu czy podczas review. Coaguję też Scrum Masterów i przypominam im, żeby realizowali to, co pierwotnie chcieli zrobić.

Oto przykład z zespołem, z którym pracowałem: przeprowadzili retrospektywę i stwierdzili, że ich umiejętności i wiedza (ponieważ byli zespołem multidyscyplinarnym) były rozproszone między poszczególnych członków. Jak ujął to Jerry Weinberg w swoim prawie dżemu malinowego z książki „Sekrety konsultingu": im bardziej coś rozkładasz, tym cieńsza staje się warstwa. W kilku przypadkach tylko jedna osoba potrafiła wykonać pewien rodzaj pracy i to było niepożądane.

Zespół zdefiniował działanie „więcej pracy w parach". Było ono nieco ogólnie sformułowane, ale zgodziliśmy się traktować je jako okazję do współpracy i rozwijania nowych umiejętności i kompetencji. W ten sposób działanie stało się możliwe do wdrożenia.

W trakcie iteracji zespół natrafił na zadanie, przy którym utknął. Fragment oprogramowania wymagał przetestowania, ale testerzy byli zajęci testowaniem innych modułów. Na spotkaniu standup jeden z programistów wspomniał, że chętnie podjąłby się tego zadania, ale ma niewielkie doświadczenie w testowaniu. Scrum Master zapytał testerów, czy ktoś mógłby współpracować z programistą i pokazać mu, jak testować. Wskazał przy tym na działanie z tablicy zadań i przypomniał zespołowi, że właśnie na to się umówili w tej iteracji. Jeden z testerów zgłosił się i przez kilka godzin pracował razem z programistą.

Okazało się, że to w zupełności wystarczyło, aby programista mógł samodzielnie testować. Odpowiedzi na kilka pytań sprawiły, że był w stanie ukończyć zadanie. W kolejnych iteracjach pracował przy zadaniach wymagających testowania i systematycznie się doskonalił. Dzięki temu zespół był w stanie przeprowadzić znacznie więcej testów i ukończyć więcej User Stories, ponieważ testowanie było zwykle wąskim gardłem uniemożliwiającym zamknięcie historyjek.

Zadbaj więc o to, by działania usprawniające były zawsze dobrze widoczne. Pomaga to w ich rzeczywistym wdrożeniu, gdy tylko nadarzy się okazja, ponieważ są stale widoczne dla członków zespołu.

Śledzenie działań usprawniających

Zazwyczaj zaczynam retrospektywę od przejrzenia działań usprawniających z poprzedniego spotkania, by sprawdzić, czy wszystkie zostały zrealizowane. Jeśli nie (a zawsze proszę zespoły, by formułowały działania tak, aby dało się je wykonać w ciągu jednej iteracji), pytam zespół, dlaczego im się to nie udało.

Czasami jest po prostu za dużo działań (wtedy polecam ćwiczenia pomagające znaleźć najważniejsze z nich). Niekiedy istnieją jednak głębsze powody, dla których zespół nie jest w stanie się doskonalić (w takim przypadku polecam analizę przyczyn źródłowych).

Zespoły powinny zasadniczo wychodzić z retrospektywy z taką liczbą działań, jaką są w stanie faktycznie zrealizować w kolejnej iteracji. Małymi krokami można osiągnąć trwałe i ciągłe doskonalenie.

Ciągłe doskonalenie poprzez retrospektywy

Retrospektywa to znacznie więcej niż tylko spotkanie na końcu iteracji. Chodzi o stworzenie kultury, w której zespoły mogą stale ulepszać swój sposób pracy.
Mam nadzieję, że udało mi się przekazać kilka pomysłów na to, jak faktycznie uzyskiwać z retrospektyw możliwe do wdrożenia działania.

Jeśli interesujesz się retrospektywami lub szkoleniem Scrum Master, zapoznaj się z ofertą Agile Academy. Głębszą wiedzę na temat retrospektyw przekazujemy na naszych Deep Dives.

Tekst pochodzi z bloga Bena Lindersa i został przez nas przetłumaczony na język polski.

Wdrażanie działań z retrospektywy

Kiedy coahuję zespół, staram się pomagać, przypominając członkom zespołu o uwzględnieniu wyznaczonych działań w kolejnych iteracjach. Dzieje się to na przykład podczas Daily Standup, w rozmowach z członkami zespołu czy podczas review. Coaguję też Scrum Masterów i przypominam im, żeby realizowali to, co pierwotnie chcieli zrobić.

Oto przykład z zespołem, z którym pracowałem: przeprowadzili retrospektywę i stwierdzili, że ich umiejętności i wiedza (ponieważ byli zespołem multidyscyplinarnym) były rozproszone między poszczególnych członków. Jak ujął to Jerry Weinberg w swoim prawie dżemu malinowego z książki „Sekrety konsultingu": im bardziej coś rozkładasz, tym cieńsza staje się warstwa. W kilku przypadkach tylko jedna osoba potrafiła wykonać pewien rodzaj pracy i to było niepożądane.

Zespół zdefiniował działanie „więcej pracy w parach". Było ono nieco ogólnie sformułowane, ale zgodziliśmy się traktować je jako okazję do współpracy i rozwijania nowych umiejętności i kompetencji. W ten sposób działanie stało się możliwe do wdrożenia.

W trakcie iteracji zespół natrafił na zadanie, przy którym utknął. Fragment oprogramowania wymagał przetestowania, ale testerzy byli zajęci testowaniem innych modułów. Na spotkaniu standup jeden z programistów wspomniał, że chętnie podjąłby się tego zadania, ale ma niewielkie doświadczenie w testowaniu. Scrum Master zapytał testerów, czy ktoś mógłby współpracować z programistą i pokazać mu, jak testować. Wskazał przy tym na działanie z tablicy zadań i przypomniał zespołowi, że właśnie na to się umówili w tej iteracji. Jeden z testerów zgłosił się i przez kilka godzin pracował razem z programistą.

Okazało się, że to w zupełności wystarczyło, aby programista mógł samodzielnie testować. Odpowiedzi na kilka pytań sprawiły, że był w stanie ukończyć zadanie. W kolejnych iteracjach pracował przy zadaniach wymagających testowania i systematycznie się doskonalił. Dzięki temu zespół był w stanie przeprowadzić znacznie więcej testów i ukończyć więcej User Stories, ponieważ testowanie było zwykle wąskim gardłem uniemożliwiającym zamknięcie historyjek.

Zadbaj więc o to, by działania usprawniające były zawsze dobrze widoczne. Pomaga to w ich rzeczywistym wdrożeniu, gdy tylko nadarzy się okazja, ponieważ są stale widoczne dla członków zespołu.

Śledzenie działań usprawniających

Zazwyczaj zaczynam retrospektywę od przejrzenia działań usprawniających z poprzedniego spotkania, by sprawdzić, czy wszystkie zostały zrealizowane. Jeśli nie (a zawsze proszę zespoły, by formułowały działania tak, aby dało się je wykonać w ciągu jednej iteracji), pytam zespół, dlaczego im się to nie udało.

Czasami jest po prostu za dużo działań (wtedy polecam ćwiczenia pomagające znaleźć najważniejsze z nich). Niekiedy istnieją jednak głębsze powody, dla których zespół nie jest w stanie się doskonalić (w takim przypadku polecam analizę przyczyn źródłowych).

Zespoły powinny zasadniczo wychodzić z retrospektywy z taką liczbą działań, jaką są w stanie faktycznie zrealizować w kolejnej iteracji. Małymi krokami można osiągnąć trwałe i ciągłe doskonalenie.

Ciągłe doskonalenie poprzez retrospektywy

Retrospektywa to znacznie więcej niż tylko spotkanie na końcu iteracji. Chodzi o stworzenie kultury, w której zespoły mogą stale ulepszać swój sposób pracy.
Mam nadzieję, że udało mi się przekazać kilka pomysłów na to, jak faktycznie uzyskiwać z retrospektyw możliwe do wdrożenia działania.

Jeśli interesujesz się retrospektywami lub szkoleniem Scrum Master, zapoznaj się z ofertą Agile Academy. Głębszą wiedzę na temat retrospektyw przekazujemy na naszych Deep Dives.

Tekst pochodzi z bloga Bena Lindersa i został przez nas przetłumaczony na język polski.