W połowie maja 2024 udostępniłem anonimową ankietę z dwunastoma pytaniami dotyczącymi Scruma i zaprosiłem wszystkich zainteresowanych do sprawdzenia swojej wiedzy.
Jeśli ktoś nie miał okazji spróbować swych sił, wciąż można to zrobić przed dalszą lekturą artykułu, korzystając z kopii ankiety, która będzie dostępna bezterminowo.
W ciągu dwudziestu dni, w których czasie oryginalna ankieta była aktywna, wzięło w niej udział 231 osób, uzyskując średnio 6.4 punktu na 12 możliwych. Tylko pięć osób odpowiedziało prawidłowo na wszystkie pytania, choć niewykluczone, że ktoś postanowił wypełnić ankietę więcej niż raz.
Poniższy wykres przedstawia rozkład liczby wypełnionych ankiet w zależności od uzyskanego wyniku punktowego. Nie jest to widok budujący, jeśli wziąć pod uwagę, że pytania, na które odpowiadali uczestnicy badania, dotyczą kwestii podstawowych w Scrumie, a znajomość metody deklaruje cała rzesza ludzi.
Niektóre pytania okazały się prostsze, inne zdecydowanie bardziej problematyczne. Co więcej, już od pierwszego dnia pojawiać się zaczęły komentarze, niektóre bardzo złośliwe, wskazujące na merytoryczne błędy, jakie rzekomo zawierać ma ankieta. Trochę się tego spodziewałem, a mimo to zaskoczył mnie poziom emocji, jakie udało mi się wygenerować.
Zgodnie z obietnicą omawiam wyniki ankiety i wyjaśniam, dlaczego takie, a nie inne odpowiedzi były w niej poprawne. Może to nieco ostudzi rozgrzane głowy… a może tylko jeszcze bardziej je rozpali. Zobaczymy. Dla wygody czytelników, całość omówienia podzieliłem na części, tworząc z nich kolejny niewielki cykl.
Pytanie 1
Czy Developerzy w trakcie Planowania Sprintu mogą nie trzymać się kolejności elementów Backlogu Produktu?
Możliwe odpowiedzi wraz z rozkładem głosów oddanych na nie:
- Tak – 83.5%
- Nie – 16.5%
Poprawna odpowiedź: tak, mogą.
Potencjalne pułapki i nieporozumienia
Product Owner porządkuje Backlog Produktu wedle oczekiwanej kolejności realizacji elementów w nim zawartych. Jest zarazem jedyną osobą w Scrumie, która decyduje o tym, jakie zmiany wprowadzone zostaną do produktu. Stąd dość częste przekonanie, że kolejność, jaką Product Owner ustalił, musi bezwzględnie być przestrzegana w każdej sytuacji.
Omówienie pytania i prawidłowej odpowiedzi
Backlog Produktu jest wizualizacją planu osiągnięcia aktualnie obowiązującego Celu Produktu i właśnie dlatego elementy uporządkowane są zgodnie z oczekiwaną przez Product Ownera kolejności ich realizacji, a sam Backlog ma formę uporządkowanej listy, a nie np. luźnego zbioru rzeczy do zrobienia lub jakiejś ich macierzy.
Górna część Backlogu Produktu (początek listy) to w istocie zaproponowany przez Product Ownera plan osiągnięcia jakiegoś prototypowego Celu Sprintu na nadchodzącą iterację.
Samo Planowanie Sprintu nie polega na zgarnięciu z początku listy tylu elementów Backlogu, ile Developerzy uznają za możliwe do zrealizowania. Zespół Scrum wspólnie ustala Cel Sprintu, a następnie szuka sposobu jego osiągnięcia, decydując o tym, co i w jakiej kolejności będzie robione.
Przy czym Zespół nie ma obowiązku przyjąć zaproponowanego przez Product Ownera prototypu Celu Sprintu. Może być nieosiągalny, może pojawić się pomysł o wiele lepszy i korzystniejszy dla interesariuszy. Nierzadko Planowanie wymaga iteracyjnego podejścia, czyli rozważenia szeregu kolejnych propozycji Celu, nim ostatecznie powstanie Backlog Sprintu.
Na Backlog ten składają się Cel Sprintu oraz prognoza tego, co i jak trzeba zmienić w produkcie, by go osiągnąć. Podstawę prognozy stanowi zwykle zbiór elementów Backlogu Produktu podjętych do realizacji w Sprincie, przy czym niekoniecznie wybierane są one w kolejności, w jakiej znajdowały się na liście. Kryterium doboru jest ustalony Cel Sprintu i pomijanie elementów, które są zbędne do jego osiągnięcia, jest w pełni uzasadnione. Zdarza się też, że opis zmiany w produkcie, która nie była wcześniej przewidywana, jest dodawany wprost do Backlogu Sprintu, jeśli Zespół odkryje, że bez niej Celu Sprintu nie osiągnie.
Product Owner mógłby żonglować Backlogiem Produktu na bieżąco, dostosowując go do przebiegu dyskusji, ale byłaby to strata czasu. Powinien skupić się na dyskusji o Celu Sprintu, dążąc do uzyskania maksymalnej wartości dla interesariuszy. Ma prawo domagać się realizowania elementów w kolejności, jaką ustalił, ale nie może upierać się przy niej w sposób bezmyślny. Poza tym ostatecznie kolejność realizacji i tak wynikać będzie po prostu z Celu Sprintu.
Pytanie 2
Czy Zespół Scrum może pracować nad dwoma produktami naraz w jednej iteracji?
Możliwe odpowiedzi wraz z rozkładem głosów oddanych na nie:
- Tak – 56.3%
- Nie – 43.7%
Poprawna odpowiedź: nie, nie może.
Potencjalne pułapki i nieporozumienia
Wiele produktów stanowi zlepek różnych rozwiązań, które mogą być wytwarzane niezależnie od siebie. Nierzadko te części składowe same stanowią niewielkie produkty, z których składana jest większa całość.
Istnieją metody skalowania dzielące produkt na obszary opisane osobnymi Backlogami. Zespół realizujący prace dotyczące wielu takich obszarów naraz, w oczywisty sposób będzie realizował elementy z więcej niż jednego Backlogu.
A skoro w definicji Scruma brak zakazu pracy z wieloma produktami jednocześnie, logika podpowiada, że jest to działanie poprawne.
Omówienie pytania i prawidłowej odpowiedzi
Żeby pracować w Sprincie nad dwoma produktami naraz, Zespół musiałby podejmować do realizacji elementy z dwóch różnych Backlogów Produktu (nie obszaru produktu, ale całego produktu). Planowanie Sprintu odbywałoby się nieuchronnie w kontekście dwóch różnych Celów Produktu oraz dwóch Definicji Ukończenia i skutkować musiałoby ustaleniem dwóch różnych Celów Sprintu, a tym samym powstaniem dwóch równoległych Backlogów Sprintu. W praktyce oznacza to podział Zespołu na dwie części, z których każda niezależnie od drugiej próbuje realizować Sprint na rzecz innego produktu.
Alternatywnie konieczne byłoby stworzenie jednego Backlogu Produktu dla dwóch produktów i ustanowienie jakiegoś jednego pseudo-Celu, z którego potem wynikałby równie sztuczny jeden Cel Sprintu. Gdyby natomiast ustanowione zostały dwa Cele Produktu w ramach jednego Backlogu, to w zależności od tego, który z nich brany byłby pod uwagę, zawartość i kolejność elementów na liście powinna być różna.
Nie byłoby też możliwe stworzenie Przyrostu, który łączyłby w sobie całość prac wykonanych przez Developerów. Wszak mowa o różnych produktach, więc to trochę tak, jakby pracując jednocześnie nad betoniarką i latawcem spodziewać się, że powstanie jedno urządzenie łączące funkcjonalności obu tych rzeczy.
Ciężko też ustalić sensowną formułę Przeglądu Sprintu, skoro istnieją dwie grupy interesariuszy, których łączy być może tylko to, że pracują na ich rzecz ci sami Developerzy.
Pytanie 3
Czy może powstać Przyrost mimo niespełnienia formalnych warunków zapisanych w Definicji Ukończenia?
Możliwe odpowiedzi wraz z rozkładem głosów oddanych na nie:
- Tak – 43.7%
- Nie – 56.3%
Poprawna odpowiedź: tak, może powstać.
Potencjalne pułapki i nieporozumienia
Definicja Ukończenia określa formalny stan produktu, który nadaje się do użycia. Kojarzona jest z listą praktyk, działań i czynności, jakie wykonać muszą Developerzy, by spełnić wspomniany wymóg formalny. Nierzadko bywa stosowana dosłownie jako lista kontrolna do sprawdzenia, czy można uznać, iż powstał Przyrost.
W literaturze, na szkoleniach i w samej definicji Scruma nieustannie podkreśla się, jak ważne dla działania empirycznej kontroli procesu jest faktyczne ukończenie prac nad produktem w Sprincie. Twierdzenie, że „Przyrost może powstać bez spełnienia wymogów formalnych Definicji Ukończenia” musi więc być herezją…
Omówienie pytania i prawidłowej odpowiedzi
Definicja Ukończenia jest zapisem kryteriów jakościowych, którymi przy budowaniu produktu ma intencję kierować się Zespół Scrum. Zwykle Definicja ta ma formę wymogów odnośnie do tego, jakimi narzędziami i praktykami Developerzy będą się posługiwać. Nie jest to jednak forma obowiązkowa.
Scrum Guide jasno określa, że Definicja Ukończenia jest formalnym opisem stanu Przyrostu, który spełnia kryteria jakościowe, a nie formalną listą czynności, praktyk i narzędzi, jakimi mają posłużyć się Developerzy.
Każda reguła zawarta w Definicji musi wynikać z dążenia Zespołu do uzyskania określonego minimalnego poziomu jakości lub jego przekroczenia, ale Developerzy nie mogą po spisaniu Definicji zapominać, co miały zapewnić poszczególne zapisy, czyli dlaczego do Definicji zostały dodane.
Czy jest możliwe, że warunki zawarte w Definicji formalnie są spełnione, a mimo to Developerzy dojdą do wniosku, że jakość produktu jest za niska i nie powstał Przyrost? Tak, liczy się bowiem stan faktyczny, a nie formalny.
A czy możliwe jest, że w sposób, którego nie przewiduje Definicja Ukończenia, Developerzy wytworzą produkt o jakości zgodnej z oczekiwaniami lub nawet wyższej? Tak i może to wynikać z użycia nowych praktyk i narzędzi albo z konieczności wykonania nietypowych prac, których w standardowy sposób ukończyć się nie da. Dopóki stan produktu tak zbudowanego jest przejrzysty dla całego Zespołu i interesariuszy, dopóty nie ma podstaw do twierdzenia, że Przyrost nie powstał.
W pierwszym przypadku konieczne jest udoskonalenie dziurawej Definicji Ukończenia. W drugim być może również trzeba ją rozbudować, dopuszczając użycie kolejnych praktyk. Pamiętać jednak trzeba, że dodawanie zapisów do Definicji tylko po to, żeby przewidywała ona każdą ewentualność, może nie być dobrą strategią, podobnie jak próba robienia tego od razu, zamiast np. dopiero na Retrospekcji Sprintu, gdy Zespół ma czas na spokojną dyskusję.
Dlatego spotkać można Zespoły, które zamiast litanii praktyk, narzędzi i czynności, zapisują jawnie kryteria jakościowe w Definicji Ukończenia. Obowiązkiem Developerów jest potem poszukanie skutecznego sposobu na ich zaspokojenie. Wymaga to sporej dojrzałości i raczej nie sprawdzi się w Zespołach o niskim morale (w których wartości Scrum jest jak na lekarstwo), ale moim zdaniem taka forma Definicji jest najbardziej scrumowa…
Ciąg dalszy
Kolejne pytania z ankiety omówione zostały w drugiej części cyklu.