Tytułowe pytanie zadałem w trakcie jednego z ostatnich szkoleń grupie uczestników, którzy już zapoznali się z zasadami Scruma i nawet deklarowali pewne doświadczenie w tej metodzie. Wydawało się trywialne, a wywołało dłuższą dyskusję i skłoniło mnie do napisania krótkiego artykułu na ten temat.
Oczywiście wyjaśnię, o co trzeba zadbać przed pierwszym Planowaniem Sprintu, ale zacząć trzeba od odpowiedzi na zupełnie inne pytanie.
Po co są Sprinty?
Iteracje w metodach zwinnych, w tym i w Scrumie, gdzie nazywają się Sprintami, mają kilka zasadniczych funkcji.
Przede wszystkim służą wytwarzaniu w krótkich interwałach czegoś wartościowego i nadającego się do użycia, co można poddać sprawdzeniu pod kątem przydatności oraz wartości. Dzięki temu planowanie dalszych działań oparte jest na empirycznych danych (wnioskach ze sprawdzenia działającego produktu), a nie wirtualnych planach, projektach, założeniach itd.
Sprinty są krótkie, więc redukują ryzyko podążania zbyt długo w złą stronę w naiwnej wierze, że kierunek jest właściwy. Jeśli postęp prac jest zbyt wolny albo podjęte zostały błędne decyzje, najpóźniej na koniec iteracji fakt ten stanie się widoczny.
W istocie Sprinty służą do walidowania hipotez odnośnie do tego, co jest możliwe do zrobienia przed końcem iteracji i jaką korzyść to przyniesie, jeśli faktycznie zrealizowane zostanie. Dzięki temu da się szybko potwierdzić lub obalić kluczowe założenia biznesowe.
Co więcej, Cel Sprintu i zakres prac ustalane są indywidualnie na początku każdej iteracji. W połączeniu z krótkim czasem trwania Sprintu pozwala to szybko zareagować na pilne problemy i zmiany potrzeb interesariuszy bez przerywania rozpoczętych już prac w połowie. Dzięki temu proces jest stabilny, a jednocześnie jego inercja jest niewielka.
Można też powiedzieć, że Sprinty pozwalają na uzyskanie równowagi pomiędzy koniecznością szybkiego reagowania na zmiany potrzeb interesariuszy oraz koniecznością zapewnienia czasu i stabilności niezbędnych do tego, by można było wytworzyć cokolwiek wartościowego.
Sprinty zawsze odbywają się po coś – Cel Sprintu zapewnia skupienie ludzi na tym, co ważne i ułatwia podejmowanie decyzji. Z jednej strony pozwala to odejść od bardzo detalicznego planowania z góry na rzecz planowania działań w znacznym stopniu just-in-time, z drugiej sprzyja zaangażowaniu ludzi, którzy mogą sami podejmować wiele decyzji i organizować swoją pracę.
Regularny rytm Sprintów ułatwia planowanie działań, np. rezerwowanie niezbędnych zasobów czy organizację spotkań. Ten rytm pozwala też łatwiej analizować różne miary i dane statystyczne oraz zauważać pozytywne lub negatywne trendy różnych zjawisk.
Przed pierwszym Sprintem
Wróćmy do listy rzeczy, bez których rozpoczęcie prac w Sprincie nie jest możliwe. Wymienię je w określonym porządku nie bez przyczyny, bo układają się w pewien ciąg logiczny. Rzecz jasna opisane składniki mocno od siebie zależą i w niektórych przypadkach kolejność, w jakiej można je uzyskać, będzie trochę inna.
Składnik 1: definicja produktu
Zacząć trzeba od jakiejś definicji produktu. Niekoniecznie musi to być świetnie dopracowana wizja, obłożona setkami analiz, modelami biznesowymi czy wynikami eksperymentów rynkowych. Nie musimy od razu tworzyć szeregu canvasów, modelować grup docelowych, tworzyć person itd. Niemniej produkt musi zostać zdefiniowany przynajmniej na tyle, by dało się wiedzy o nim użyć jako kontekstu w kolejnych krokach.
Oczywiście produkt należy rozumieć tutaj bardzo szeroko, czyli może to być zarówno coś fizycznego, może to być twór wirtualny (np. oprogramowanie), ale też usługa, proces biznesowy lub cokolwiek, co może istnieć i być rozwijane długo, przynosząc komuś korzyści. Zdecydowanie nie chodzi tu np. o jeden egzemplarz krzesła – jeśli już, to o stworzenie, utrzymanie i dalszy rozwój całego procesu wytwarzania i sprzedaży takich krzeseł.
Składnik 2: Product Owner
Skoro jest produkt, ktoś musi chcieć, by on powstał i traktować go jako coś swojego. Czasami zdarza się, że to Product Owner jest pomysłodawcą produktu, ale bywa odwrotnie – nie do końca wiadomo, jak pojawiła się idea, by produkt wytworzyć, a potem ktoś poczuł się odpowiedzialny za to, by przekuć ją w rzeczywistość.
Bywa niestety i tak, że Product Owner zostaje wyznaczony przez pomysłodawców produktu, albo wręcz jest zatrudniony tylko po to, by dopilnować jego wytworzenia. Niemniej wciąż jakiś Product Owner musi być, jeśli ma istnieć przejrzystość odnośnie do tego, kto decydował będzie o kierunku rozwoju produktu.
Składnik 3: kluczowi interesariusze
Produkt zawsze powstaje po coś, a mówiąc precyzyjniej, dla kogoś. Ma rozwiązywać czyjeś problemy, być użyty do czegoś, w czymś pomagać, coś umożliwiać itd. Są produkty, które powstają na potrzeby jednej osoby. Są takie, które wytwarzane są dla milionów użytkowników.
Warto zauważyć, że definicja produktu do pewnego stopniu wymaga zidentyfikowania potencjalnych interesariuszy już na samym początku, bo bez nich produkt byłby bezsensowny. Jednakże dopiero Product Owner podejmie decyzję o tym, które potrzeby i których interesariuszy weźmie pod uwagę. Można więc powiedzieć, że przed rozpoczęciem pierwszego Sprintu konieczne jest doprecyzowanie, dla kogo produkt będzie rozwijany. Oczywiście to może zmienić się z czasem – chodzi o ustalenie początkowej grupy interesariuszy.
Zdarza się, że produkt powstaje nie po to, by odpowiedzieć na czyjeś potrzeby, ale ma posłużyć inwestorom do wepchnięcia jakiegoś rozwiązania na rynek i wygenerowania zainteresowania nim. Niektórzy powiedzą, że wtedy brak jest interesariuszy, ale to nieprawda – są nimi zarówno wspomniani inwestorzy, jak i potencjalni użytkownicy nieistniejącego jeszcze produktu.
Składnik 4: Cel Produktu
Gdy Product Owner pozna wystarczająco potrzeby kluczowych interesariuszy, może określić pierwszy Cel Produktu, który trzeba osiągnąć. Nie chodzi tu o „dużą funkcjonalność produktu”, ale o wyjaśnienie, po co produkt będzie rozwijany na początku, co ma pozwolić osiągnąć. Łatwo wyobrazić sobie, że pomysłów, co powinno być pierwszym Celem, będzie wiele – dlatego też potrzebny jest Product Owner, by wybrać jeden z nich.
Jeden Cel Produktu wskazywany przez konkretną osobę pozwala uniknąć sytuacji, w której rozwój produktu zmierza w wielu kierunkach naraz, nie przynosząc przez długi czas żadnych korzyści. Wiadomo kto decyduje, a sam decydent zmuszony jest wskazać jeden Cel, więc musi wysilić się na określenie kryteriów, którymi będzie kierował się w trakcie wyboru.
Składnik 5: zręby Backlogu Produktu
Po ustaleniu Celu Produktu można zacząć dyskutować o tym, jak Cel ten osiągnąć. W ten właśnie sposób Product Owner identyfikuje pierwsze elementy Backlogu Produktu i układa je w kolejności, w jakiej powinny być zrealizowane. Można powiedzieć, że powstaje wstępny plan rozwoju produktu – oczywiście niekompletny i mało precyzyjny.
Ten początkowy Backlog Produktu będzie od tej pory rozwijał się dalej, w miarę jak Product Owner dowiadywał się będzie o kolejnych rzeczach, które trzeba zrobić, by Cel Produktu osiągnąć. Zaczyn Backlogu nie będzie duży, ale pozwoli wstępnie określić charakter prac, jakie trzeba wykonać, by poszczególne elementy zrealizować.
Prawdopodobnie na tym etapie Product Ownera wesprą jacyś Developerzy, aby dostarczyć niezbędnej wiedzy odnośnie do kwestii technologicznych związanych z rozwojem produktu.
Składnik 6: Developerzy
W końcu do Product Ownera powinni dołączyć Developerzy, którzy będą w stanie przekuć elementy Backlogu Produktu w działające rozwiązania, ale też pomogą w dalszym kształtowaniu samego Backlogu. Dzięki temu, że już wiadomo, jaki produkt ma powstawać, a nawet znana jest lista pierwszych rzeczy, które powinny być zrobione, łatwiej określić kompetencje, które Developerzy powinni mieć. Można też wstępnie ocenić, jak wielu Developerów powinien liczyć Zespół.
Czy można Developerów zatrudnić wcześniej? Tak, choć samo formowanie Zespołu lepiej pozostawić do momentu, gdy choćby zgrubnie zarysuje się Backlog Produktu. Bez tego powstanie spore ryzyko, że kompetencje osób w przedwcześnie utworzonym Zespole marnie pasować będą do tego, co przyjdzie im robić.
Składnik 7: Definicja Ukończenia
Aby zaplanować pierwszy Sprint, w którym powstanie pierwsza działająca wersja produktu, trzeba określić, czym jest działający produkt. Inaczej mówiąc, jakie kryteria jakościowe musi spełniać, by uznać, że prace nad nim zakończyły się, a rozwiązanie nadaje się do użycia.
Jakiś zarys przyszłej Definicji Ukończenia może przewijać się w dyskusjach już wcześniej, zwłaszcza przy ustalaniu, jakich kompetencji będą potrzebować Developerzy. Teraz trzeba ją sprecyzować i upewnić się, że jest przez wszystkich w Zespole rozumiana tak samo. Niewykluczone, że ujawni to konieczność uzupełnienia kompetencji przez Developerów, albo wręcz zmiany składu Zespołu.
Składnik 8: ustalenie czasu trwania Sprintów
Zanim rozpocznie się pierwsza iteracja, trzeba określić interwał, w jakim będą się one odbywać. Planowanie Sprintu wymaga bowiem od Developerów, by stworzyli prognozę tego, co są w stanie w pełni ukończyć w czasie rozpoczynającej się iteracji. Muszą zatem wiedzieć, kto będzie w trakcie Sprintu pracował, jakie kryteria jakościowe trzeba spełnić (tu pojawia się Definicja Ukończenia) oraz jakim czasem dysponują.
Ustalenie długości Sprintów może nie być trywialne, ale z czymś trzeba zacząć. Wziąć należy pod uwagę nie tylko poziom zmienności potrzeb interesariuszy (im jest ona większa, tym Sprinty powinny być krótsze), ale również realne możliwości Developerów. Warto pochylić się nad elementami Backlogu Produktu, bo z ich charakteru często wynika to, jaka minimalna długość Sprintu może mieć sens.
Składnik 9: pielęgnacja Backlogu Produktu
Gdy już Zespół ustali, jak długie mają być Sprinty, może okazać się, że niektóre elementy Backlogu Produktu są zdecydowanie za duże, by dało się je zrealizować w czasie jednej iteracji, a znajdują się na szczycie listy. To dobry moment, by przeprowadzić pierwszą pielęgnację Backlogu, która odtąd powinna stać się stałym procesem.
Oczywiście nie chodzi o wytworzenie jakiegoś „kompletnego Backlogu Produktu” i ustalenie wszystkiego z góry jeszcze przed rozpoczęciem pracy w Sprintach. Celem jest doprowadzenie elementów na szczycie listy do takiego stanu, by w trakcie Planowania Sprintu cały Zespół zdołał ustalić sensowny Cel Sprintu i prognozę tego, co Developerzy wytworzą, by go osiągnąć.
Składnik 10: przygotowanie narzędzi
Rozpoczynanie pracy nad produktem nie ma sensu, jeśli brakować będzie podstawowych narzędzi i środków niezbędnych do tego. Zanim więc Zespół zaplanuje pierwszy Sprint, powinien zadbać o kluczowe rzeczy. Przy czym niekoniecznie oznacza to, że faktycznie wszystko trzeba z góry przygotować – bo o tym, co ostatecznie będzie potrzebne, zdecyduje przebieg developmentu i nie wszystko da się przewidzieć.
Natomiast nie można zaniedbać kwestii krytycznych, bez których pracy wykonywać się nie da. Jeśli częścią pracy nad produktem będzie wbijanie gwoździ, to bez młotka i sporej ilości gwoździ Sprintu nie ma co planować. A już bardziej serio, jeśli np. wytworzone ma zostać oprogramowanie, Developerzy powinni zawczasu przygotować swoje komputery, żeby nie poświęcać połowy Sprintu na instalację potrzebnych narzędzi.
Niektórzy błędnie nazywają takie przygotowania „Sprintem zerowym” lub „Sprintem zero” – nie ma w Scrumie czegoś takiego.
Po pierwsze dlatego, że taki pseudo-Sprint nie prowadziłby do powstania produktu (czyli Przyrostu), a bez tego wartość faktycznie wytworzona w iteracji jest zerowa (co nawet nieźle pasuje do nazwy tego nowotworu). Czemu zerowa? A do czego da się użyć produktu, którego nie ma? Jaki problem taki produkt rozwiązuje? Nie da się niczego użyć, bo wciąż istnieje jedynie plan rozpoczęcia budowy produktu w Sprincie pierwszym.
Po drugie, wszystkie te przygotowania kończą się, gdy Zespół założy, że jest gotowy do zaplanowania Sprintu pierwszego, ale nijak nie da się tego założenia empirycznie potwierdzić. A skoro każda iteracja w Scrumie ma służyć do walidowania hipotez stawianych na jej początku, „Sprint zero” tego postulatu nie spełnia.
Gotowi? To planujemy!
Można zaplanować pierwszy Sprint, jeśli:
- istnieje Zespół Scrum,
- Zespół ten dysponuje zrozumiałym dla niego Backlogiem Produktu z listą elementów wystarczającą, by zaplanować chociaż jedną iterację,
- ustalona została Definicja Ukończenia,
- wiadomo, jak długo Sprint ma trwać.
Bez Zespołu nie ma kto planować. Bez Backlogu nie wiadomo, co i po co miałoby zostać zrobione. Bez Definicji Ukończenia i wiedzy o długości iteracji nie da się realnie ocenić, co jest możliwe do zrobienia w tym czasie.
Jeśli mamy wszystkie te rzeczy, Sprinty można rozpocząć. Backlog Produktu będzie się rozwijał (wyłaniał) już w trakcie rozwoju produktu, a z czasem udoskonaleniu ulegnie pewnie i Definicja Ukończenia.
Pracujemy w Scrumie, ale…
No, właśnie. Zdarzyło mi się obserwować pseudo-Planowania pseudo-Sprintów w Zespołach, które nie miały określonej Definicji Ukończenia i nagminnie przeciągały pracę nad elementami Backlogu Produktu na wiele iteracji, efektywnie rozmywając ich granice. Często ludzie, którzy tak pracowali, narzekali przy tym, jak straszliwie Sprinty ich uwierają i zarzucali Scrumowi brak pragmatyzmu.
A przecież takie planowanie (małą literą, bo ze zdarzeniem Scrumowym nie ma to wiele związku) sprowadza się do zgrubnej oceny, że „spróbujemy zrobić coś, ale na kiedy i co, to się okaże, bo sytuacja jest skomplikowana”.
Serio „skomplikowana”? Jaka korzyść płynie z nieustalenia Definicji Ukończenia? I cóż takiego straszliwego uniemożliwia jej stworzenie? Obawiam, że głównym motywatorem jest niechęć do przyznania czegoś, co pewnie i tak jest tajemnicą poliszynela, a mianowicie, że produkt jest w stanie nędznym i wytwarzany jest byle jak…
W szczególności po to potrzebny jest w Zespole Scrum Master, żeby coś z tym zrobić i doprowadzić do poprawy sytuacji. Oczywiście wspomniane przeze mnie Zespoły miały tytularnych Scrum Masterów, ale o ich zrozumieniu Scruma i skuteczności w działaniu lepiej zamilczeć.
W którym momencie potrzebny staje się Scrum Master?
Pisałem powyżej o Product Ownerze i Developerach, pomijając Scrum Mastera, zupełnie jakby nie był w ogóle przydatny. W istocie dobrze byłoby, aby pojawił się już w momencie, gdy klaruje się, kto zostanie Product Ownerem. W ten sposób może zapobiec wielu przyszłym problemom, np. ustanowieniu Product Ownera, który ma władzę formalną nad produktem, ale realnej jest zupełnie pozbawiony.
Im później Scrum Master (taki prawdziwy, a nie tytularny, który nic nie potrafi i mało co wie) dołączy do inicjatywy, tym gorzej. Bo, niestety, mimo prostoty Scruma, nie jest to metoda łatwa w zastosowaniu. Dobrze byłoby, aby Product Ownerowi ktoś pomógł w ustaleniu zasad współpracy z interesariuszami. Przyda się adwokat diabła przy dyskusji o Celu Produktu, a może po prostu Scrum Master podpowie, jak ten Cel ustalić. Dobrze byłoby, aby przy tworzeniu Backlogu Produktu nie wpaść w pułapkę tworzenia planu klasycznego projektu. I by Developerzy dobrani zostali tak, by Zespół był wystarczająco wszechstronny… Wiele rzeczy może dobry Scrum Master podpowiedzieć lub sam zrobić.
Moim zdaniem bardzo ważne jest, by Scrum Master dołączył do Zespołu najpóźniej przed dyskusją na temat Definicji Ukończenia. Jest to kluczowa dla empiryzmu kwestia, którą (jak pisałem powyżej) wiele Zespołów potraktowało po macoszemu. A konsekwencje braku Definicji Ukończenia albo sporządzenia Definicji lichej i niejasnej będą potencjalnie ciągnęły się za Zespołem i produktem przez wiele Sprintów.
Co zrobić, jeśli organizacja tworzy Zespół, ale nie zamierza zapewnić mu Scrum Mastera? Cóż, Scrum Master to odpowiedzialność i w tej sytuacji ktoś z osób będących częścią Zespołu musi ją na siebie wziąć. Niekoniecznie Product Owner (choć to nie jest zabronione), najpewniej jeden z Developerów.
Ważne, by osoba ta świadomie brała na siebie odpowiedzialność i miała intencję z niej się wywiązywać, a nie robiła to tylko dlatego, że „ktoś musi być Scrum Masterem”. Dlaczego to ważne? Bo w opisanym modelu ten niedoświadczony Scrum Master będzie musiał szybko nauczyć się dużo, naprawdę dużo rzeczy, żeby skutecznie działać. A tego bez szczerej motywacji nikt nie zechce zrobić.