Choroby trawiące zespoły Scrum #3 — Późna cofka

Późna cofka niczym hiszpańska inkwizycja pojawia się znienacka kiedy ktoś sobie nagle przypomina, że coś już  Done trzeba jednak zmieniać albo ma feedback stawiający to, co zostało do tej pory zrobione pod znakiem zapytania. 

Objawy cofki

Późna cofka niczym hiszpańska inkwizycja pojawia się znienacka kiedy ktoś sobie nagle przypomina, że coś już  Done trzeba jednak zmieniać albo ma feedback stawiający to, co zostało do tej pory zrobione pod znakiem zapytania.  Na codzień Zespół Scrum ustalał wszystkie szczegóły i kolejność prac z Product Ownerem, a teraz dowiadują się od osób trzecich, że jednak to nie było to, o co im chodziło. Gdyby to byli Interesariusze (ang. stakeholders), należałoby poddać w wątpliwość dobrą współpracę na linii Product Owner — Interesariusze.

Przeróbki na ostatnią chwilę przed wydaniem zwykle wprowadzają brak stabilności, defekty i brak spójności wymagań. I podobnie jak w poprzedniej chorobie, zespół po pierwsze będzie zdemotywowany, a po drugie nie będzie się starał w Sprintach, skoro przed wydaniem znowu będą zmiany. Późna cofka przypomina także tsunami. Najpierw pojawia się dziwna cisza, żeby za chwilę pojawiła się fala niszcząca życie.

Przyczyny cofki

Taka sytuacja jest zazwyczaj zasługą późnych testów UAT poza Zespołem Scrum. Tak naprawdę to, co dajemy w ręce biznesu zgadzając się na osobne testy UAT prowadzone kilka Sprintów później jest przyzwoleniem na brak zdecydowania i możliwość zmian zakresu na ostatnią chwilę.

Kolejną przyczyną może być brak zaangażowania Interesariuszy. Na przykład kiedy interesariusze są nieobecni na Sprint Review. Wówczas oglądają Przyrost Produktu późno jeśli nie tuż przed wydaniem i uzurpują sobie prawo liberum veto.

Leczenie cofki

Najlepiej jest pozbyć się osobnej fazy UAT i specjalnego Sprintu przed wydaniem. Testy akceptacyjne powinny być wykonywane przez Product Ownera. Jeśli Product Owner potrzebuje pomocy, to oczywiście może zaprosić osoby z biznesu, ale pozostaje odpowiedzialny za akceptację przed końcem Sprintu. Późniejsze uwagi i feedback od biznesu i użytkowników powinny być traktowane jak nowe elementy Product Backlog i dostarczone w zdecydowanej przez Product Ownera kolejności w następnych Sprintach.

Jeśli interesariusze nieobecni na Sprint Review zgłaszają uwagi, a zespół jest już w trakcie kolejnego Sprintu, powinniśmy umieścić je na Product Backlog. Będą tupali nóżkami i próbowali wywrzeć wpływ przez eskalację, ale zasady powinny zostać utrzymane, bo inaczej nigdy ich nie nauczymy ponosić konsekwencji swoich decyzji.

Inne choroby Zespołu Scrum

Choroby trawiące zespoły Scrum #1 — Wrzódki
Choroby trawiące zespoły Scrum #2 — Bieżączka
Choroby trawiące zespoły Scrum #4 — Spady