Jak wiadomo w transformacjach Agile jest tak, że wszystkie organizacje i zespoły są wyjątkowe. Jednak jeśli wiele Zespołów Scrumowych zgłasza się z tymi samymi problemami i te same pytania pojawiają się na szkoleniach to mamy jakiś wzorzec. Tak powstał pomysł na cykl o chorobach, które osłabiają Zespoły Scrum. Będę opisywał objawy, przyczyny i leczenie. Oczywiście, przyczyn może być więcej niż przedstawione, ale te, o których piszę pojawiły się w mojej praktyce. Na leczenie może też być więcej pomysłów, więc nie ograniczajcie się do moich. Jeśli znasz inne choroby lub masz nowe pomysły na objawy czy leczenie, zostaw komentarz. W tej chwili mam pomysł na trzy, ale może się zrobić więcej.

Wrzódki

Objawy wrzódek w Sprincie

Zespól Developerski pracuje spokojnie w bieżącym Sprincie, a tu nagle niespodzianka, trzeba rzucić pracę i robić coś innego. Wrzódki to nieplanowana praca, która nagle wpada do Sprintu. Przykładami takich wrzódek mogą być krytyczne błędy na produkcji, czy inne ważne zmiany, które dostają większy priorytet u Product Ownera niż praca w bieżącym Sprincie. Mogą pojawić się też niezwykle ważne elementy Rejestru Produktu, które muszą zostać zrobione pomimo zaplanowania Sprintu. I tutaj sytuacja jest nieczysta, bo przecież obiecaliśmy biznesowi możliwość zmian a z drugiej strony Zespół Developerski potrzebuje stabilnego zakresu Sprintu. Co ważniejsze, ponieważ Developement Team powinien współpracować z Product Ownerem nad osiągnięciem największej wartości, takie sytuacje mogą mieć miejsce.

Skutki wrzódek w Scrincie

Efekt wrzódki jest taki, że plan Sprintu rozpada się w drobne kawałki i nie możemy wszystkiego dostarczyć, a nawet w najgorszym wypadku nie udaje się osiągnąć celu Sprintu. Czy wpływ wrzódek na Velocity będzie prosty i liniowy? Na pewno nie. Należy zdać sobie sprawę, że mamy tutaj wpływ na ludzi, którym zakłócamy rytm pracy i obniżamy motywację.

Przyczyny wrzódek

Poza szukaniaem przyczyn, dobrą praktyką jest zbieranie danych na temat wrzódek i ich wpływu na Velocity, żeby sytuacja była transparentna dla Produt Ownera i interesariuszy. Warto zastanowić się nad skróceniem długości Sprintu (jeśli już nie macie tygodniowego), żeby zwiększyć tym samym okazję do zmian priorytetów między Sprintami a nie w samych Sprintach. Często wydaje się, że tak powinno być i nic nie da się z tym zrobić. Scrum Master powinien kwestionować jawne przyczyny całej sytuacji i szukać tych niejawnych.

Leczenie wrzódek w Zespole Scrum

Oczywiście można zareagować na wrzódkę w ten sposób, że renegocjujemy zakres Sprintu. I tak powinniśmy postąpić jeśli jest to wcześniej oszacowany element Product Backlog, lub coś co możemy  spokojnie oszacować. Szacujemy wrzódkę i wyciągamy ze Sprintu tyle na ile oszacowaliśmy wrzódkę. Proste prawda? Problem w tym, że zwykle trudno jest oszacować wrzódkę i nigdy nie ma pewności, że nie pojawią się kolejne. Zazwyczaj dochodzenie (ang. investigation) jest na tyle wymagające i długotrwałe, że wykonanie pracy to już naprawdę formalność i chwila pracy. Dlatego nie opłaca się badać przyczyn, tylko po to, żeby oszacować.

W takim wypadku można po prostu oszacować pracę po jej wykonaniu. Można też nie szacować w ogóle. Jaka będzie różnica? Jeżeli oszacujemy nieznane wcześniej wrzódki, to tak naprawdę dodamy do Product Backlog na chwilę pewną ilość, żeby ją wyjąć i dodać do Veloctiy. W ten sposób Velocity Zespołu Developerskiego będzie na normalnym poziomie pomimo wrzódki. Jeśli nie zrobimy takiego manewru, to Velocity będzie niższe. Co za różnica jeśli de facto spalanie Product Backlogu będzie taka samo? Zwiększanie Veloctiy przez szacowanie wrzódek ma sens tylko jeśli Zespół Developerski jest oceniany ze względu na poziom Velocity.

PS. Termin wrzódka w tej pisowni jest terminem zasłyszanym (zapatrzanym?). Prawdopodobnie pierwszy raz go usłyszałem prowadząc szkolenie z Andy Brandt.

Inne choroby Zespołu Scrum

Choroby trawiące zespoły Scrum #2 — Bieżączka
Choroby trawiące zespoły Scrum #3 — Późna cofka
Choroby trawiące zespoły Scrum #4 — Spady