Czwarty z serii artykułów omawiających wyniki ankiety na temat Scruma dotyczy ostatnich trzech pytań i tym samym kończy krótką serię. Jeśli ktoś nie przeczytał poprzednich tekstów, może zrobić to teraz albo wrócić do nich później (części pierwsza, druga i trzecia).

Nieustannie i bezterminowo dostępna jest też kopia oryginalnej ankiety. Każdy może sprawdzić swą wiedzę, zanim przeczyta artykuły z opisem wszystkich pytań i odpowiedzi.

Pytanie 10

Czy w tym samym momencie mogą powstać dwa różne Przyrosty jednego produktu?

Możliwe odpowiedzi wraz z rozkładem głosów oddanych na nie:

  • Nie – 24.7%
  • Tak, jeśli nad produktem pracuje równocześnie wiele Zespołów Scrum – 42.0%
  • Tak, jeśli development dotyczył różnych obszarów produktu – 33.3%

Poprawna odpowiedź: nie, nie mogą powstać.

Potencjalne pułapki i nieporozumienia

Przyrost to produkt ze zmianami wprowadzonymi do niego przez Developerów, wytworzony zgodnie z obowiązującą Definicją Ukończenia. W Scrumie jest dopuszczalne, by z jednym produktem pracowało jednocześnie nad różnymi zmianami wiele osób, a nawet wiele Zespołów. Jeśli skończą oni swoją pracę w tym samym momencie, to zasadnym wydaje się twierdzenie, że powstaje wtedy więcej niż jeden Przyrost.

Omówienie pytania i prawidłowej odpowiedzi

Przyrost to nowa wersja produktu, spełniająca wymogi jakościowe zawarte w Definicji Ukończenia. Inaczej mówiąc, to produkt po zmianach dokonanych w nim przez Developerów, będący się w stanie pozwalającym na przekazanie go do użycia.

Zróbmy analizę konsekwencji, z jakimi wiązałaby się możliwość wytworzenia dwóch różnych Przyrostów tego samego produktu w jednym czasie. Skoro są one różne, to znaczy, że każdy z nich ma jakieś funkcje i cechy, których brak temu drugiemu. Oba te Przyrosty znajdują się przy tym w stanie, który pozwala na użycie każdego z nich. Na razie wydaje się to mieć sens.

Kontynuujmy jednak analizę konsekwencji i spójrzmy na sytuację z punktu widzenia użytkownika. Gdyby chciał użyć funkcjonalności znajdującej się tylko w jednym z Przyrostów, nie ma problemu – da się to zrobić. Co jednak ma zrobić ów użytkownik, gdyby zechciał skorzystać z możliwości obu Przyrostów naraz? Będzie się przełączał między dwoma produktami? Być może, ale od tego momentu będą to już dwa różne produkty.

Nie ma to zatem sensu, aczkolwiek jestem pewien, że wiele osób wciąż będzie bronić tezy o możliwości powstania dwóch Przyrostów równolegle, o ile tylko będą one zawierać zmiany w „różnych obszarach produktu”. Dobrze więc, zróbmy analizę konsekwencji takiego zdarzenia na przykładzie konkretnego produktu, jakim jest rower.

Jeden Zespół wytworzył na koniec swojego Sprintu nowe wspaniałe siodełko, dzięki któremu jazda na rowerze będzie bardzo wygodna. Drugi Zespół równolegle udoskonalił hamulce. Oba twierdzą, że wytworzyły Przyrosty roweru. No, to zapraszam do przejażdżki na dwóch rowerach naraz, bo tylko w ten sposób można skorzystać z wygodnego siodełka i świetnych hamulców. Obstawiam, że okaże się to trudne…

Co trzeba zrobić? Ano, zamontować siodełko i hamulce w jednym rowerze, a dopiero potem przekazać go użytkownikowi. Czyli trzeba zrobić to, czego jeszcze nie zrobiono – połączyć efekty prac wielu Zespołów w jeden Przyrost, który obejmuje wszystko, co powstało, oraz to, co nie zostało zmodyfikowane ani nie zostało z roweru usunięte, a co znajdowało się w nim wcześniej.

