Blog

Na jednym z niedawnych szkoleń Product Owner Toolbox, jakie prowadziłem, rozgorzała niespodziewanie dyskusja dotycząca wymogu, aby każda retrospekcja zespołu scrumowego owocowała przynajmniej jednym konkretnym usprawnieniem, którego realizację zespół podejmie w kolejnym sprincie. Zanim napiszę czego dotyczyła dyskusja (a właściwie spór), kilka uwag związanych z samym Scrum Guide.

Otóż co jakiś czas twórcy Scruma dopisują do definicji metody (czyli właśnie do Scrum Giude) rzeczy, które wydawały się nie potrzebować jawnego nazwania i wskazania palcem, a mimo to użytkownikom metody umykały. Tak na przykład jest z wizją produktu, która powinna zostać przedstawiona przez Product Ownera, w czym pomóc powinien Scrum Master; tak jest z wartościami Scrum, które związane z metodą są od zawsze, ale dopiero niedawno pojawiły się w definicji Scruma – Scrum Guide.

Na podobnej zasadzie dodano zapis, że backlog sprintu musi zawierać plan realizacji co najmniej jednego usprawnienia zidentyfikowanego w czasie retrospekcji sprintu poprzedniego, aby zapewnić ciągłe usprawnianie procesu. Rzecz w sumie oczywista (ale widać nie do końca, skoro w końcu trzeba było o tym napisać): retrospekcja ma owocować działaniami jakie podejmiemy w kolejnym sprincie.

Skoro dokonujemy inspekcji, to towarzyszyć jej musi adaptacja. Zrobienie retrospekcji, z której nie wynika żadne działanie oznacza, że… No właśnie, co to oznacza? Że nie ma żadnej rzeczy, którą dałoby się zrobić lepiej? Że nie pojawiło się nic nowego, co można by wypróbować w ramach eksperymentu? Że jesteśmy już doskonali?

Wracając do dyskusji w ramach szkolenia: nie dotyczyła wyłącznie samego wymogu definiowania usprawnień, ale i tego, czym te konkretne usprawnienia są.

„Będę grzeczny, mamo”

Czy postanowienie takie jest konkretnym usprawnieniem, które przekłada się na konkretne działanie, jakie zostanie podjęte i którego efekty da się doświadczalnie stwierdzić? Niespecjalnie, bo brak informacji, jaka zmiana i kiedy będzie podejmowana i co w sumie ma być jej skutkiem. To w istocie deklaracja pewnej intencji, z której może niewiele wyniknąć.

Ponieważ Scrum to coś, co robimy profesjonalnie i najczęściej używany jest do budowania produktów dla zysku (lub innej, szerzej rozumianej wartości), trzeba wysilić się troszkę bardziej.

Na szkoleniu pojawiło się takie pytanie: czy retrospekcja, której jedynym wnioskiem byłaby zmiana godziny Daily tak, by wszyscy zdążyli na niego dotrzeć rano, rzeczywiście zaspokaja wymóg usprawniania zdefiniowany w Scrum Guide?

I drugie trudne pytanie: czy naprawdę „zmuszanie” do tego, żeby cokolwiek pojawiało się backlogu sprintu następującego po retrospekcji jest sensowne? Bo przecież wartościowe może być i takie retro, w którym odbyła się trudna dyskusja, i której efektem jest opadnięcie emocji. I cóż z tego, że akurat to retro nie prowadzi do żadnych konkretnych zmian w kolejnym sprincie…?

Moje wątpliwości

Przeniesienie Daily na inna godzinę: takie postanowienie z retrospekcji da się zrealizować od razu, nie wymaga niemal żadnych działań ani przesadnego wysiłku. I choć niewątpliwie może to dramatycznie poprawić efektywność pracy w sprintach, wydaje się, że da się jednocześnie podjąć inne usprawnienia, trudniejsze do zrealizowania.

Druga wątpliwość dotyczy tego, czy da się na pewno ocenić już po jednym sprincie, że faktycznie taka zmiana rozwiązała problem. Może tak, może nie. Jeśli mamy tygodniowe sprinty, przesunęliśmy Daily o godzinę i przez ten jeden tydzień nikt się nie spóźnił… czy aby na pewno problem nie wróci? A może jednak trzeba poczekać ciut dłużej, żeby mieć tę pewność? Dobrym pomysłem może być tu ustalenie po jakim czasie (lub po ilu sprintach) dokonamy oceny czy problem został rozwiązany a efekty są takie, jakich oczekiwaliśmy.

