Antywzorce w Scrumie. Część 4: Retrospektywa Sprintu

Anty-wzorce w Scrumie

Anty-wzorce w Scrumie

Przed Wami czwarta część popularnej serii, opisującej najczęściej występujące antywzorce w Scrumie. Poprzednie części dotyczyły Codziennego Scruma, Planowania Sprintu oraz Przeglądu Sprintu. Tym razem opisuję kluczowe Zdarzenie Scrumowe, jakim jest Retrospektywa Sprintu.

Poniżej znajdziecie subiektywne TOP 5 antywzorców dotyczących przeprowadzania Retrospektyw Sprintu.

Antywzorzec #1: Brak struktury spotkania

Po czym poznać?

Spotkanie nie ma wyraźnej struktury. Brakuje agendy spotkania. Nie ma moderatora lub osoba w roli moderatora nie wykonuje swojej pracy we właściwy sposób. Timeboxy nie są stosowane. Nie pojawia się ciąg przyczynowo-skutkowy w kontekście prowadzonych rozmów. Toczy się równocześnie wiele wątków, jednak żaden nie jest na tyle dobrze omówiony, aby móc wyciągnąć wnioski na przyszłość.

Jakie są konsekwencje?

Spotkanie jest nieefektywne. W skrajnym przypadku Zespół Scrumowy wychodzi z retrospektywy bez konkretnych wniosków, za to z poczuciem zmarnowanego, “przegadanego” czasu. Na skutek panującego chaosu tylko część tematów jest omówiona, nie zawsze jednak są to te tematy, które są faktycznie ważne dla zespołu.

Co można zrobić inaczej?

Przygotuj strukturę spotkania

Esther Derby oraz Diana Larsen w książce “Agile Retrospectives” zaproponowały prostą strukturę, która pomaga przeprowadzić retrospektywę w sposób uporządkowany oraz efektywny. Struktura ta składa się z pięciu etapów:

  1. Otwarcie (ang. set the stage) – otwarcie retrospektywy, które pomaga Zespołowi Scrumowemu skupić się na spotkaniu i przygotować do dalszych etapów. Przykładowym otwarciem może być poproszenie zespołu o określenie, jak w skali od 1 do 5 (gdzie 1 oznacza “fatalnie, a 5 “bardzo dobrze”) oceniają efekty poprzedniego Sprintu oraz wysłuchanie 1-2 zdań komentarza, dlaczego właśnie taką cyfrę zdecydowali się wybrać.
  2. Zebranie danych (ang. gather data) – w etapie tym zbierane są tematy oraz informacje, które są istotne z punktu widzenia członków zespołu. Jest to “materiał”, nad którym zespół będzie pracował w dalszym etapie retrospektywy. Przykładową techniką na ten etap może być poproszenie zespołu o wypisanie rzeczy, które udały się w trakcie Sprintu oraz takich, które zakończyły się niepowodzeniem.
  3. Wygenerowanie spostrzeżeń (ang. generate insights) – etap ten ma na celu kreatywne przeanalizowanie zebranych danych w poszukiwaniu powiązań, zależności, związków przyczynowo-skutkowych oraz powtarzających się wzorców. Etap ten pomaga zespołowi zrozumieć źródła problemów. Przykładową techniką pomocną na typ etapie może być metoda 5 why.
  4. Wygenerowanie akcji (ang. decide what to do) – na tym etapie Zespół Scrumowy generuje konkretne akcje, których wykonanie spowoduje usprawnienie sposobu ich pracy. Przykładową techniką na ten etap jest przygotowanie listy “kto, co, do kiedy” – czyli ustalenie, kto odpowiada za konkretne zadanie, co jest w jego zakresie oraz kiedy spodziewamy się jego realizacji.
  5. Domknięcie (ang. closing) – podsumowanie oraz zakończenie spotkania. Jest to dobry moment, aby wejść na meta-poziom spotkania i zastanowić się nie tyle nad tym, co zostało omówione w trakcie, co nad sposobem jego przeprowadzenia, wybranych technik oraz struktury. Przykładowa, bardzo prosta technika, która może zostać użyta na tym etapie, to zwykłe pytanie do zespołu “Jak oceniacie to spotkanie?”.

Co ważne, każdy z etapów może zostać przeprowadzony przy użyciu wielu różnych technik – zachęcam do poszukiwania tych, które dają najlepsze efekty w konkretnych okolicznościach.

Antywzorzec #2: Brak śledzenia postępu zaplanowanych działań

Po czym poznać?

Zespół nie realizuje zmian w procesie, które ustala podczas Retrospektyw. Nie monitoruje na bieżąco postępu zaplanowanych działań. Nie wiadomo, które z zaplanowanych działania udało się zrealizować, a które nie. Brakuje nawiązania do zaplanowanych działań podczas kolejnych Retrospektyw.