Wiele osób do tego stopnia przyzwyczaiło się do patologicznych sposobów pracy w tzw. skalowanym Agile, że zaciera im się zrozumienie absolutnie podstawowej rzeczy: jeśli produkt jest jeden, niezależnie od tego, że każda z równolegle działających różnych nowych wersji w sumie działa, aby użyć całości zmian, trzeba je najpierw połączyć ze sobą. I dopóki to nie nastąpi, nowej wersji produktu (w Scrumie zwanej Przyrostem) nie ma. Ba, nie wiadomo nawet, czy da się ją wytworzyć, bo czasami próba poskładania w całość zmian zaimplementowanych przez różne Zespoły tak jakoś nie bardzo ma ochotę działać…

Jeśli zatem ktoś jest przekonany, że da się w jego środowisku budować równoległe Przyrosty i nie jest to pochodną jakiejś kreatywnej księgowości, ale faktycznie da się je przekazywać użytkownikom, by z nich korzystali, to znaczy, że w istocie nie jest to jeden produkt, ale dwa – być może mocno ze sobą powiązane.

W każdym innym przypadku Przyrost może powstać dopiero po zintegrowaniu wszystkich zmian wykonywanych równolegle w jedną całość i upewnieniu się, że to, co powstało, spełnia kryteria jakościowe zawarte w Definicji Ukończenia oraz wciąż zawiera wszystko to, co działało w produkcie wcześniej, a czego nikt nie miał intencji zmieniać.

Pytanie 11

Developerzy zmodyfikowali implementację jednej z funkcji produktu i doprowadzili do spełnienia warunków Definicji Ukończenia. Sam sposób działania tej funkcjonalności się nie zmienił. Czy w tej sytuacji powstał nowy Przyrost?

Możliwe odpowiedzi wraz z rozkładem głosów oddanych na nie:

  • Tak – 70.4%
  • Tak, o ile zmiany tej domagali się interesariusze – 16.1%
  • Nie – 13.5%

Poprawna odpowiedź: tak, powstał.

Potencjalne pułapki i nieporozumienia

W definicji Scruma jest stwierdzenie o tym, że w momencie, gdy prace nad elementem Backlogu Produktu skutkują spełnieniem warunków zawartych w Definicji Ukończenia, powstaje nowy Przyrost. Celem każdego Zespołu Scrum i każdego Sprintu, jaki one realizują, jest wykreowanie wartości dla interesariuszy, a nośnikiem jej są właśnie Przyrosty. Za identyfikowanie tego, co przyniesie wartość, odpowiada Product Owner, odzwierciedlając swoją wiedzę i decyzje w Backlogu Produktu. Stąd logiczna konkluzja, że tylko realizacja przynajmniej jednego elementu Backlogu Produktu może skutkować wytworzeniem Przyrostu i zarazem wartości.

Omówienie pytania i prawidłowej odpowiedzi

Backlog Produktu to zapis hipotez, jakie tworzy Product Owner w dyskusji z interesariuszami, ekspertami i swoim Zespołem. Są to hipotezy na temat spodziewanej wartości, którą przyniesie interesariuszom realizacja poszczególnych elementów Backlogu, a także na temat możliwości osiągnięcia w ten sposób wytyczonego Celu Produktu. Żadna z tych hipotez nie jest z definicji poprawna, a każda wymaga sprawdzenia empirycznego – do tego służą w Scrumie Sprinty.

Jedynym sposobem potwierdzenia wartości produktu po wprowadzeniu do niego zmian jest faktyczne użycie go. Dopóki z nowej wersji nikt nie korzysta, wszelkie dywagacje na temat wartości są mniej lub bardziej uzasadnionymi przewidywaniami. Z tego powodu tak krytyczne jest, by nie rzadziej niż raz na Sprint, a jednocześnie przynajmniej raz na miesiąc (stąd maksymalny czas trwania iteracji w Scrumie) uzyskać coś, co nadaje się do użycia. W ten sposób rośnie szansa, że do tego użycia dojdzie i spekulacje zastąpione zostaną empirycznymi danymi (faktami).

