Blog

W trakcie jednego z niedawnych szkoleń dla Product Ownerów, jakie prowadziłem, rozgorzała niespodziewanie dyskusja dotycząca wymogu, aby każda Retrospekcja Sprintu owocowała przynajmniej jednym konkretnym usprawnieniem, którego realizację Zespół Scrum podejmie w kolejnej iteracji. Zanim napiszę, czego dotyczyła dyskusja (a właściwie spór), kilka uwag związanych z zapisami znajdującymi się w Scrum Guide.

Otóż co jakiś czas twórcy Scruma dopisują do definicji metody (jest nią właśnie Scrum Guide) rzeczy, które wydawały im się tak oczywiste, że wcześniej nie uznawali za konieczne ich jawnego nazwania. 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.

Na podobnej zasadzie dodano zapis, że Backlog Sprintu musi zawierać plan realizacji co najmniej jednego usprawnienia zidentyfikowanego w trakcie Retrospekcji Sprintu poprzedniego, aby zapewnić ciągłe usprawnianie procesu:

To ensure continuous improvement, it includes at least one high priority way in which the team works, identified in the previous Retrospective meeting.

Scrum Guide, listopad 2017

Rzecz w sumie oczywista, ale jak widać nie do końca, skoro w końcu trzeba było o tym napisać wprost: 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 nie ma żadnej rzeczy, którą dałoby się zrobić lepiej? Że nie pojawiło się nic nowego, co można 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 działanie, które zostanie podjęte, i którego efekty da się doświadczalnie stwierdzić? Niespecjalnie, bo brak informacji, jak zmiana ta będzie przebiegać i co w sumie ma być jej wymiernym 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 rozpoczynania Daily Scrumów tak, by wszyscy zdążyli na nie 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ę w Backlogu Sprintu następującego po Retrospekcji, jest sensowne? Bo przecież wartościowe może być i taka Retrospekcja, w której odbyła się trudna dyskusja, i której efektem jest opadnięcie emocji. I cóż z tego, że akurat tym razem nie prowadzi to do żadnych konkretnych zmian w kolejnym Sprincie…?

Moje wątpliwości

Przeniesienie Daily Scrumów na inną 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 Developerów 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 spóźniania się Developerów na spotkanie. Może tak, może nie. Jeśli mamy tygodniowe Sprinty, przesunęliśmy Daily Scrumy 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, rozmowa jest potrzebna, ale jeśli nie idzie za nią żadna zmiana… to możliwe, że rzeczywiście na dłuższą metę nic się nie zmieni. A przecież skoro rozwiązaliśmy jakiś problem (bo mówimy, że „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?

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 Sprintu owocują dwoma rodzajami usprawnień. Jeden z nich to zmiany w procesie lub zmiany zasad, którymi się kierujemy. Często da się je wdrożyć w życie łatwo, bo są umową lub postanowieniem, że coś będziemy robić inaczej. Jeśli jest z nimi związany wysiłek, to jest on rozłożony w czasie i 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, najczęściej od razu po zakończeniu prac nad realizacją usprawnienia.

Przesuwanie Daily Scrumów tak, aby nie było spóźnień, umówienie się, że będziemy stosować pair programming, wprowadzenie rotacyjnego uczestnictwa w spotkaniach Scrum of Scrums w ramach skalowanego Agile to przykłady usprawnień należących do tej pierwszej kategorii. Natomiast 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 Retrospekcji a Backlog Sprintu

Usprawnienia klasy umowa lub postanowienie ciężko opisać jako rzecz do zrobienia w 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ć np. kolejne zadanie na tablicy scrumowej Zespołu. Praca (wysiłek) związany z realizacją takiego usprawnienia stanie się częścią wielu różnych działań.

W przypadku zmian w procesie warto w Backlogu Sprintu zdefiniować pracę, którą należy wykonać 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.

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 – punktowego lub rozłożonego w czasie. Doskonale poddają się one planowaniu tak, jak prace nad rozwojem produktu i łatwo opisać je w formie elementów Backlogu Sprintu, np. jako zadania, albo w dowolny inny sposób, jakiego używają Developerzy.

Czego wymaga Scrum?

W najnowszym wydaniu Scrum Guide, jaki ukazał się w listopadzie 2017, 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 wskazano, 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ązana 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ć sposoby cyklicznego sprawdzania (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 itd., ale sama jej realizacja może nie wymagać pracy jako takiej (ale np. trzymania się ustalonych zasad). W takim przypadku 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 takie rozmowy budują relacje między ludźmi, pozwalają unikać konfliktów i poprawiają atmosferę, ale na tym nie można poprzestać. Celem Retrospekcji Sprintów 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ż do podniesienia zdolności budowania 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ąd inąd wniosku, że przecież ludzie rozmawiają ze sobą na bieżąco i nie potrzebują do tego „sztucznych wydarzeń” takich, jak Retrospekcja Sprintu.

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 Sprintu w twoim Zespole kończyły się konkretami. By łatwym i szybkim zmianom w procesie, zasadach postępowania oraz umowom lub porozumieniom czynionym przez Zespół towarzyszyły realizowane w Sprintach działania realnie zmieniające sposób, w jaki produkt jest budowany.

Zmiana wprowadzona w listopadzie 2020

Wersja definicji Scruma opublikowana trzy lata później już nie zawiera twardego wymogu definiowania przynajmniej jednego konkretnego usprawnienia w Backlogu Sprintu. Nie oznacza to, że twórcy Scruma zmienili zdanie w ciągu kilku lat. Scrum Guide w wersji z 2020 znacząco różni się od wszystkich poprzednich nie zmianą definicji metody, ale zmianą podejścia do jej opisywania. Jest mniej preskryptywny i skupia się na zasadach, a nie na wskazaniach konkretnych praktyk.

To oznacza, że Zespoły Scrum wciąż muszą identyfikować usprawnienia w ramach Retrospekcji Sprintów, a następnie implementować je w iteracji nadchodzącej. Wszędzie tam, gdzie wymagać to będzie pracy Developerów, zostanie ona opisana w Backlogu Sprintu – nie dlatego, że tak nakazuje Scrum Guide, ale ze względu na to, czym jest, do czego służy i jak używany powinien być ten Backlog.