Jakie są konsekwencje?

Zespół Scrumowy może przestać widzieć sens w przeprowadzaniu Retrospektyw, skoro postęp dla ustalonych podczas tego spotkania zadań nie jest przez przez nikogo obserwowany. Często brak śledzenia postępu prowadzi do stanu, w którym zdania te po prostu nie są realizowane. Jest to objaw poważnej dysfunkcji Zespołu Scrumowego.

Co można zrobić inaczej?

Zacznij Retrospektywę od przeglądu zaplanowanych działań

Dobrą praktyką jest rozpoczęcie Retrospektywy od przeglądu wcześniej zaplanowanych działań. Pozwala to jasno określić, które zadania są już zrealizowane, które są w trakcie realizacji, a które nadal czekają na wykonanie. Może się również okazać, że niektóre z zadań straciły swój “okres ważności” lub na skutek innych działań, nie ma zasadności, aby je realizować. Odpowiednia moderacja takiej dyskusji – na przykład poprzez Scrum Mastera – pozwala zapewnić, że z jednej strony nie zajmuje ona zbyt dużo czasu, z drugiej strony pozwala zespołowi na bieżącą synchronizację wybranych do realizacji działań.

Umieść ustalenia z Retrospektywy w widocznym miejscu

Często jestem świadkiem sytuacji, w której postanowienia z Retrospektywy są spisywane w formie elektronicznej i umieszczane w narzędziach typu wiki. Może to powodować, że następny raz strona ta zostanie otwarta dopiero na początku kolejnej Retrospektywy. Warto rozważyć umieszczenie postanowień ze Retrospektywy w miejscu widocznym dla całego zespołu – na przykład na ścianie w przestrzeni zespołowej lub na tablicy, z której zespół korzysta podczas Codziennego Scruma.

Antywzorzec #3: Ignorowanie “słonia w pokoju”

Po czym poznać?

Zespół omawia mało istotne tematy, podczas gdy te poważne – pomimo, iż każdy odczuwa ich obecność – są pomijane (stąd wspomniany “słoń w pokoju”).

Jakie są konsekwencje?

Zespół nie dotyka problemów, których rozwiązanie może mieć krytyczny wpływ na efektywność pracy, jakość produktu oraz atmosferę w zespole. Poważne problemy, długo ignorowane oraz nieobsługiwane, mogą w konsekwencji doprowadzić do zwiększenia poziomu demotywacji w zespole, zaprzestania przeprowadzania Retrospektyw, zrezygnowania z korzystania ze Scruma oraz do personalnych decyzji o zmianie miejsca pracy.

Co można zrobić inaczej?

Nazywaj problemy i wyciągaj je na powierzchnię

Jedną z wartości Scruma jest odwaga (ang. courage). Odważne zachowania mogą być niekomfortowe dla osoby, która decyduje się na taki krok, jednak mogą pomóc przełamać impas w zespole i zapoczątkować dyskusję na zupełnie nowym poziomie. Przejawem odwagi może być zarówno podjęcie dyskusji z managementem firmy, podczas gdy ten naciska na obniżenie jakości, jak również nazwanie po imieniu problemu podczas Retrospektywy, podczas gdy reszta Zespołu Scrumowego milczy.

Obrazuj problemy przy użyciu danych

Wyobraź sobie sytuację, w której “słoniem w pokoju” jest niska jakość wytwarzanego oprogramowania. Każdy wewnętrznie czuje, że coś niedobrego dzieje się z jakością, jednak póki co jest to wyłącznie odczucie każdego członka zespołu z osobna.

Pomocne w takiej sytuacji może być zobrazowanie problemu przy użyciu danych – to znaczy pokazanie ich, następnie upewnienie się, że są zrozumiane w ten sam sposób, by ostatecznie zastanowić się nad rozwiązaniem. Przykładowo, nienamacalne odczucie, że jakość produktu być może jest nie najlepsza, może zostać zobrazowana i wzmocniona pomiarami wskazującymi, że 70% czasu w Sprincie Zespół Deweloperski spędza rozwiązując błędy produkcyjne. W takiej sytuacji, w zderzeniu z tak mocnymi danymi, dyskusja zwykle nabiera zupełnie nowego kierunku.

Antywzorzec #4: Jeden z uczestników dominuje podczas spotkania

Po czym poznać?

Spotkanie jest zdominowane przez jednego z uczestników. Przez całą Retrospektywę jest osobą mówiącą najwięcej. Pozostali uczestnicy wypowiadają się rzadko, nie potrafią też “przebić się” ze swoimi pomysłami.

Jakie są konsekwencje?

