Raz jeszcze wracam do omówienia ankiety na temat Scruma, pochylając się nad trzema kolejnymi pytaniami i odpowiedziami na nie. Jeśli ktoś nie czytał poprzednich artykułów z tej krótkiej serii, warto to nadrobić (część pierwsza i część druga).

Jeśli ktoś chce sprawdzić swą wiedzę, może przed dalszą lekturą wypełnić ankietę, która będzie dostępna bezterminowo i stanowi kopię oryginalnego testu.

Pytanie 7

Czy Product Owner pracuje wraz z Developerami nad osiągnięciem Celu Sprintu?

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

  • Tak – 83.9%
  • Nie – 16.1%

Poprawna odpowiedź: tak, pracuje.

Potencjalne pułapki i nieporozumienia

Osiągnięcie Celu Sprintu wymaga wytworzenia przynajmniej jednego Przyrostu, czyli pracy wykonywanej przez Developerów. Product Owner, o ile nie jest równocześnie Deweloperem, nie bierze udziału w developmencie, a zatem w przekonaniu wielu osób nie pracuje nad osiągnięciem Celu Sprintu.

Omówienie pytania i prawidłowej odpowiedzi

Product Owner nie jest klientem Developerów, który zleca realizację zmian w produkcie i znika, aby pojawić się na koniec Sprintu i dokonać odbioru tego, co udało się wytworzyć. Jest w Scrumie odpowiedzialny za uzyskanie dla interesariuszy maksimum wartości, jaką da się wygenerować bez poświęcania jakości, więc jego praca – wbrew przekonaniu wielu osób – nie kończy się na zarządzaniu Backlogiem Produktu.

Osiągnięcie Celu Sprintu nie sprowadza się do wytworzenia takiego czy innego Przyrostu i nie wystarczy do tego sam development. Konieczne jest podejmowanie decyzji odnośnie do tego, co robić, czego nie robić, co będzie właściwym rozwiązaniem, a co sprawi użytkownikom kłopoty itd. Zespół często odkrywa, że nie zaplanował zrobienia czegoś, co jest niezbędne, aby Cel był osiągalny. Albo szuka sposobu na ograniczenie ilości pracy, bo pojawił się jakiś problem i czasu pozostałego w Sprincie zaczyna dramatycznie brakować. Developerzy, pozostawieni sami sobie, musieliby nieuchronnie podejmować decyzje, które przynależą do obszaru odpowiedzialności Product Ownera.

Jednym z powodów, dla których usunięty został ze Scruma istniejący w nim przez lata Zespół Developerski, było właśnie wyeliminowanie nieporozumień, jakoby w Sprincie pracowali tylko Developerzy (w swoim Zespole), a Product Owner i Scrum Master, lewitując w międzyczasie gdzieś wokół, pojawiają się punktowo to tu, to tam. W Sprincie bierze udział cały Zespół, bo wspólnie ustala Cel Sprintu i potem ma do niego wspólnie dążyć – wykonując prace wynikające z odpowiedzialności, jakie na siebie wzięły poszczególnego osoby.

Bardzo łatwo rozpoznać Zespołu Scrum, w których Product Owner nie pracuje nad osiągnięciem Celu Sprintu. Wystarczy zobaczyć, jak zachowuje się w trakcie Przeglądu Sprintu. Jeśli pojawia się tam po to, by wespół z interesariuszami rozliczać Developerów z ich pracy albo wręcz dopiero wtedy dowiaduje się, co udało się wytworzyć, jest bardziej interesariuszem niż Product Ownerem. Jeśli natomiast to on informuje, co wraz z Zespołem zdołał wypracować i bierze odpowiedzialność za to, z czym przychodzi do interesariuszy, to znaczy, że pracował w Sprincie z Zespołem w takim stopniu, w jakim powinien i czas mu pozwolił.

Pytanie 8

Kto odpowiada za dostarczenie wartości interesariuszom?

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

  • Product Owner – 6.5%
  • Scrum Master – 0.0%
  • Developerzy – 3.0%
  • Cały Zespół Scrum – 90.5%

Poprawna odpowiedź: odpowiada za to cały Zespół Scrum.

Potencjalne pułapki i nieporozumienia

Nośnikiem wartości w Scrumie jest Przyrost, czyli nowa wersja produktu ze zmianami, jakich dokonali w nim Developerzy. Ponieważ tylko Developerzy budują Przyrost, wydaje się logiczne, że to oni dostarczają wartość interesariuszom i za to odpowiadają.

Omówienie pytania i prawidłowej odpowiedzi

Ci, którzy w Scrumie bezpośrednio pracują nad zbudowaniem kolejnych Przyrostów, czyli Developerzy, faktycznie wartość dla interesariuszy kreują. Natomiast za to, by mogli to robić to skutecznie, odpowiada cały Zespół.