A co z retrospekcją, która pozwoliła na rozładowanie emocji, ale nie skończyła się żadnym konkretem? Owszem, taka rozmowa jest potrzebna, ale jeśli nie idzie za nią żadna zmiana… to możliwe, że w praktyce na dłuższą metę nic się nie zmieni. A przecież skoro rozwiązaliśmy jakiś problem (bo „para zeszła”) to powinno nam to otworzyć możliwość zrobienia czegoś, co było niemożliwe, zanim emocje nie opadły. Czemu więc nie określiliśmy tej rzeczy? Jasne, mogło braknąć czasu, ale jeśli czas był, to jednak powinniśmy zaplanować jakieś usprawnienie.

Przyznam też, że uwiera mnie nazywanie wymogu definiowania usprawnień „niepotrzebnym przymusem”. Czy można mówić o empirycznej kontroli procesu, jeśli nie dokonuje się w nim ewolucyjnych zmian (adaptacji)? To miałoby sens tylko tam, gdzie nie borykamy się ze złożonością lub nieprzewidywalnością. Jeśli użycie Scruma jako metody jest uzasadnione, to równie uzasadnione (i niezbędne do działania tej metody) jest ciągłe usprawnianie (adaptacja, ewolucja) procesu.

Dwa rodzaje usprawnień

Często wspominam osobom, z którymi pracuję (również uczestnikom szkoleń), że retrospekcje owocują dwoma rodzajami usprawnień. Jeden z nich to zmiany w procesie lub zmiany zasad, którymi się kierujemy. Zazwyczaj da się je przeprowadzić łatwo, bo są „umową-postanowieniem”, że coś będziemy robić inaczej. Jeśli jest z nimi związany wysiłek, to jest on rozłożony w czasie, bo wynika z konieczności przestrzegania w sposób powtarzalny poczynionych ustaleń. Raczej nie jest to duży wysiłek jednorazowy. A żeby mieć pewność, że nowe zasady się utrwaliły (dają powtarzalne rezultaty), i że te rezultaty są zgodne z naszą intencją, potrzeba czasu: dni, tygodni, a być może wielu sprintów.

Drugi rodzaj usprawnień to te, które wymagają wykonania konkretnej pracy, podjęcia jednorazowego lub rozłożonego na jakieś etapy wysiłku, który da konkretny rezultat. Oczywiście czasami też nie od razu, ale zdecydowanie większe jest prawdopodobieństwo, że „owoce” pojawią się szybko.

Przesuwanie Daily aby nie było spóźnień, umówienie się że będziemy robić pair-programming, wprowadzenie rotacyjnego uczestnictwa w spotkaniach Scrum-of-Scrums etc. to usprawnienia należące do tej pierwszej kategorii. Za to wdrożenie narzędzia do przeprowadzania statycznej analizy kodu, automatyzacja krytycznych testów biznesowych, zmiana formy i sposobu używania backlogu sprintu – to kategoria druga, bo wymaga wykonania pracy, nierzadko sporej i zajmującej dużo czasu.

Wnioski z retrospektywy a backlog sprintu

Usprawnienia klasy „umowa-postanowienie” ciężko opisać jako element backlogu sprintu, bo nie jest to coś, co robimy raz, ale stała zmiana w procesie. O nowym sposobie działania musimy pamiętać przez cały czas, nie może więc to być kolejne pojedyncze zadanie na tablicy zespołu. Praca (wysiłek) związany z realizacją takiego usprawnienia stanie się częścią wielu innych działań.

W przypadku zmian w procesie warto w backlogu sprintu zapisywać zadania, które muszą zostać wykonane celem sprawdzenia (zapewne więcej niż raz), czy uzyskujemy spodziewane rezultaty. Aby dokonać takiej inspekcji, niezbędne jest określenie klarownych warunków, których spełnienie uznamy za potwierdzenie pozytywnego wpływu zmiany. Możemy tu posłużyć się kryteriami akceptacyjnymi, podobnie jak to czynimy dla wymagań biznesowych realizowanych w kolejnych sprintach.

Przy czym najczęściej jest tak, że na efekty zmiany w procesie trzeba poczekać dłużej. Weźmy owo usprawnienie polegające na przesunięciu godziny rozpoczęcia Daily Scruma: czy po zmianie rezerwacji sali i odbyciu jednego spotkania o nowej godzinie uznamy, że zmiana jest „done”? Jasne, że nie. Dopiero po tygodniu, może na koniec sprintu lub po dwóch kolejnych sprintach możliwe stanie się ocenienie, czy faktycznie znacząco spadła liczba nieobecności i spóźnień na Daily.

Dużo prościej jest z uwzględnieniem w backlogu sprintu usprawnień przekładających się na konkretne działania, wymagające mierzalnego wysiłku rozłożonego w czasie. One jak najbardziej poddają się planowaniu tak jak prace nad rozwojem produktu i łatwo dekomponuje się je na przykład na zadania – elementy backlogu sprintu.

Czego wymaga Scrum?

