Retrospektywy w metodologii agile a kondycja zespołu: spostrzeżenia ekspertów

Rozmowy na temat metodyki agile często koncentrują się na frameworku Scrum, z jego zaplanowanymi spotkaniami i zdefiniowanymi rolami. Czy jednak wraz z dojrzewaniem filozofii agile punkt ciężkości tych dyskusji ulega zmianie? W niniejszym wywiadzie trener agile typu full-stack Jon Fazzaro odpowiada na to pytanie i porusza wiele innych kwestii.

Wszystko zaczyna się z wielkim rozmachem, gdy Jon kwestionuje opieranie się wyłącznie na metodologii Scrum jako punkcie wyjścia do osiągnięcia agilitetu. Zamiast tego opowiada się za bardziej organicznym podejściem do agilitetu.

W miarę rozwoju dyskusji na pierwszy plan wysuwa się analiza retrospektywna, a przedmiotem rozważań staje się rola trenera.

Na koniec przedstawiono spostrzeżenia dotyczące kondycji zespołów pracujących metodą agile oraz bezcenne porady dotyczące wspierania Państwa zespołu.

Zacznijmy więc!

Ewolucja podejścia do metodyki Scrum

Przeczytałem Pański artykuł na platformie Medium Retrospektywa jest sercem projektu. Czy nadal uważa Pan, że tak właśnie jest, czy też uznałby Pan, że obecnie należy wziąć pod uwagę coś ważniejszego?

Od czasu napisania tego artykułu zdecydowanie przestałem uważać, że Scrum jest najlepszym sposobem na rozpoczęcie pracy w duchu agile, jeśli jeszcze tego nie robią.

Pozwolę sobie zapożyczyć metaforę, którą szef naszej firmy, Joshua Kerievsky,, przedstawił jakiś czas temu podczas swojego wystąpienia.

Kiedy uczy się Pan/Pani jeździć na rowerze, korzysta się z kółek pomocniczych. Przynajmniej tak robi większość dzieci – mają one małe kółka pomocnicze przykręcone z boku roweru. Pierwszą rzeczą, której się uczą, jest pedałowanie. Dlatego kiedy zdejmuje się kółka pomocnicze, pierwszą reakcją dzieci jest upadek. Nie zdają sobie sprawy, że muszą pedałować do przodu. Nie nauczyły się jeszcze utrzymywać równowagi.

Istnieje alternatywny sposób nauki jazdy na rowerze dla dzieci. Nazywa się to rowerem biegowym. Jest to bardzo proste. Nie ma on nawet pedałów. Ma kształt roweru, dwa koła i siodełko. Wystarczy po prostu poprosić dziecko, aby szło, poruszało się naprzód i spróbowało jechać, utrzymując równowagę.

To lepszy sposób na nauczenie dziecka jazdy na rowerze. Trudnością jest utrzymanie równowagi, a nie pedałowanie.

Podobnie Scrum jest najczęstszym sposobem, w jaki zespoły mówią: „No dobrze, musimy zacząć działać agile, więc wdrażajmy Scrum”. Następnie przystępują do działania i po prostu „zakładają” sobie „kółka pomocnicze” Scruma. Mówią: „oto spotkania, oto role, a oto, co robimy”.

Niestety, w praktyce Scrum nie spełnia w pełni swoich zadań.

Proszę mnie źle nie zrozumieć. Na papierze ten przewodnik jest bardzo dobry. Zawiera wiele znakomitych pomysłów. Jednak Scrum zazwyczaj nie robi wystarczająco dużo, aby nauczyć zespół tego, co naprawdę jest potrzebne do osiągnięcia agile.

Rola retrospektyw w zespołach stosujących metodykę agile

Skoro Państwa podejście do metodyki Scrum i jej związku z agile uległo zmianie, to jak wygląda kwestia retrospektywy?

Nadal uważam, że ważne jest, aby przerwać pracę i porozmawiać o tym, jak Państwo ją wykonują. Myślę, że to jest najważniejsze. Podoba mi się pomysł organizowania częstszych retrospektyw. Aby przyspieszyć tempo pracy.

Zespół nie musi codziennie przeprowadzać intensywnej, dwugodzinnej retrospektywy. Zamiast tego warto poświęcić pół godziny każdego dnia w określonym momencie, który pozostaje niezmienny – w mgnieniu oka. Być może dzięki temu szybciej odkryją Państwo ważne kwestie. Zamiast czekać dwa tygodnie, aby naprawić „tę sprawę” i gromadzić zaległości w postaci „innych spraw” do załatwienia, zespół może zająć się nią niemal natychmiast.

Szczerze mówiąc, to bardziej agile podejście. Zamiast gromadzić zadania i czekać.