Każdy dzień w Sprincie przynosi coś nowego, co może wymagać podjęcia decyzji, które istotnie wpłyną na wartość produktu, jaki powstanie. Decyzje te mogą być związane z samym produktem (wtedy podejmuje je Product Owner), sposobem jego budowania (to domena Developerów), albo procesem, którym posługuje się Zespół (tu być może zdecydować o czymś musi Scrum Master).

Poza tym odpowiedzialność Product Ownera za dostarczenie maksymalnej wartości interesariuszom nie ogranicza się do sprawdzania, czy aby na pewno Developerzy realizują elementy Backlogu Produktu zgodnie z ustaleniami. Konieczne jest sprawdzenie, czy faktycznie powstaje wartościowy produkt. Jeśli wymaga to odejścia od ustaleń, to Developerzy nie tylko mogą, ale wręcz powinni to zrobić, a Product Owner ma ich w tej decyzji wspierać.

Scrum Master też ma wpływ na to, czy i jak wiele wartości wykreować uda się w trakcie Sprintu. Brak efektywności wpływa negatywnie na skuteczność Zespołu, a spadek przejrzystości wiedzie zwykle do błędów decyzyjnych. Czasami na możliwości i sposób pracy Developerów i Product Ownera negatywnie wpływa otoczenie, a innym razem to samo otoczenie może w znacznym stopniu pomóc. Scrum Master musi aktywnie pomagać w stworzeniu środowiska, w którym efektywność i skuteczność Zespołu jest maksymalna.

Pytanie 9

Czy Daily Scrum może odbywać się więcej niż raz dziennie?

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

  • Tak – 45.9%
  • Nie, bo nazywałby się wtedy inaczej – 54.1%

Poprawna odpowiedź: tak, może się odbywać częściej.

Potencjalne pułapki i nieporozumienia

Nazwa zdarzenia, czyli Daily Scrum, wydaje się rozstrzygać wątpliwości bez konieczności głębszej refleksji. Po cóż zresztą ktokolwiek miałby się spotykać częściej, skoro wiele Zespołów narzeka, że i tak ma za dużo spotkań, a Daily Scrum odbywający się raz dziennie też wydaje się im nadmiarowy…

Omówienie pytania i prawidłowej odpowiedzi

Scrum Guide definiuje wyłącznie minimalny zestaw elementów i reguł ich stosowania, na podstawie których Zespół może stworzyć (o ile naprawdę tego chce) sprawnie działający proces wykorzystujący empiryzm w praktyce. Z tego powodu koniecznie staje się uzupełnienie Scruma różnymi praktykami i technikami, bo sama metoda ich nie definiuje ani nawet nie podpowiada.

Kluczową kwestią w Scrumie jest zapewnienie możliwości empirycznego kontrolowania procesu. W tym celu framework definiuje artefakty, które są podmiotem inspekcji (stanu produktu, planów dalszego jego rozwoju, postępu prac w Sprincie) oraz zdarzeń, w ramach których to sprawdzenie się odbywa regularnie, dostatecznie często i we właściwych momentach.

Daily Scrum nie może się odbywać co drugi dzień lub raz na dwa tygodnie, bo sytuacja w Sprincie jest na tyle zmienna, że codzienna synchronizacja i ewentualne dostosowanie planów działania przez Developerów jest niezbędne dla zapewnienia możliwości osiągnięcia Celu Sprintu. Przy czym celem synchronizacji nie jest wymiana wiedzy o tym, co się dzieje (bo to Developerzy zwykle robią na bieżąco), ale ustalenie wspólnych wniosków, które z tej wiedzy płyną. Wnioski te są podstawą do planowania dalszych działań, w tym ewentualnej zmiany planów (czyli Backlogu Sprintu).

Jeśli poziom niestabilności i nieprzewidywalności środowiska, w jakim funkcjonuje Zespół, jest tak duży, że organizacja Daily Scrumów raz dziennie nie wystarcza do utrzymania empirycznej kontroli nad przebiegiem prac developerskich, spotkanie musi odbywać się częściej.

Nazwa Daily Scrum przypomina o minimalnej częstotliwości, z jaką realizowane jest to zdarzenie. Byłoby skrajną głupotą trzymać się jej w sytuacji, gdy okaże się za mała tylko ze względu na nazwę spotkania. Poza tym nikt nie zabrania realizować Sprintów, które trwają nie tydzień lub dwa, ale raptem jeden dzień. Czy wtedy Daily Scrumy nie będą się w ogóle odbywać? Jasne, że będą, np. co godzinę lub dwie, a może i częściej.

Ciąg dalszy

Ostatnie trzy pytania z ankiety omówione zostały w artykule, który kończy cykl.