Scrum umożliwia Product Ownerowi dokonywanie zmian w Backlogu Produktu w każdym momencie, gdy uzna, że kolejność elementów Backlogu jest niewłaściwa, albo gdy trzeba usunąć jakieś wymaganie lub dodać nowe. Brak ograniczeń oznacza, że takich zmian Product Owner dokonać może tuż przed Planowaniem Sprintu, albo choćby w trakcie Planowania.
Z drugiej strony to Developerzy mają ostatnie słowo w kwestii tego, ile elementów (wymagań) podejmą z Backlogu Produktu do realizacji w Sprincie. Product Owner ma prawo domagać się od Developerów jak najwięcej, ale nie może im narzucić listy wymagań obszerniejszej niż to, co prognozują oni jako możliwe do ukończenia w ciągu jednej iteracji.
Co powinno stać się, gdy na początku Backlogu Product Owner umieści wymaganie, którego Developerzy nie widzieli wcześniej, które jest niezrozumiałe i prawdopodobnie zbyt duże, by dało się go zrealizować w czasie jednego Sprintu?
Drobna różnica między „ile?”, „które?” i „po co?”
W opisanej sytuacji Developerzy z większości Zespołów Scrum informują Product Ownera, że nie są w stanie podjąć się realizacji takiego „wrzuconego w ostatniej chwili wymagania”. Argumentują, że nie zostało ono omówione w ramach pielęgnacji Backlogu Produktu, więc jest niezrozumiałe, niejasne, zbyt duże itd.
Gdy Product Owner napiera, Developerzy odwołują się do definicji Scruma i przypominają, że wedle jej zapisów to oni wybierają elementy Backlogu Produktu do realizacji w Sprincie. Bardzo często wspiera ich w tym asertywnym podejściu Scrum Master. I wydaje się, że to zamyka temat, ale nie do końca tak jest.
Owszem, to Developerzy decydują o tym, które elementy Backlogu Produktu realizowane będą w rozpoczynającej się iteracji. Natomiast ten wybór nie jest całkowicie swobodny z trzech powodów.
Po pierwsze, zobligowani są do honorowania kolejności elementów w Backlogu Produktu, jaką ustalił Product Owner. Nie mogą więc potraktować Backlogu jako swoistego menu, z którego dowolnie będą wybierać to, co im pasuje.
Po drugie, Sprinty mają kreować wartość (korzyść) dla interesariuszy, czyli istnieć musi jakiś Cel Sprintu, który osiągnięty zostanie dzięki realizacji elementów Backlogu Produktu. To oznacza, że wybór Developerów musi być skorelowany z Celem Sprintu, a Cel ten nie jest ustalany wyłącznie przez Developerów, tylko przez cały Zespół Scrum.
Po trzecie wreszcie, w Sprincie biorą udział nie tylko Developerzy, ale również Scrum Master i Product Owner. Scrum Master wpłynie na pracę developerską swoimi działaniami, Product Owner podejmowanymi na bieżąco decyzjami (bo prawie zawsze w trakcie Sprintu ujawni się coś, o czym Zespół nie wiedział w momencie Planowania Sprintu, a co wpływa na sposób realizacji wymagań).
W praktyce oznacza to, że ostateczną samodzielną decyzyjność Developerzy mają wyłącznie odnośnie do liczby podejmowanych do realizacji elementów Backlogu Produktu. Natomiast o tym, które elementy podjęte zostaną do realizacji, Zespół Scrum decyduje wspólnie. Developerzy nie mogą ignorować oczekiwań Product Ownera, o ile tylko istnieje realna możliwość ich zaspokojenia. Mają oczywiście prawo, a nawet obowiązek dyskutować z nim i nakłaniać go do zmiany zawartości lub kolejności Backlogu Produktu, o ile kierują się w tym dobrem interesariuszy i produktu, a nie np. własną wygodą.
Scrum Master nie powinien więc poprzestawać na nauczeniu Developerów asertywności, ale powinien nauczyć cały Zespół, o co chodzi z tym wyborem, jakiego dokonują w trakcie Planowania Sprintu Developerzy. Chodzi o użycie wiedzy developerskiej do wybrania z początku Backlogu Produktu tych elementów, które są niezbędne, by osiągnąć ustalony Cel Sprintu.
Czy Product Owner może więcej niż inni?
Czasami spotykam się ze stwierdzeniem, że Product Owner nie ma prawo wrzucać do Backlogu Produktu nowych elementów w ostatniej chwili i oczekiwać ich realizacji, bo to naruszałoby zasadę braku hierarchii w Zespole Scrum. Product Owner pozbawia w ten sposób Developerów możliwości przygotowania się do Planowania Sprintu, czym jakoby uniemożliwia im wywiązywanie się z ich odpowiedzialności. Cóż, to nieporozumienie.
Na początek warto przypomnieć, że to Product Owner odpowiada za to, by Backlog Produktu był przejrzysty i by umożliwiał przeprowadzenie Planowania Sprintu. Muszą istnieć jakieś obiektywne przyczyny, dla których decyduje się dokonać istotnej zmiany Backlogu w ostatniej chwili. Nie robi tego po to, by utrudniać życie Developerom, ale ze względu na istotne potrzeby interesariuszy.
Można przyjąć, że jest to sytuacja równie kłopotliwa dla Developerów, jak i dla samego Product Ownera. Przecież Planowanie Sprintu w tej sytuacji będzie trudniejsze, a sam Sprint może zostać obciążony zwiększonym ryzykiem, że nie uda się osiągnąć ustalonego Celu.
Konieczne trzeba też zastanowić się nad konsekwencjami uznania, że prawo Developerów do zapoznania się z każdym elementem Backlogu Produktu z odpowiednim wyprzedzeniem jest nienaruszalne. W oczywisty sposób ograniczałoby to prawo Product Ownera do decydowania o zawartości i kolejności Backlogu, a pośrednio godziłoby w potrzeby interesariuszy.
A jeśli już mowa o odpowiedzialnościach Developerów i Product Ownera, to nie mogą one być realizowane w sposób sprzeczny z sensem istnienia Zespołu Scrum jako całości. Sensem tym nie jest przecież „realizować to, co jest w Backlogu Produktu”, ale budowanie wartościowego produktu. Jeśli wymaga to reakcji na potrzebę zmiany, która ujawniła się w ostatniej chwili, to Zespół powinien tej zmiany dokonać, o ile jest to wykonalne. Formalizm procesowy i spory kompetencyjne w Zespole na pewno w tym nie pomogą.
Na czym polega Planowanie Sprintu
Scrum używany jest tam, gdzie konieczne jest zmaganie się z niestabilną złożonością. Możliwość dyskusji o wymaganiu w ramach pielęgnacji Backlogu Produktu podnosi prawdopodobieństwo, że Developerzy będą lepiej przygotowani do jego realizacji, ale nie daje takiej gwarancji.
A to oznacza, że jeśli na początku Backlogu Produktu pojawią się nowe wymagania tuż przed Planowaniem Sprintu, Developerzy powinni wraz z Product Ownerem szukać sposobu na ich realizację, a nie powodu, by jej odmówić. Jeśli w dyskusji ujawni się przyczyna, dla której realizacja jest niemożliwa, żadne odmowy nie będą wtedy potrzebne.
W wielu Zespołach Planowanie Sprintu polega zwykle na mechanistycznym zgarnianiu z góry Backlogu Produktu takiej liczby elementów, jaką Developerzy uznają za możliwą do realizacji, a następnie kombinowaniu, jakiż Cel Sprintu pozwoli to osiągnąć. W takim modelu działania dobrze wypielęgnowane wymagania są kluczowe i presja na to, by odmawiać realizacji nowych, dopiero do Backlogu dodanych, będzie bardzo silna.
Natomiast nie jest to najlepszy sposób Planowania, bo skupia się ono nie na tym, co ma przynieść Sprint interesariuszom, ale na tym, co ma zostać zrealizowane w Sprincie. Tak rozumiany Sprint staje się po prostu kontenerem na pracę developerską, a nie narzędziem empirycznej kontroli w procesie kreowania wartości.
Jak więc wygląda to w nieco bardziej dojrzałych Zespołach Scrum? Product Owner układa Backlog Produktu w określonej kolejności z jakiegoś powodu, który może stanowić dobry prototyp Celu Sprintu. Inaczej mówiąc, może wyjaśnić Zespołowi (Developerom i Scrum Masterowi), co chciałby, aby przyniósł rozpoczynający się Sprint i w związku z tym, co w jego ocenie trzeba zrobić, by taki pożądany Cel Sprintu osiągnąć. To rozpoczyna dyskusję o dwóch tematach:
- Czy taki Cel jest w ogóle realny?
- Czy Backlog Produktu jest ułożony tak, że faktycznie zgarnięcie z góry elementów i ich zrealizowanie pozwoli Cel osiągnąć?
Z tej dyskusji albo wyłoni się konieczność zmian w Backlogu Produktu, której Product Owner radośnie dokona (bo przecież prowadzić ona będzie do Celu, o jaki mu chodziło), albo do przyjęcia innego Celu niż ten proponowany przez Product Ownera.
Jak widać, Backlog Produktu w tym modelu działania nie stanowi listy, którą należy bezrefleksyjnie realizować z góry na dół, zgodnie z decyzjami Product Ownera (i jeśli chce się coś przeskoczyć, trzeba wykazać, że jest niemożliwe do realizacji, choćby z formalnego powodu w rodzaju „nie było czasu na pielęgnację”). Dla dojrzałego Zespołu Scrum Backlog Produktu stanowi w trakcie Planowania Sprintu podstawę do dyskusji. Wszak to dlatego Product Owner jest tam obecny, by dokonywać zmian w Backlogu, jeśli ujawni się taka konieczność, a nie by dopilnować trzymania się kolejności poszczególnych elementów.
A jeśli na szczycie Backlogu znajdzie się w ostatniej chwili nowe, nieznane wymaganie? Planowanie stanie się o tyle trudniejsze, że poziom niepewności jest wyższy, a ilość pytań będzie większa, niż zazwyczaj. Poza tym Developerzy zadziałają właściwie tak samo, jak zwykle – będą rozmawiać o tym, co jest możliwe, dokonując przy okazji niezbędnej pielęgnacji nowego wymagania.
Jak poradzić sobie z niewypielęgnowanym wymaganiem
Przede wszystkim warto dokonać podziału takiego kłopotliwego wymagania, by wyłuskać z niego to, co najpilniejsze. W ten sposób mniej kluczowe zmiany mogą zostać odłożone w czasie do momentu, gdy uda się o nich porozmawiać w ramach standardowego procesu pielęgnacji Backlogu Produktu.
Czy taki podział nowego wymagania w ogóle będzie możliwy mimo braku wiedzy o nim? Owszem, bo pilne potrzeby są zwykle dobrze zdefiniowane, choć niekoniecznie są przy tym trywialne do zaspokojenia. Choć bywa, że są naprawdę proste i być może nie wymagałyby i tak żadnej pielęgnacji.
Warto też wesprzeć się ekspertami, jeśli tylko da się ich realnie ściągnąć na Planowanie. Jeśli nie, plan realizacji powinien uwzględniać pracę z ekspertami, którzy już w czasie Sprintu pomogą Zespołowi (całemu, a nie samym Developerom) doprecyzować szczegóły.
Kolejna kwestia to ułożenie planu realizacji tak, by najpierw wyeliminować największe niewiadome i ryzyka. Nie ma pewności, że wymaganie nie wybuchnie w rękach Developerom już w czasie Sprintu, ale im wcześniej taki czarny scenariusz się ziści, tym większa jest szansa na poradzenie sobie ze skutkami, nim iteracja dobiegnie końca.
Zdrowy rozsądek nakazuje zaplanować taki Sprint nieco zachowawczo – Zespół powinien pozostawić sobie na nieprzewidzianą pracę nieco więcej czasu niż zwykle.
Aby uniknąć katastrofy już w czasie realizacji, Developerzy powinni też przyjąć zasadę ograniczenia liczby wymagań, które realizują równocześnie – najlepiej do jednego (o ile to możliwe). Przyzwolenie na to, by z kłopotliwym i poniekąd ryzykownym elementem Backlogu pracował tylko jeden Developer, podczas gdy reszta robi coś innego, jest proszeniem się o kłopoty. Prawie na pewno w trakcie prac ujawni się nowa, nieprzewidziana praca i dobrze by było, aby od razu miał ją kto podjąć.
Kiedy Developerzy powinni odmówić realizacji wymagania?
W zasadzie tylko wtedy, gdy odkryją, że nie ma żadnych realnych możliwości ukończenia prac nad jakimś wymaganiem i zbudowania produktu zgodnie z wymogami Definicji Ukończenia. Przy czym trzeba pamiętać, że:
- Brak wiedzy lub otwarte pytania bez odpowiedzi to nie powód do odmowy realizacji wymagania. Można zaplanować zdobycie tej wiedzy i odpowiedzi na pytania jako część prac developerskich.
- Brak umiejętności w Zespole to również nie powód do odmowy realizacji wymagania. Można zaplanować działania, które pozwolą uzyskać tę wiedzę już w trakcie Sprintu lub wsparcie eksperta spoza Zespołu.
- Niespełnione zależności, o których wiadomo, też najczęściej nie są dobrym powodem, by wymagania nie podejmować do realizacji w Sprincie. Można zaplanować sposób poradzenia sobie z zależnością (jej usunięcie, zaspokojenie, lub w ostateczności wytworzenie zaślepki, pozwalającej na tymczasowe działanie produktu bez docelowego komponentu).
Warto tu podkreślić, że często nie da się w sposób obiektywny określić w trakcie Planowania Sprintu, czy rzeczywiście wymagania nie da się zrealizować. Decyzja o rozpoczęciu realizacji lub nie jest zawsze wynikiem jakiejś prognozy i oceny związanego z nią ryzyka. Nadmierna lekkomyślność jest tu równie niewskazana, jak zbytnia zachowawczość – ta pierwsza spowoduje wygenerowanie chaosu, ta druga będzie źródłem marnotrawstwa (czasu, środków i możliwości).
Skąd ten „brak elastyczności” w Scrumie?
Konieczność trzymania się Backlogu Produktu w połączeniu z pracą w iteracjach, których zakres jest planowany na początku, oceniany bywa jako objaw niskiej elastyczności procesu w Scrumie. W kontrze do tego stawiane są inne metody, w których planowanie odbywa się just-in-time. W nich to, w odróżnieniu od Scruma, nie będzie problemu z takim nowym wymaganiem dodanym do Backlogu Produktu w ostatniej chwili – można go pominąć na razie i podjąć do realizacji, gdy tylko uda się o nim porozmawiać i nie trzeba z tym czekać do rozpoczęcia kolejnej iteracji.
Tego typu oceny dowodzą jedynie braku zrozumienia Scruma i funkcji Sprintów w nim. Zakres prac może zmieniać się dowolnie, nie można jedynie zmieniać Celu Sprintu. Inaczej mówiąc powód, dla którego odbywa się Sprint, jest niezmienny (bo jego zmiana podważałaby sens toczącej się iteracji), natomiast sposób osiągnięcia Celu może zmieniać się nieustannie (choćby po to istnieje w Scrumie zdarzenie takie, jak Daily Scrum).
Zespół Scrum może posługiwać się planowaniem działań just-in-time, ale musi dążyć do uzyskania korzyści dla interesariuszy. Sprinty służą temu, by wykonać kolejny krok w rozwoju produktu i podnieść w ten sposób jego wartość, ale jednocześnie by ograniczyć ryzyko pójścia zbyt daleko w złą stronę. Wspomniany „brak elastyczności” w użyciu Backlogu Produktu i regularny interwał planowania rozwoju produktu ma za zadanie zmuszać Zespół (a głównie Product Ownera w nim) do dokonywania wyboru: co warto robić, co zrobione nie będzie.
Cechą tych „bardziej elastycznych” metod jest to, że często pozwalają odsunąć na dalszy plan rozważania o wartości produktu i sensie wytworzenia określonych zmian i skupić się na robieniu tego, co „dobrze zdefiniowane”. Może to być korzystne tam, gdzie Zespół nie musi poszukiwać rozwiązań i zmagać się ze złożonością. W przeciwnym razie potrzeba dużej samodyscypliny Zespołu, by czasami zrezygnować z łatwości działania i skupić się na potrzebach interesariuszy.
Przy okazji: „brak elastyczności” Scruma ułatwia identyfikowanie ograniczeń i dysfunkcji w Zespole oraz jego otoczeniu. Pojawianie się nowych wymagań w Backlogu Produktu w ostatniej chwili i kłopot, jaki to powoduje, jest dobrym przykładem. Być może już za pierwszym razem, gdy tak się stanie, a na pewno w przypadku powtórzenia się problemu, Zespół zacznie zastanawiać się, co jest tego przyczyną i w jaki sposób można ją wyeliminować. To ma szansę zaowocować udoskonaleniem procesu.
Skąd biorą się takie pilne wymagania?
Gdy Zespół Scrum zacznie analizować przyczyny, może okazać się, że Product Owner nie ogarnia swojego produktu i jest zaskakiwany zmieniającymi się potrzebami interesariuszy. Rozmawia z niewłaściwymi osobami, robi to za rzadko, w nieodpowiedniej formie itd.
Może być i tak, że brakuje jasnej wizji produktu – wyjaśnienia, czym ten produkt jest. Efektem jest brak sensownego Celu Produktu, co przekłada się wprost na marną kondycję Backlogu Produktu, który jest przecież ciągle zmiennym planem osiągnięcia wspomnianego Celu.
Ten brak wizji może spowodować również, że rozwój produktu miota się od prawa do lewa, bo w sumie nie wiadomo, co powinno być w produkcie robione, a co absolutnie nie jest jego częścią. W ten sposób często powstają patologiczne rozwiązania, które próbują odpowiadać na bardzo różne potrzeby – zwykle w marny sposób. Ot, taki produkt do wszystkiego, czyli do niczego.
Niewykluczone też, że organizacja nie rozumie, jak działa Scrum i nie wyposażyła ani Product Ownera, ani Zespołu, w niezbędne narzędzia i prawo podejmowania decyzji. W ten sposób być może Product Owner jest zaledwie „operatorem Backlogu”, o którego zawartości i kolejności decyduje tak naprawdę kto inny, marnie komunikujący się z Zespołem i zaskakujący go zmianami w ostatniej chwili.
Powodów może być dziesiątki. A ten najbardziej typowy to…
…kiepsko prowadzona pielęgnacja Backlogu Produktu
Proces pielęgnacji Backlogu Produktu nie powinien zajmować całego czasu, jakim Developerzy dysponują w Sprincie, ale Product Owner może i powinien się temu poświęcić w pełni. Inaczej mówiąc wszystko, co robi Product Owner, w ten czy inny sposób służy pielęgnacji Backlogu.
Nowe wymagania nie biorą się bowiem z jakiegoś niedopowiedzianego Gdziebądzia, tylko są naturalną konsekwencją wcześniejszych zmian w produkcie i sposobu, jak ten produkt jest używany. Potrzeby zmian ujawniają się nieustannie, ale realnie nikt nie spodziewa się, że nastąpią one natychmiast. Interesariusze (użytkownicy produktu, klienci, inwestorzy itd.) mają świadomość, że trzeba będzie chwilę poczekać.
Co więcej, dość rzadko pojawiają się takie potrzeby, które od samego początku są pilne. Jest raczej tak, że stają się one pilne z czasem, w miarę jak interesariusze nie mogą doczekać się adekwatnej zmiany w produkcie.
Jeśli więc w Backlogu Produktu pojawiają się pilne wymagania w ostatnim momencie, to zwykle przyczyną jest prozaiczny fakt, że Product Owner dowiaduje się o nich za późno. W tej sytuacji Scrum Master powinien pomóc całemu swojemu Zespołowi (nie tylko Product Ownerowi, choć pewnie głównie jemu) w udoskonaleniu wyjątkowo marnie działającej pielęgnacji Backlogu.