Czy dokonanie zmian w produkcie bez zmodyfikowania sposobu jego działania i bez nadania mu nowych cech użytkowych daje interesariuszom jakąkolwiek wartość? Tak, jeśli usunięte w ten sposób zostaje jakieś kluczowe ryzyko, zwiększone zostają możliwości rozwoju produktu, obniżony zostanie całkowity koszt utrzymania produktu, wzrośnie jego jakość strukturalna itd.

Nie wolno przy tym zapominać, że Przyrost to nowa wersja produktu, spełniająca wymogi jakościowe zawarte w Definicji Ukończenia. To nie Przyrost produktu, ale Przyrost potencjalnej wartości tego produktu – stąd taka, a nie inna nazwa. W produkcie nie musi pojawić się nowa funkcja lub cecha, by okazał się on bardziej wartościowy na skutek prac wykonanych przez Developerów.

Hipoteza, że takie zmiany czysto strukturalne lub techniczne przyniosą korzyść interesariuszom, nie musi być poprawna, ale może być słuszna. Jedynym sposobem na jej potwierdzenie jest wykonanie prac niezbędnych do zbudowania nowej wersji produktu spełniającej wymogi Definicji Ukończenia, którą poddać będzie można sprawdzeniu.

Przy czym hipoteza o sensowności i wartości zmian tego rodzaju nie jest w żaden sposób gorsza czy lepsza od hipotez, na podstawie których Product Owner kreuje Backlog Produktu. To oczywiste, że na Backlogu skupi się główny wysiłek Zespołu, ale bynajmniej nie oznacza to, że w produkcie nie wolno dokonać żadnych zmian technologicznych, podnoszących jego jakość (czyli również wartość).

Przykładowo, usunięcie błędu skutkuje powstaniem nowego Przyrostu. Zastąpienie jednej implementacji jakiegoś mechanizmu inną (lepszą) również owocuje nowym Przyrostem. I wcale nie trzeba na siłę dodawać do Backlogu Produktu elementów opisujących taką pracę tylko po to, by następnie je wciągnąć do Sprintu i realizować. Przyrost powstanie również wtedy, gdy o wprowadzeniu zmian w produkcie zdecydują Developerzy już w trakcie Sprintu i zaimplementują je zgodnie z wymogami Definicji Ukończenia.

Utożsamianie powstawania Przyrostów z momentem zakończenia realizacji elementów Backlogu Produktu skutkuje złą organizacją developmentu. Zaczyna on być nastawiony na wytworzenie dokładnie jednego Przyrostu dopiero na zakończenie prac nad danym elementem Backlogu. Nie jest to dobra strategia w złożonym środowisku, w jakim stosuje się Scrum. Rozsądniejsze i bardziej zgodne z ideą empirycznej kontroli procesu jest inkrementalne budowanie rozwiązań dla każdego z realizowanych elementów Backlogu Produktu. W ten sposób, nim powstanie końcowe rozwiązanie, wytworzony zostanie szereg Przyrostów, z których każdy może być potencjalnie użyty.

I na koniec: nawet jeśli zmiany w produkcie wprowadzane są tylko po to, by Developerom łatwiej było go dalej rozwijać, to o ile Zespół nie poświęca na to większości czasu w Sprintach, jest to działanie poprawne w Scrumie i skutkuje powstawaniem Przyrostów. Nie można też zapominać, że sam Zespół jest zawsze jednym z interesariuszy swojego produktu i choćby dlatego od czasu do czasu ma prawo (a wręcz obowiązek) zadbać o swoje potrzeby.

Pytanie 12

Cel Produktu ma być zawarty w Backlogu Produktu. Jak należy to rozumieć?

Możliwe odpowiedzi wraz z rozkładem głosów oddanych na nie:

  • Dosłownie: ma być zapisany jako element Backlogu – 8.4%
  • Dosłownie: ma być widoczny w dowolnej formie – 33.9%
  • Symbolicznie: zawartość i kolejność Backlogu Produktu musi wynikać z Celu Produktu – 57.7%

Poprawna odpowiedź: należy to rozumieć dosłownie, a o formie zapisu decyduje Product Owner.

Potencjalne pułapki i nieporozumienia

