Cel Sprintu. Jedno zdanie, którego brak kosztuje najwięcej

Uwaga: Artykuł odnosi się do Scrum Guide 2017 (19 stron). W wersji 2020 Sprint Goal wzmocniono, czyniąc go osobnym komponentem Sprint Backlogu i trzecim tematem Sprint Planning, obok “Co” i “Jak” pojawiło się “Dlaczego”.

Mały eksperyment na start. Otwórz Scrum Guide, te dziewiętnaście stron, i policz, ile razy pada w nim „Cel Sprintu”.

Wyjdzie kilkanaście. Na dokument, który spora część branży traktuje jak tekst założycielski. Cel Sprintu należy do elementów Scruma, które najłatwiej pominąć i najdrożej stracić.

Guide opisuje go oszczędnie: każdy Sprint ma cel tego, co ma powstać, oraz elastyczny plan prowadzący przez pracę i przez powstający przyrost. Dwie rzeczy naraz — kierunek i swoboda. Zespoły pamiętają o kierunku. Swobodę gubią po drodze.

Co się dzieje, gdy celu nie ma

Kiedy Sprint nie ma celu, cel pojawia się sam. Brzmi: „skończyć wszystko ze Sprint Backlogu”.

I tu zaczyna się problem. Praca produktowa jest nieprzewidywalna. W połowie Sprintu okazuje się, że jedno zadanie było banalne, drugie kryło pod sobą trzy kolejne, a klient w międzyczasie zmienił zdanie. Zespół, którego jedynym celem jest domknięcie listy, nie ma jak na to zareagować. Lista staje się święta. Każda zmiana zakresu wygląda jak porażka względem planu.

Tak wygląda jeden z objawów Zombie Scruma. Wszystkie wydarzenia się odbywają — planowanie, daily, review, retrospektywa — a pod spodem nic nie pulsuje. Zespół przerabia backlog zamiast rozwiązywać problem.

Praca złożona rządzi się inną logiką

Wytwarzanie oprogramowania to praca złożona. W klasyfikacji Cynefin ląduje po stronie, gdzie związku przyczyny ze skutkiem nie da się ustalić z góry — widać go dopiero z perspektywy czasu. Bywa nazywana „wicked problem”: zadaniem, które definiujesz dopiero wtedy, gdy próbujesz je rozwiązać.

W takiej pracy zmienia się wszystko jednocześnie. Wymagania, technologia, ludzie, zależności między zespołami. Plan zbudowany w poniedziałek bywa nieaktualny w czwartek.

Dlatego Scrum Guide przypisuje Celowi Sprintu konkretną funkcję: daje zespołowi elastyczność co do zakresu funkcjonalności dostarczonej w Sprincie. Kiedy celem jest „czternaście ticketów”, każda niespodzianka jest zagrożeniem. Kiedy celem jest efekt, tickety stają się środkiem, który można wymienić.

Apollo 13, czyli „po co” ważniejsze od „jak”

Jest w „Apollo 13” scena warta trzymania przy sobie jako obraz Celu Sprintu. Na Ziemi inżynierowie wysypują na stół dokładnie te przedmioty, które astronauci mają na pokładzie. Zadanie: dopasować kwadratowy filtr do okrągłego otworu, bo inaczej załoga udusi się własnym dwutlenkiem węgla. Cel jest sztywny — utrzymać ludzi przy życiu. Cała reszta to improwizacja w granicach tego, co jest pod ręką.

Cel Sprintu działa podobnie. Ustala „po co” i zostawia „jak” zespołowi. Ta jedna decyzja uruchamia samoorganizację. Trudno samoorganizować się wokół listy poleceń. Łatwo wokół problemu do rozwiązania.

Jak cel dojrzewa w zespole

Cel Sprintu rzadko rodzi się od razu dojrzały. Przechodzi drogę, którą widać w zespołach pracujących nad nim świadomie.

Najpierw znika słowo „oraz”. Cel z „oraz” to dwa cele w przebraniu jednego. Dobry cel mieści się w jednym zdaniu, jednej myśli, jednym najwyższym priorytecie. Jeśli w środku Sprintu zespół musi wybierać między dwiema połówkami celu, to od początku nie był to cel.

Potem pojawia się grupowanie. Ktoś zauważa, że kilka elementów backlogu dotyka tego samego obszaru, i łączy je w jeden Sprint. Zespół dostaje punkt skupienia zamiast rozproszenia po pięciu frontach.

Kolejny etap to zmiana formy. Cel zaczyna brzmieć jak pytanie otwarte: „Jak moglibyśmy…”, „Czy da się…”, „Co byłoby dobrym sposobem na…”. Pytanie zaprasza zespół do wymyślenia „jak”. Rozkaz tylko go egzekwuje.

Najbardziej dojrzała wersja celu mówi o skutku. Zespół pyta, jaka zmiana w zachowaniu użytkownika pokaże, że cel został osiągnięty. Nazywa założenia, które Sprint ma potwierdzić albo obalić. Stawia hipotezę: jaki wynik albo jaka zmiana zachowania dowiedzie, że kierunek był słuszny. Sprint przestaje być listą do odhaczenia, a zaczyna być eksperymentem z postawionym pytaniem.

Cel Sprintu w Sprint Review

Sprint Review to wydarzenie strategiczne. Służy optymalizacji wartości i budowaniu przejrzystości między zespołem a interesariuszami.

Bez celu Review zsuwa się do pokazu ticketów: zrobiliśmy to, to i tamto. Z celem staje się rozmową o wartości — o tym, czy Sprint przybliżył nas do tego, po co w ogóle był. To dwie zupełnie różne rozmowy, choć na sali siedzą ci sami ludzie.

Cel osiągnięty i nieosiągnięty

Osiągnięty cel warto odnotować. Zespół, który wiedział, po co pracuje, i widzi, że dowiózł, dostaje coś więcej niż zamknięte zadania. Dostaje poczucie, że jego praca miała kierunek.

Nieosiągnięty cel też coś daje. Niesie informację, czasem cenniejszą niż cel dowieziony. Pokazuje, gdzie założenia rozminęły się z rzeczywistością, które oszacowanie było życzeniowe, gdzie leży prawdziwa złożoność. Zespół, który tego nie chowa, uczy się szybciej niż ten, który za wszelką cenę broni statystyki „zielonych” Sprintów.

Na koniec

Cel Sprintu mieści się w jednym zdaniu. Właśnie dlatego tak łatwo go pominąć — wygląda na drobiazg obok całego Sprint Backlogu. I dlatego jego brak widać dopiero po dwóch tygodniach odhaczania zadań, których nikt w zespole nie umie streścić jednym zdaniem.

---

Bibliografia

• Ken Schwaber, Jeff Sutherland, The Scrum Guide, 2017 — definicja i rola Celu Sprintu w Scrum
• Jeff Sutherland, Scrum: The Art of Doing Twice the Work in Half the Time, Crown Business, 2014 — praktyczne zastosowanie Sprint Goals w zespołach
• Eliyahu M. Goldratt, Jeff Cox, The Goal: A Process of Ongoing Improvement, North River Press, 1984 (wyd. pol. Cel I. Doskonałość w produkcji, Mint Books) — cel jako miara odróżniająca ruch od postępu
• David Snowden, Mary E. Boone, A Leader’s Framework for Decision Making, Harvard Business Review, 2007 — klasyfikacja Cynefin i praca w warunkach złożoności