Co to regularne, być może przyspieszone bicie serca może oznaczać dla kierownictwa organizacji?

Pozornie chodzi o to, że zależy im na tym, by zespół był w dobrej kondycji i osiągał wyniki na przewidywalnym poziomie. Jako osoby zarządzające działalnością, którą obsługuje dany zespół, chcą mieć pewność, że zespół ten zapewni im to, czego potrzebują, aby zrealizować swoje cele biznesowe.

Jeśli zespół nie spotyka się regularnie i nie dostosowuje swojego działania, może stać się nieprzewidywalny. Być może mieli znakomity tydzień, ponieważ wszyscy pracowali w nadgodzinach, ale są już wyczerpani. W rezultacie przez kolejne trzy tygodnie będą tylko wprowadzać błędy i popełniać niedopatrzenia.

Właśnie na tym skupiłbym się, pełniąc funkcję kierowniczą. Uważam, że świadomość tego ma naprawdę ogromną wartość.

Trener agile i skuteczne retrospektywy

Na jakie wskaźniki – niekoniecznie dane – mógłby zwracać uwagę Scrum Master, biorąc pod uwagę, że nie wszyscy z nich mają doświadczenie w dziedzinie programowania?

Cóż, w retrospektywie Scrum Master jest w gruncie rzeczy ich trenerem.

Jeśli posłużymy się metaforą sportową, trener to zazwyczaj osoba będąca ekspertem w danej dyscyplinie. Być może były zawodnik. Aby być użytecznym, musi on przyjąć stanowisko, że nie może pomóc zawodnikom, samemu biorąc udział w grze.

Osoba prowadząca retrospektywę musi spojrzeć na rozmowę z dystansu, nie skupiając się wyłącznie na jej treści. Powinna raczej zwrócić uwagę na ogólny przebieg rozmowy.

W związku z tym fakt, że nie rozumieją niektórych omawianych kwestii, może w rzeczywistości okazać się korzystny, ponieważ te kwestie mogłyby stanowić czynnik rozpraszający. Mogłyby one odwrócić ich uwagę od obserwowania interakcji w zespole. Załóżmy, że ktoś ciągle jest przerywany. Właśnie w takiej sytuacji trener mógłby wkroczyć do akcji. Może on pomóc w dostosowaniu przebiegu rozmowy.

Chociaż treść rozmowy należy do osób, które ją prowadzą, czasami jej przebieg nie przebiega prawidłowo. Potrzebna jest tam osoba, która jedynie obserwuje, jak to się dzieje. Można ją delikatnie zachęcić, by uczestnicy „współpracowali” ze sobą lepiej.

Czy przyczyniają się Państwo do tego, by „zabawa” była jak najlepsza?

Tak.

Jeśli chcą podnieść poprzeczkę, co mógłby zrobić trener?

Cóż, przychodzi mi na myśl pojęcie „tworzenia przestrzeni” z technologii Open Space.

Tworzenie przestrzeni to osobne zadanie. Właśnie tym zajmuje się moderator retrospektywy, niezależnie od tego, czy jest to coach, czy Scrum Master – bez względu na pełniony tytuł. Chodzi o rolę polegającą na moderowaniu rozmowy. Nie angażują się Państwo w samą treść, lecz tworzą Państwo przestrzeń i obserwują przebieg rozmowy.

Wiąże się to z wyjaśnieniem, w jaki sposób zamierzają Państwo przeprowadzić tę rozmowę. Przygotowali Państwo pytania, które będą stanowić punkt wyjścia do tej rozmowy. Wyznaczyli Państwo granice. Wymaga to sporego nakładu pracy związanej z planowaniem.

Z mojego doświadczenia wynika, że gdy retrospektywa nie przebiega pomyślnie, zazwyczaj wynika to z tego, że osoba ją prowadząca nie poświęciła czasu na jej odpowiednie zaplanowanie. Po prostu improwizuje.

To nie jest przydatne.

Warto, aby ustalili sobie limit czasowy, powiedzmy 10 minut. Kiedy ten limit się skończy, nie podchodzą do tego pobłażliwie, lecz stanowczo. „No dobrze, skończyliśmy rozmawiać na ten temat, czas podjąć decyzję i przejść dalej”.

Te parametry są więc naprawdę dość istotne, aby przestrzeń ta była funkcjonalna. Jakie nieprawidłowości zauważył Pan, które można było usunąć za pomocą prostego rozwiązania?

Jeśli chodzi o retrospektywy, częstym błędem jest stwierdzenie: „porozmawiajmy swobodnie”. Następnie grupa zaczyna rozmawiać o wszystkim, co przychodzi jej do głowy. Chociaż w niektórych sytuacjach jest to ważne, w rzeczywistości warto dążyć do tego, aby czas przeznaczony na retrospektywę przynosił konkretne korzyści.