Scrum Guide nie opisuje Celu Produktu jako elementu Backlogu Produktu. Określa go jako zobowiązanie będące opisem przyszłego stanu produktu, do uzyskania którego Zespół Scrum zamierza dążyć. Natomiast sama zawartość i kolejność elementów Backlogu Produktu stanowi opis dynamicznie zmiennego planu rozwoju produktu, który ma to umożliwić. Poszczególne elementy na liście są zatem opisami potrzeb interesariuszy, problemów do rozwiązania, oczekiwanych zmian w produkcie itd. Można więc powiedzieć, że obowiązujący Cel Produktu jest odzwierciedlony w zawartości Backlogu.

Omówienie pytania i prawidłowej odpowiedzi

Potraktowanie Celu Produktu jako jednego z elementów Backlogu Produktu rzeczywiście nie ma sensu. Tak rozumiany Cel zostałby automatycznie osiągnięty po zrealizowaniu elementu, który go definiuje. Co więcej, nie miałby żadnego związku z pozostałymi elementami na liście. Inaczej mówiąc, Cel Produktu nie może być elementem Backlogu.

Nie oznacza to jednak, że Cel należy traktować wyłącznie symbolicznie jako wyjaśnienie przyczyn, dla których Product Owner definiuje Backlog w ten czy inny sposób. O ile samo stwierdzenie o konieczność kierowania się Celem Sprintu przy zarządzaniu Backlogiem jest jak najbardziej poprawne, o tyle byłoby to daleko niewystarczające do zapewnienia przejrzystości.

Przyjmijmy, że Cel Produktu jest gdzieś zdefiniowany w takiej formie, że osoby przeglądające Backlog Produktu nie mają go wprost przed oczami. Jakie mogą być tego konsekwencje?

Zrozumienie planu rozwoju produktu (a tym jest Backlog) wymaga znajomości obowiązującego Celu Produktu. Bez tego nie da się ocenić, czy zaproponowana przez Product Ownera lista elementów faktycznie prowadzi do osiągnięcia Celu. Utrudnione lub niemożliwe staje się zidentyfikowanie rzeczy, które są w Backlogu zbędne i nie powinny być robione w tym momencie. Równie marne są szanse, że ktoś odkryje, iż w Backlogu Produktu brak elementów, bez których Celu osiągnąć się nie uda.

Brak widoczności Celu Produktu bardzo ograniczy prawdopodobieństwo, że Product Owner będzie dostawał szybki feedback, pozwalający na wycofanie się z nietrafionych decyzji. I stanie się tak przy optymistycznym założeniu, że osoby nieznające Celu Produktu lub niepamiętające go, powstrzymają się od zgłaszania uwag, najpierw dopytując o sam Cel.

Gorzej będzie, gdy brak świadomości Celu Produktu skłoni ludzi do domyślania się, co nim jest. Lub gdy niepamięć spowoduje, że będą przekonani, iż Cel jest inny niż faktycznie obowiązujący. Posypie się lawina uwag i komentarzy, sugestii i oczekiwań, które będą pchać Product Ownera w złą stronę, a nawet jeśli będzie w stanie stawić temu odpór, zabiorą mu mnóstwo czasu na dyskusje. Będą one przy tym doskonałą okazją do popsucia relacji i wygenerowania konfliktów.

Jeśli Cel Produktu w jakiejś wybranej przez Product Ownera formie jest widoczny od razu wraz z Backlogiem, nie ma potrzeby niczego się domyślać ani liczyć na sprawną pamięć. Dzięki temu przejrzystość Backlogu Produktu nie jest ograniczona.

Stała widoczność Celu Produktu w Backlogu ogranicza też ryzyko potraktowania tego artefaktu jako listy rzeczy do zrobienia albo wręcz miejsca, w którym umieszczane są zlecenia do wykonania przez Developerów. Im mniej widoczny jest powód, dla którego lista elementów zawiera takie, a nie inne elementy w określonej kolejności, tym łatwiej dodawać do niej rzeczy po to, by o nich nie zapomnieć, pomysły na przyszłość, które być może kiedyś warto zrealizować itd. Backlog przestaje wtedy być planem rozwoju produktu, a staje się skrzynką podawczą dla interesariuszy, o ile nie śmietnikiem.