W najnowszym wydaniu Scrum Guide znaleźć można wymóg, by zespół uwzględnił w backlogu sprintu przynajmniej jedno usprawnienie, które jest wynikiem zakończonej retrospekcji sprintu poprzedniego. Nie jest określone jakie zmiany (udoskonalenia) można uznać za wystarczające do spełnienia tego postulatu. Można więc uznać, że wszystko, co przełoży się na wysiłek dający się jakoś opisać w formie elementu backlogu sprintu jest dopuszczalne. Przy czym, jak pisałem wcześniej, wysiłek (praca) nie musi być związany z samym „przeprowadzeniem zmiany”, ale może wynikać z konieczności ciągłego dbania, by z tej zmiany się nie wycofać. Elementy backlogu sprintu mogą też opisywać cykliczne sprawdzenia (monitorowania) efektów wprowadzenia usprawnienia.

Moim zdaniem twórcy Scruma dążą do tego, byśmy zbyt łatwo nie poprzestawali na definiowaniu wyłącznie usprawnień klasy „zmieńmy proces w pół godziny i będzie fajnie”. Zmiana procesu to nierzadko wyzwanie okupione tysiącami godzin poświęconych na naukę, rozwiązywanie problemów, przekonywanie ludzi etc. Ale zmiana taka jak wspomniane przesunięcie Daily na późniejszą godzinę jest całkiem prosta i nie ma powodu, by równocześnie z nią nie podjąć się realizacji choć jednego usprawnienia, które wymaga większego wysiłku (pracy). A wtedy rzeczywiście w backlogu sprintu znajdzie się przynajmniej jeden element opisujący konkretne działania (wysiłek)…

Zachowajmy przy tym zdrowy rozsądek. Jeśli rzeczywiście dla jakiegoś zespołu osiągnięciem jest to, że ludzie w ogóle otwarcie ze sobą pogadali (tu zachęcam do refleksji skąd tak naprawdę będzie wiadomo, że to nie pozorna otwartość…?), na siłę nie szukajmy konkretnych działań do zrealizowania w następnym sprincie. Czasami robimy coś niekoniecznie w stu procentach wedle Scrum Guide, bo mamy ku temu dobry powód. I tak jest w tym przypadku: nie zapominając o konieczności dokonywania usprawnień, musimy zadbać o relacje między ludźmi, bo bez tego Scrum nie działa lub działa marnie. Byleby takie odstępstwo od obowiązujących reguł nie stało się u nas codzienną praktyką.

Prawdziwym problemem i gwoździem do trumny Scruma będzie permanentne zignorowanie wymogu realizowania choć jednego konkretnego usprawnienia w każdym sprincie i ograniczenie retrospekcji wyłącznie do „pogadania sobie”. Niezaprzeczalnie rozmowy budują relacje między ludźmi, pozwalają unikać konfliktów i poprawiają atmosferę, ale na tym nie można poprzestać. Celem retro jest zarówno budowanie i pielęgnowanie relacji międzyludzkich, jak i empiryczne udoskonalanie procesu, w którym budowany jest produkt. Organizacja zatrudniająca ludzi i umawiająca się z nimi na pracę w profesjonalnym Scrumie może oczekiwać, że użyty on zostanie nie tylko do zapewnienia, że fajnie się im ze sobą pracuje, ale też (a może przede wszystkim?) do pozyskania „fajnych” (czyli wartościowych) produktów.

Długofalowe konsekwencje

Doświadczenie w pracy z różnymi zespołami ujawnia jeszcze jedną istotną rzecz. Jeśli retrospekcje ograniczają się do rozmów, bez konkretnych rezultatów, po pewnym czasie zaczynają zanikać jako zdarzenie w procesie. Stają się coraz mniej konkretne, zamieniają się w spotkanie przy kawie. Ba, mogą przestać być robione, bo zespół dojdzie do słusznego skądinąd wniosku, że przecież ludzie rozmawiają ze sobą na bieżąco i nie potrzebują do tego „sztucznych” wydarzeń takich jak retrospekcja.

A jeśli zadowala nas, że pogadaliśmy i „jest fajnie”, to niczego nie będziemy udoskonalać. W końcu jednak przestanie „być fajnie” (rzecz nieunikniona, jeśli zespół przestanie się rozwijać), a wtedy ludzie mogą okazać się niezdolni do dokonania usprawnień, bo nigdy nie nauczyli się tego robić.

Dlatego drogi Scrum Masterze, jeśli to czytasz, zadbaj o to, by retrospekcje kończyły się konkretami. By łatwym i szybkim zmianom w procesie, zasadach postępowania oraz „umowom-porozumieniom” czynionym przez zespół towarzyszyły realizowane w sprintach działania realnie zmieniające środowisko, w jakim produkt jest budowany.