Proszę pamiętać, że nie skupiamy się na samej pracy. Skupiamy się na zespole. Skupiamy się na tym, jak pracujemy.

Często pomija się pewien element, zanim przejdziemy do omówienia naszych odczuć związanych z tym, co się wydarzyło, a mianowicie ustalenie, co faktycznie się wydarzyło. Chodzi o to, aby upewnić się, że wszyscy obecni w pomieszczeniu mają podobny obraz sytuacji, o której rozmawiamy.

A zatem uzgodnienie stanowisk. Sprawdzenie, czy „zgadzamy się co do faktów?”.

Często pomocnym sposobem na osiągnięcie tego celu jest poświęcenie kilku minut na wspólne ustalenie z zespołem osi czasu opisującej przebieg wydarzeń. Należy narysować poziomą linię na tablicy i zacząć nanosić na nią notatki. „Na początku sprintu miało miejsce to, a potem nastąpiło tamto”.

Pomaga to uniknąć efektu „świeżości”. Uczestnicy nie będą skupiać się wyłącznie na wydarzeniach z ostatniego dnia lub dwóch, ani z ostatniej godziny lub dwóch. Jest to szczególnie ważne w przypadku iteracji trwającej dwa tygodnie, miesiąc lub dłużej. Jest wiele rzeczy, których po prostu nie będą Państwo pamiętać.

Zapewnienie im czasu na aktywne przywoływanie wspomnień jest naprawdę pomocne.

Być może niektórzy członkowie zespołu nie odczuwali tego w ten sam sposób lub nie pamiętali tych wydarzeń tak wyraźnie. Być może słyszeli o czymś, ale nie brali w tym udziału. Dzięki temu uzyskują oni nieco bardziej całościowy i wspólny obraz sytuacji.

W tym momencie, gdy zespół uzgodni, co się wydarzyło, będzie mógł omówić, co to oznacza, jakie są ich odczucia w tej sprawie oraz co można by poprawić.

W pierwszej kolejności można zająć się amnezją.

Albo po prostu zupełnie odmienne punkty widzenia. Przed rozpoczęciem retrospektywy można omówić zupełnie odmienne modele mentalne dotyczące tego, co się wydarzyło.

Wyobraźcie sobie zatem alternatywę. Przejście od razu do dyskusji na temat: „Czy to było dobre, czy złe?”. Każdy ma w głowie własną wersję tego, co się wydarzyło. Te opowieści są zupełnie różne. Oznacza to, że słowa, których używają do opisania sytuacji, będą z punktu widzenia drugiej osoby całkowicie nieadekwatne. Nie będzie żadnego porozumienia. Nie da się z tego wyciągnąć żadnych wniosków.

Zespoły agile jako systemy żywe: analiza tej metafory

A teraz spróbujmy jeszcze głębiej zgłębić Państwa biegłość w posługiwaniu się metaforą. Jeśli retrospektywa jest biciem serca, to czym jest zespół?

To system. Zespół narządów współpracujących ze sobą. Pełniących różne funkcje. Stara się funkcjonować, rozwijać się i uczyć się. Stara się być zdrowy.

To naprawdę płynnie prowadzi nas do tematu kondycji zespołu. Czy kiedykolwiek zetknęli się Państwo z zespołem, który choć dysfunkcyjny, jest jednak skuteczny? Są osoby o wysokiej wydajności, które borykają się z poważnymi problemami.

Oczywiście, jakoś sobie radzą w codziennym życiu. Ale właśnie o to chodzi – „jakoś sobie radzą”. Jeśli musi się Pan/Pani z czymś „radzić”, to znaczy, że prawdopodobnie jest w tym coś trudnego, co dla osób zdrowych nie stanowi trudności. Traci się przez to pewne możliwości.

To prowadzi nas z powrotem do kwestii przewidywalności. Wydaje mi się, że jedną z najbardziej druzgocących rzeczy związanych z poważnym schorzeniem jest to, jak bardzo nieprzewidywalne stałoby się moje życie. Nie mógłbym naprawdę rzetelnie snuć żadnych planów, ponieważ nie wiem, czy nie upadnę nagle. Być może będę potrzebował karetki i trafię do szpitala. I tak oto mój tydzień legnie w gruzach.

Myślę, że właśnie o to chodzi w kwestii zdrowia i metafory związanej ze zdrowiem. Wkłada się ten dodatkowy wysiłek, aby poprawić sytuację, tak aby życie stało się łatwiejsze.