Jest jeszcze jeden powód, dla którego w Backlogu Produktu musi być wprost widoczny Cel Produktu, a jest nim potrzeba efektywnego monitorowania postępu prac nad nim. Jeśli taki postęp faktycznie następuje, to Sprint po Sprincie ubywać powinno elementów, które wprost związane są z Celem Produktu. A gdy w Backlogu pozostają już tylko te rzeczy, które trzeba zrobić z różnych powodów niepowiązanych z Celem Produktu, to dobry moment, by ustanowić nowy Cel. Zrobi to Product Owner, a następnie przebuduje listę elementów tak, by powstała pierwsza wersja planu jego osiągnięcia.

Oczywiście w miarę prac nad Celem Produktu niemal zawsze pojawiają się nowe rzeczy, o których potrzebie realizacji Product Owner wcześniej nie wiedział, ale od pewnego momentu Backlog Produktu musi zacząć się skracać, jeśli jakikolwiek progres następuje. Z drugiej strony nieustanne rozrastanie się Backlogu może być sygnałem konieczności zrewidowania obowiązującego Celu Produktu, a mówiąc wprost, ponownej oceny jego sensowności.

Jeśli Cel Produktu funkcjonuje gdzieś w oderwaniu od samego Backlogu jako „kontekst, o którym trzeba pamiętać”, miarą postępu prac może stać się velocity albo liczba elementów realizowanych co Sprint (czyli przepustowość) – a wysoka wartość tych miar nie świadczy automatycznie o podążaniu w dobrą stronę. Wspomniany „kontekst”, jeśli nie jest nieustannie widoczny, bywa zapominany, a na pewno przestaje wydawać się kluczowy. Stąd już tylko krok do realizowania listy elementów „jak leci” bez dociekania, czy faktycznie wszystkie są wartościowe i czy rzeczywiście teraz jest właściwy moment, by się nimi zajmować.

Koniec?

Omówiłem wszystkie pytania z ankiety, zapewne generując przy okazji wątpliwości lub oburzenie u wielu osób. Ta ostatnia emocja jest często o tyle nieuzasadniona, że wynika ze zbyt dosłownego traktowania zapisów w definicji Scruma (a precyzyjniej mówiąc, skupiania się na pojedynczych zdaniach, bez uwzględniania w ich interpretacji całości dokumentu). A czasami powodem jest przyzwyczajenie do czegoś, co działa w sposób niekoniecznie spójny z definicją metody, choć mimo to nazywane jest Scrumem… Lub po prostu z braku świadomości, że sam Scrum się zmienił.

Jednym z oskarżeń, z jakimi się zetknąłem przy okazji tej ankiety, ale i w wielu innych przypadkach, jest zarzut, że traktuję Scrum Guide niczym święte pismo. Z drugiej strony nie brak kąśliwych uwag, że jest to dokument napisany właśnie tak, by „kapłani” dokonywali wykładni dla maluczkich (wiadomo, że za pieniądze).

Jest to zabawne i denerwujące zarazem. Tak, Scrum nie jest gotową receptą i nie da się go użyć bez zrozumienia zasad. Tak, nie są one wyłożone w łopatologiczny sposób. Tak, trzeba wyciągać wnioski, bo to, co należy zrobić, co robić można, a czego absolutnie robić nie warto, nie wynika ze zdefiniowanych wprost nakazów czy zakazów. Tak, to trudne i nie udaje się wielu Zespołom, zwłaszcza tym wyzutym z chęci zrobienia czegoś sensownego lub niemającym niczego sensownego do zrobienia. Nie czyni to jednak Scruma metodą teoretyczną, marną, źle zdefiniowaną, religią itd. To narzędzie, które zadziała każdemu, kto zechce użyć go świadomie do osiągnięcia rozsądnych celów. Tylko tyle i aż tyle.

Na temat kondycji Scruma napiszę kilka słów już niedługo, bo aż prosi się o komentarz to, co można zaobserwować w przestrzeni publicznej.