Podczas spotkania dominuje wyłącznie jeden punkt widzenia. Potencjał Zespołu Scrumowego nie jest wykorzystywany. Problemy rozwiązywane są zgodnie ze światopoglądem osoby dominującej. Pozostali uczestnicy mogą czuć się znudzeni spotkaniem, podczas którego nie mają oni realnego wpływu na jego efekty.

Co można zrobić inaczej?

Porozmawiaj z osobą dominującą

Nie zawsze osoba dominująca zdaje sobie sprawę ze skutków swojego zachowania. Co więcej, różne mogą być powody takiego zachowania. Przykładowo, może to być echo wcześniejszych doświadczeń z pracy w firmie, gdzie kultura organizacyjna promowała taki właśnie styl prowadzenia dyskusji, a odmienne zachowania były traktowane jako oznaka słabości. Być może nikt wcześniej nie podzielił się z tą osobą informacją zwrotną, która pomogłaby jej zrozumieć wpływ swojego zachowania na pozostałe osoby. Podobnych przykładów można by mnożyć.

W takiej sytuacji zacząłbym od zwykłej rozmowy, która będzie okazją do podzielenia się obserwacją, jak to konkretne zachowanie wpływa na zespół i co tracimy, nie tworząc przestrzeni do wypowiedzi dla pozostałych członków zespołu.

Wykorzystaj możliwość pracy w grupach

Sprawdzonym sposobem na zaangażowanie większej liczby osób w dyskusję jest zorganizowanie podczas Retrospektywy (a także każdego innego, dowolnego spotkania) pracy w grupach.

Aby zniwelować negatywny wpływ dominującego uczestnika, wystarczy, że stworzymy minimum dwie grupy po dwie osoby – oczywiście odpowiednio dopasowując liczebność grup w zależności od ilości uczestników. Spowoduje to, że co najmniej jedna grupa będzie miała możliwość swobodnego przedyskutowania problemu. Trudno też ocenić, jak zachowa się wyróżniający się członek zespołu w nowej, odmiennej konfiguracji osobowej – być może stworzy przestrzeń do dyskusji dla pozostałych.

Dodatkowo, w procesie łączenie efektów pracy grup, właściwa moderacja poprzez wprowadzane ograniczenia czasowe per grupa spowoduje, że już nie jeden, a dwa (lub więcej) “głosy” wybrzmieją podczas spotkania.

Antywzorzec #5: Product Owner nie uczestniczy

Po czym poznać?

Product Owner jest nieobecny na Retrospektywie. Nie jest to jednorazowa nieobecność, tylko stan permanentny.

Jakie są konsekwencje?

Zespół Scrumowy nie ma możliwości usprawniania się jako całość – perspektywa biznesowa nie ma bowiem swojego wyraźnego reprezentanta. Tworzy się podział na dwie odseparowane grupy: zespół wraz ze Scrum Masterem oraz Product Owner.

Co można zrobić inaczej?

Wytłumacz korzyści z posiadania całego Zespołu Scrumowego na Retrospektywie

Powody, dla którego Product Owner nie uczestniczy w Retrospektywnie mogą być rozmaite – brak zrozumienia potencjalnych korzyści, stare nawyki, poczucie brak czasu, obawy co z takiej rozmowy wyniknie lub też – w przypadku współpracy międzynarodowej – bariera językowa. Obawy te mogą być nasilone zarówno po stronie Zespołu Deweloperskiego, jak i po stronie Product Ownera. W takim przypadku Scrum Master lub doświadczony Agile Coach może być osobą, która porozmawia z obiema stronami i wytłumaczy korzyści, jakie płyną z regularnej inspekcji sposobu pracy zespołu, która jest przeprowadzana w pełnym składzie.

Przygotuj odpowiednia strukturę Retrospektywy

Słabo przeprowadzona pierwsza wspólna Retrospektywa może być kiepskim otwarciem i zadziałać zniechęcająco, zarówno na Zespół Deweloperski, jak i na Product Ownera. Kiedy piszę o przygotowaniu odpowiedniej struktury, mam na myśli dwa aspekty. Po pierwsze, dobrze, żeby w ogóle pojawiła się jakaś struktura – na przykład zgodnie ze schematem, który opisałem wcześniej w tym artykule. Po drugie, pisząc o odpowiedniej strukturze, mam na myśli takie poprowadzenie spotkania, aby powstała przestrzeń zachęcającą do wymiany myśli oraz obserwacji pomiędzy wszystkimi rolami w Zespole Scrumowym. W tym przypadku w szczególności zadbałbym o uwypuklenie różnych punktów widzenia. Z doświadczenia wiem bowiem, że kiedy w zespole tworzą się okazje do poznania odmiennych perspektyw, potrzeb oraz oczekiwań, to efekty takich dyskusji pomagają w budowie poczucia jednego zespołu, bez wyraźnego podziału “my” vs. “oni”.