Z własnego doświadczenia wiem, że nie radzę sobie zbyt dobrze, jeśli chodzi o ćwiczenia i utrzymywanie regularności. Były jednak w moim życiu okresy, kiedy przez kilka miesięcy dobrze mi to wychodziło. Robiłem coś w miarę prostego. Na przykład 10 pompek dziennie. I udawało mi się to przez dłuższy czas.

Kiedy udaje mi się to osiągnąć, moim najistotniejszym spostrzeżeniem dotyczącym tego, jak się czuję, jest to, że nie czuję się większy ani silniejszy. Mam jednak wrażenie, że świat stał się łatwiejszy. Trudności wydają się mniejsze.

Ta płynność. Ta swoboda ruchów, gdy jest się w pełni zdrowym. Myślę, że właśnie to jest celem, do którego dąży się w zespole, gdy odpowiednio go zgrywa się. Dla osób, dla których zespół ten pracuje, oznacza to, że zespół ten jest przewidywalny jak zegar, jest niezawodny, rozumie Pan?

W książce Tima Ferrissa „The 4-Hour Body” pojawia się pojęcie „minimalnej skutecznej dawki”. Nie trzeba być w formie olimpijskiej – chodzi o minimum niezbędne do osiągnięcia pozytywnego efektu. Jakie jest minimum, które możemy zrobić, aby wywrzeć wpływ, pozytywny wpływ na zespół? W wielu przypadkach to wystarczy.

Cechy charakterystyczne zdrowego zespołu stosującego metodologię agile

Na co powinien zwrócić uwagę prowadzący retrospektywę, aby ocenić kondycję swojego zespołu?

Cóż, z pewnością powinni obserwować, jak podejmowane są decyzje. W dobrze funkcjonującym zespole sytuacja ulega zmianom. Wprowadzają drobne poprawki. Dostosowują się. Swobodnie eksperymentują.

Odpowiedzialność nie spoczywa na pojedynczej osobie. Spoczywa na wszystkich. Panuje tu swego rodzaju atmosfera bez obwiniania, w której mówi się: „Hej, to nie poszło zbyt dobrze”. Być może zidentyfikują, że ktoś coś zrobił i spowodowało to problem, ale nie powie się: „Kiedy to zrobiłeś, naprawdę wszystko zepsułeś – co zamierzasz zrobić, aby to naprawić?”. Chodzi raczej o to: „Co możemy zrobić lepiej, aby na to zareagować?”. Wie Pan, że odpowiedzialność spoczywa na całym zespole, nawet jeśli to działania jednej osoby mogły spowodować, że coś poszło nie tak.

Ogólnie rzecz biorąc, istnieje pojęcie niewinności.

Dobrze radzą sobie z konfliktami.

Charakterystyczną cechą dobrego zespołu jest to, że jego członkowie nie milczą — wyrażają swoje niezadowolenie. Dzieje się tak, ponieważ panuje w nim atmosfera pełna poczucia bezpieczeństwa, w której czują się na tyle swobodnie, by poruszać kwestie, które ich niepokoją.

Ostatnia perła mądrości agile’owej

Gdy pozostało już tylko 30 sekund i nie ma żadnego ostrzeżenia, jaka jest Pana/Pani najważniejsza rada dla każdego, kto rozpoczyna przedsięwzięcie oparte na metodologii agile?

Zrób sobie chwilę na retrospektywę, zanim będzie to konieczne.

Wiele zespołów zbiera się, by omówić daną sprawę dopiero wtedy, gdy staje się ona problemem, a cóż, łatwo jest pominąć retrospektywę, gdy wydaje się, że wszystko jest w porządku. Jeśli tak postąpili Państwo, to znaczy, że nie przyjrzeli się Państwo sprawie wystarczająco dokładnie i nie wykryli tego, co może stać się dla nas problemem – za kilka tygodni lub za kilka dni.

Dziękuję!

Serdecznie dziękujemy Jonowi Fazzaro za udział w tym wywiadzie.

Jon jest trenerem agile w zakresie pełnego cyklu programistycznego (Full-Stack) i od ponad dwudziestu lat zajmuje się tworzeniem oprogramowania. Jest praktycznym zwolennikiem nowoczesnych praktyk agile, takich jak programowanie zespołowe, programowanie sterowane testami oraz codzienna współpraca z interesariuszami. Jest również zdecydowanym zwolennikiem leanowego zarządzania produktem oraz myślenia systemowego.

Od 2015 roku Jon regularnie występuje jako prelegent na konferencjach poświęconych oprogramowaniu. Zapraszamy do zapoznania się z artykułem „Oh! The Humanity.”, który stanowi szczegółowe omówienie jego aktualnych poglądów zawodowych.