W pierwszej części cyklu pisałem o nadinterpretacjach i mitach związanych z Backlogiem Produktu i tym, jak ten artefakt powinien być używany w Scrumie.
Pora zająć się Planowaniem Sprintu. Oto garść absurdów, na jakie można się natknąć nie tylko w wielu Zespołach i organizacjach, ale niestety też w niektórych książkach…
Mit 12: Backlog Produktu to jedne źródło pracy w Sprincie
Skoro Sprinty mają służyć do rozwoju produktu, a ten powinien następować wyłącznie na skutek realizacji elementów Backlogu Produktu, wychodzi na to, że w Sprincie nie wolno robić nic, co wcześniej nie zostało umieszczone w tymże Backlogu. Jeśli więc Zespół ma wykonać jakieś prace techniczne, wdrożyć w życie usprawnienia lub naprawić błędy, konieczne jest zdefiniowanie opisujących to elementów w Backlogu Produktu.
Dwa powyższe zdania są oczywiście bełkotem niemającym wiele wspólnego ze Scrumem, ale jak każde kłamstwo, zawierają okruchy prawdy.
Tak, Backlog Produktu ma być jedynym źródłem zmian w produkcie, ale chodzi o zmiany mające na celu rozwój produktu od strony użytkowej i funkcjonalnej, a nie jakiekolwiek zmiany w nim.
I rzeczywiście Sprint służy rozwojowi produktu, ale nie oznacza to, że Zespół w jego trakcie nie ma prawa robić nic innego.
Dlatego Developerzy mogą dokonywać w produkcie zmian czysto technicznych w dowolnej chwili, jeśli uznają to za konieczne dla podniesienia jakości strukturalnej albo spłaty jakiejś części długu technicznego.
Mają też prawo naprawiać błędy, a do Backlogu Produktu trafią zapewne jedynie zgłoszenia takich problemów, których usunięcie jest jednocześnie kosztowne, opłacalne i niezbyt pilne – Product Owner podejmie decyzję, kiedy Zespół się nimi zajmie.
Zespół musi realizować usprawnienia zidentyfikowane w trakcie Retrospekcji – to też praca w Sprincie, która zwykle nie jest związana (choć może być) z dokonywaniem zmian w produkcie.
Są w końcu różne prace utrzymaniowe, wsparcie klienta, udział w szkoleniach itd. Jest też pielęgnacja Backlogu Produktu – czy i ona powinna zostać opisana na liście elementów? Byłby to absurd, aczkolwiek i z tym się kiedyś spotkałem.
Zaśmiecanie Backlogu Produktu elementami opisującymi pracę Zespołu, zamiast rozwoju produktu, bywa symptomem istnienia pseudo-Scruma, który w rzeczywistości jest kiepsko zarządzanym projektem. Pseudo-Backlog to plan tego projektu, a pseudo-Sprinty stanowią kolejne etapy jego realizacji. W tej sytuacji uczciwiej i lepiej byłoby usunąć tę fasadę, bo skoro już musi to być projekt, niechże przynajmniej będzie profesjonalnie prowadzony i jawny.
Mit 13: Cel Sprintu musi obejmować wszystko
Kolejna nadinterpretacja dotyczy Celu Sprintu, który w Scrumie ma wyjaśniać, po co odbywa się iteracja. Wiele Zespołów uznaje więc za konieczne ustalenie takiego Celu, który obejmie komplet elementów Backlogu Produktu podjętych do Sprintu. Mozolą się zatem nad wymyśleniem hasła, które będzie na tyle pojemne, by można upchnąć w nim wszystko.
Jako sarkastyczny typ bardzo chętnie służę pomocą, dlatego podpowiadam idealną formułę tego Celu: „Zrealizować to, co podjęliśmy do Sprintu”, albo – mniej formalnie – „Dowieźć wszystko”.
Moja pomoc zwykle nie spotyka się z entuzjastycznym przyjęciem, bo Zespołom głupio przyznać, że ich Sprinty redukują się do kontenera na wykonywanie zaplanowanego developmentu. Szukają więc czegoś, co brzmi lepiej, choć logicznie jest tożsame z Celami, jakie im podpowiadam.
A jak powinno to wyglądać w dobrze stosowanym Scrumie? Sprint ma przynieść interesariuszom wymierną korzyść dzięki zmianom dokonanym w produkcie. Cel Sprintu wyjaśnia, co jest tą korzyścią. Nie chodzi więc o to, by jednym zdaniem opisać, co się w produkcie zmieni (bo to przecież wynika z listy realizowanych elementów), ale o wyjaśnienie, co interesariusze będą mieli z tych zmian.
Zdarza się, że Sprint służy osiągnięciu jakiegoś Celu, nad którym nie ma aż tyle pracy, by nie było przestrzeni na zrobienie czegoś jeszcze. Wtedy Developerzy mogą i nawet powinni podjąć do realizacji kolejne elementy Backlogu Produktu, pamiętając przy tym, że priorytet w iteracji ma osiągnięcie Celu Sprintu.
Zwykle Cel Sprintu związany jest z większością realizowanych elementów, ale zdarza się, że zaledwie z kilkoma. A w skrajnym przypadku może to być dosłownie jeden element Backlog Produktu. Piszę o skrajnym przypadku, bo jest to dopuszczalne i poprawne, ale nie powinno zdarzać się często.
Przypominam też, że nie każda praca w trakcie Sprintu to development produktu, bo Zespół realizuje usprawnienia, odpowiada na zapytania od użytkowników itd. Są Zespoły, w których idzie na to np. 30% czasu Developerów, więc ich Cel Sprintu, jeśli ma być choć trochę sensowny, musi dotyczyć co najwyżej 70% rzeczy realizowanych w trakcie iteracji.
Mit 14: na Planowaniu musi powstać kompletny Backlog Sprintu
Backlogu Sprintu w opinii wielu Zespołów musi na koniec Planowania Sprintu zawierać szczegółowy plan developmentu. Powoduje to niezdrowe rozrośnięcie się procesu pielęgnacji, jeśli Zespól zechce niezbędne detale ustalić w jej trakcie, albo Planowanie Sprintu potrafi trwać wiele godzin, czasem cały dzień.
Błąd polega na uznaniu, że Backlog Sprintu tworzony jest raz-a-dobrze na początku iteracji, a potem wprowadza się do niego jedynie drobne zmiany. Ma to rzekomo zapewniać w trakcie Sprintu stabilność niezbędną do efektywnego developmentu.
W rzeczywistości w ramach Planowania Sprintu powstaje początkowa wersja Backlogu Sprintu, w którym potem można dokonywać dowolnych adaptacji. Nie może się zmienić jedynie Cel Sprintu, bo to pozbawiałoby sensu całą iterację.
W szczegóły oczywiście trzeba wnikać, ale tylko do poziomu, który umożliwi dokonanie oceny, co jest potencjalnie możliwe do zrealizowania przed końcem Sprintu. Próba dalszego doprecyzowywania planu wymaga od Developerów przewidywania (na jakiej podstawie?) jak przebiegać będą w detalach kolejne dni iteracji, a to ma nikły sens w środowisku pełnym niestabilnej złożoności.
Lepiej, kierując się Celem Sprintu jako wyznacznikiem, ustalić, od czego development się rozpocznie i dla tej jednej (a może dwóch) rzeczy sporządzić bardziej szczegółowy (co nie znaczy, że precyzyjny) plan realizacji.
Dla kolejnych elementów, nad którymi praca zacznie się później, plan może być bardziej zgrubny. Zostanie doprecyzowany już w ramach developmentu, np. w trakcie Daily Scrumów albo po prostu na bieżąco. W ten sposób Backlog Sprintu będzie podlegał ciągłemu dostosowaniu z uwzględnieniem tego, co wydarzyło się w iteracji i może mieć istotny wpływ na dalszy jej przebieg.
Oczywiście taka organizacja pracy jest możliwa, jeśli Developerzy skupiają się na realizacji niewielkiej liczby rzeczy naraz (być może nawet na jednej). Muszą też sprawnie planować działania na bieżąco.
W Zespole, w którym każdy Developer zajmuje się innym tematem, albo w którym każde działanie musi poprzedzać dokładna analiza i precyzyjne rozpisanie strategii developmentu, Planowania Sprintu będą długotrwałe, a Backlog Sprintu stanie się od samego początku bardzo szczegółowy (co nie znaczy, że pozwoli to uniknąć konieczności dokonywania w nim zmian).
Scrum tego nie zabrania, jeśli Developerzy inaczej pracować nie potrafią. Pozostaje wtedy mieć nadzieję, że z czasem się to zmieni. A Scrum Master wręcz odpowiada za to, by nie ograniczyć się do pełnego nadziei oczekiwania, ale działać na rzecz zmiany niekorzystnego stanu spraw.
Mit 15: Developerzy muszą definiować zadania
Kolejny mit związany z Planowaniem Sprintu i przy okazji z organizacją pracy to rzekomy obowiązek tworzenia zadań (ang. tasks) do opisu działań, jakie mają wykonać Developerzy. Backlog Sprintu ma jakoby stanowić zbiór elementów Backlogu Produktu wraz z przytroczonymi do każdego z nich zadaniami (najlepiej starannie wycenionymi, żeby dało się „precyzyjnie ocenić”, czy da się je zrealizować w czasie Sprintu).
Jest to dość często spotykany sposób zarządzania Backlogiem Sprintu i sporo Zespołów faktycznie posługuje się zadaniami, ale Scrum tego nie wymaga. Developerzy mają pełną dowolność odnośnie do tego, jaką formę będzie miał Backlog Sprintu i w jaki sposób zorganizują sobie pracę.
Ten mit wynika chyba bardziej z przyzwyczajeń wielu użytkowników Scruma niż z jakiegokolwiek dobrego powodu. Czasami nakłada się na to jeszcze wymóg ze strony kierownictwa, by Developerzy raportowali czas pracy w powiązaniu z konkretnymi zadaniami. W takim przypadku tym bardziej każdy z nich chce mieć „swoje zadania”.
Dojrzałe Zespoły Scrum częściej zamiast tego posługują się np. tablicą kanbanową (i w ogóle Kanbanem), przez którą płyną nie tyle zadania, ile całe elementy Backlogu Produktu. Plan ich realizacji opisany jest w formie np. list kontrolnych przytroczonych do elementów. Inne Zespoły dokonują dekompozycji elementów Backlogu Produktu na mniejsze problemy – ale wciąż nie są to zadania – i z nich konstruują Backlog Sprintu. Naprawdę, można wymyślić mnóstwo lepszych rozwiązań tego problemu niż tworzenie zadań.
Mit 16: Planowanie to kontrakt, z którego rozlicza się Developerów
Jeden z najstarszych i najdłużej za Scrumem ciągnących się mitów powiada, że Planowanie Sprintu polega na zawarciu kontraktu pomiędzy Product Ownerem a Developerami, którzy zobowiązują się do zrealizowania określonych zmian w produkcie do końca Sprintu. Jeśli ktoś ma trochę lepsze pojęcie o Scrumie, wciąż może być przekonany, że Planowanie to zawieranie kontraktu, ale dla odmiany między całym Zespołem, a jego interesariuszami.
Historycznie lista elementów Backlogu Produktu podejmowanych do Sprintu nazywana była zobowiązaniem (ang. commitment), co jest jednym ze źródeł nieporozumienia. Chodziło o deklarację intencji, czyli Zespół deklarował, w co się zaangażuje, a więc co chce osiągnąć dla interesariuszy. Nie chodziło natomiast o zawarcie jakiejś umowy z kimkolwiek.
Aby wyeliminować nieporozumienia, w Scrumie mowa od dawna o prognozie (ang. forecast), a nie zobowiązaniu – ma to podkreślić, że nie ma gwarancji, iż to, co podjęte zostało do Sprintu, faktycznie da się zrealizować przed jego końcem. Planowanie Sprintu polega przecież na postawieniu dwóch hipotez, a mianowicie że:
- coś jest możliwe do zrobienia,
- zrobienie tego przyniesie interesariuszom korzyści.
Przebieg Sprintu pozwoli te hipotezy potwierdzić lub doprowadzi do ich obalenia. A potem trzeba zdecydować, co dalej.
Mit 17: Za każdą rzecz musi odpowiadać konkretny Developer
Kolejne nieporozumienie, będące być może pochodną tego poprzedniego, to przypisywanie w trakcie Planowania Sprintu osób odpowiedzialnych za dokonanie poszczególnych zmian w produkcie. A jeśli są tworzone zadania, to nierzadko z góry określane zostaje, kto ma ja wykonać. Ewentualnie Developerzy tworzą zadania „dla siebie” i w ten sposób powstaje plan działania w Sprincie.
Ma to jakoby zapewniać przejrzystość, bo wiadomo, kto odpowiada za poszczególne elementy Backlogu Produktu lub zadania.
Scrum nie wymaga takiego przypisywania odpowiedzialności. A wręcz stoi to w sprzeczności z sensem istnienia wszechstronnego Zespołu, który wspólnie pracuje nad złożonymi problemami, łącząc kompetencje tak, by dzięki temu zrobić coś, czego w krótkim czasie (lub w ogóle) jedna osoba zrobić by nie zdołała.
Developerzy powinni tworzyć plan dla Zespołu, a nie każdy dla siebie. Maksymalizują w ten sposób szansę, że wspólnie zdołają go zrealizować, dynamicznie dokonując niezbędnych zmian w trakcie Sprintu. Jeśli każdy stworzy „swój plan”, równie dobrze Zespołu mogłoby nie być.
Mit 18: Planowanie ma być oparte o wyceny oraz velocity i capacity
Panuje przekonanie w wielu Zespołach i organizacjach, że podstawą do Planowania Sprintu powinny być trzy rzeczy:
- wyceny elementów Backlogu Produktu,
- informacja o prędkości (ang. velocity) uzyskiwanej przez Zespół w poprzednich Sprintach,
- dostępność Developerów (ang. capacity), być może nawet z rozszyciem na różne kompetencje, jakie posiadają.
Na tej podstawie da się rzekomo dokonać najefektywniejszego planowania, dzięki któremu:
- nie zostanie podjęte do Sprintu ani za mało, ani za dużo,
- każdy będzie miał „dostatecznie dużo pracy”.
Oczywiście z tego wynikać musi obowiązek szacowania (a pisałem, że go nie ma) oraz monitorowania velocity.
Jak łatwo sprawdzić, żadnej z tych rzeczy Scrum nie wymaga. Jasne, można w ten sposób zorganizować pracę Zespołu i posłużyć się wspomnianymi praktykami, niemniej nie musi to przynieść spodziewanych korzyści. Choćby dlatego, że one są oparte o dwa niewypowiedziane założenia, które są z gruntu fałszywe.
Pierwsze założenie: Zespół działa najefektywniej, jeśli każdy jest równo obłożony pracą, najlepiej taką, w której jest specjalistą. Tyle że to nieosiągalne w dynamicznie zmieniającym się i nieprzewidywalnym środowisku. A nawet jeśli ludzie rzeczywiście pracują tak samo długo, nie oznacza to, że są pracą obciążeni w równym stopniu.
Drugie założenie: historyczne velocity dostarcza wiedzy o możliwościach Zespołu, więc jest dobrym punktem odniesienia przy ocenie, co jest możliwe do zrealizowania w kolejnym Sprincie. To też bzdura, bo przebieg Sprintu zależy nie tylko od liczby realizowanych rzeczy, ich wycen i dostępności ludzi, ale również od konkretnego rodzaju prac, jaki trzeba wykonać, od kolejności działań, dostępności osób o określonych kompetencjach w konkretnym momencie itd. Velocity to przecież liczba pozbawiona sama w sobie kontekstu, który wyjaśniałby, skąd się wzięła.
Jeśli już Zespół chce się posłużyć jakimiś miarami i ma wystarczająco stabilny proces, by sięganie po dane historyczne miało jakikolwiek sens, to lepiej wspierać się w trakcie Planowania Sprintu nie velocity, ale przepustowością i symulacjami Monte Carlo na jej podstawie.
Mit 19: Sprint zaczyna się po zakończeniu Planowania
Drobnym, ale wartym wspomnienia nieporozumieniem jest to dotyczące momentu rozpoczęcia Sprintu. Wielu użytkowników Scruma uważa, że najpierw odbywa się Planowanie Sprintu, a dopiero potem zaczyna się iteracja, która kończy się przed Przeglądem Sprintu. Ba, narzędzia elektroniczne miewają np. przełącznik „rozpocznij Sprint”, który należy przestawić właśnie po zakończeniu Planowania (ty już wiesz, droga – w sensie pekuniarnym – Jiro, że to znów o tobie).
A jak jest naprawdę? Planowanie Sprintu jest pierwszym zdarzeniem w Sprincie, co oznacza, że gdy się rozpoczyna, startuje też Sprint. I Sprint ten trwa do momentu zakończenia Retrospekcji. Po Planowaniu zaczyna się development, czyli realizacja zmian w produkcie i to on zakończyć powinien się przed Przeglądem.
Ciąg dalszy nastąpi
Już wkrótce pojawi się kolejna część listy rzeczy, których w Scrumie nie ma, a z różnych powodów niektórzy uznają je za obowiązkowe.