Podsumowanie

Gdybym mógł realizować z zespołem tylko jedno Zdarzenie Scrumowe, to zdecydowanie byłaby to Retrospektywa Sprintu. Stąd ważne, aby Zdarzenie to przeprowadzać na odpowiednim poziomie. Z jakimi antywzorcami podczas Retrospektyw spotykasz się na co dzień? Jak zwykle – czekam na Wasze komentarze.

Chcesz przeczytać więcej?

Powyższy artykuł to mały wycinek mojej książki “Labirynty Scruma”, której premierę planuję w okolicy połowy 2017 roku. Opisuję w niej sprawdzone, praktyczne sposoby na najczęstsze pułapki w Scrumie. Zapisz się na mój newsletter – dla subskrybentów planuję przedpremierowy fragment książki oraz dodatkowe materiały.

Źródło zdjęcia: https://flic.kr/p/61KvuL

Komentarze do wpisu: “Antywzorce w Scrumie. Część 4: Retrospektywa Sprintu

  1. Jeśli chodzi o dominującego członka/członków zespołu polecam również pracę indywidualną ze sticky notesami – czy to „generowanymi” podczas spotkania, czy to zbieranymi w trakcie całego Sprintu do „Retro Box’a”. Takie rozwiązanie sprawia, że zdanie każdego jest poruszone przez zespół 🙂

  2. Jacek Wieczorek

    Dzięki MW za Twój komentarz. +1 dla tego pomysłu.

    Myślę, że pomimo tego, nadal warto mieć radar nastawiony na przebieg dalszej dyskusji. W sensie takim, że te kartki trzeba zapewne omówić, bo zakładam, że są bardziej hasłowe niż opisowe, a warto wypracować wspólne zrozumienie tematu. To dalsze omówienie widzę jako potencjalną przestrzeń dla dominatora na przejęcie dyskusji.

    • Zgadzam sie, to co zarzuciłem pozwala poruszyć tematy wszystkich i przy okazji dodaje odwagi tym cichszym członkom zespołu. Jeśli bedzie to dobrze moderowane na kolejnych retrospektywach karteczki nie powinny być juz potrzebne 😉

  3. Antywzorzec #5: Product Owner nie uczestniczy … nie wiem co na to scrum guide ale z tym akurat się nie zgadzam by musiał być (bynajmniej zawsze). Potrzebą jest zespołu by spotkał się w takim gronie, które dotyczy problemu. Na przykład piłkarze sami czasami muszą sobie coś wyjaśnić i nie zawsze musi być wtedy trener. Popularną nawet techniką jest u doświadczonych trenerów by opuszczali szatnię w niektórych momentach by sami zawodnicy doszli w pewnych kwestiach do porozumienia. To tak jakby rodzice i ich obecność miała pomóc w tym by dzieci miały się pogodzić albo coś wyjaśnić. To, że podadzą sobie dłoń o niczym nie świadczy. Dzieci same się pokłóciły to i same mogą się pogodzić my co najwyżej możemy ich ku temu pchnąć ale w kluczowym momencie to nie od nas zależy. I to właśnie wtedy pojawia się Antywzorzec #3: Ignorowanie “słonia w pokoju” bo boją się przy PO pewne kwestie poruszać. Uprzedzam, że pewnie pojawi się kwestia, że SM i PO nie mogą być izolowani i ich też to dotyczy. Nie wszystko – czasami programiści mają do siebie uprzedzenia/problemy związane z np. kodowaniem i praktykami technicznymi. Warto naprawdę dać szanse popracować i rozwiązać problemy zespołowi …albo inaczej fachowcom … we własnym i dedykowanym gronie. Jedyne co najwyżej to można ludzi lekko na siebie pozytywnie nakierować by nie odwrócili się plecami nawzajem – i tyle.

  4. Jacek Wieczorek

    Dzięki za Twój komentarz.

    Osobiście traktuję Zespół Scrumowy (PO, SM, Zespół Deweloperski) jako całość. Na bazie moich doświadczeń, brak PO na retrospektywie to objaw dysfunkcji zespołu lub — idąc dalej — całej firmy. Przykładowo, jedna z hipotez która rodzi mi się w głowie jest taka, że firma wprawdzie pracuje Scrumem, jednak nadal istnieje głęboki, nie adresowany podział na „IT” oraz „biznes”, co może oznaczać m.in. płytkie relacje, brak wzajemnego zaufania, traktowanie prognoz jak zobowiązań czy nie mówienie sobie nawzajem prawdy.

    Podobnie, nie dyskutowanie kluczowych problemów („słoń w pokoju”) ze względu na obecność Product Ownera to dla mnie niepokojący sygnał. Nie unikał bym tej rozmowy, pomimo, iż może być trudna.


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x