Zaplanowane? Ba! O panie, i to jak zaplanowane

Zaplanowane? Ba! O panie, i to jak zaplanowane

1 1 Andrzej Zińczuk

Powodem do napisania tego posta jest kilka sytuacji z jakimi ostatnio się spotkałem – realizacji zdarzenia Daily Scrum.

Inspekcja i adaptacja

Jak każde zdarzenie w Scrum również i Daily Scrum służy inspekcji i adaptacji. Na wejściu (inspekcja) jest Sprint Backlog (zakres Sprintu + plan jego realizacji), informacje o tym co członkowie Dev Team zrobili od ostatniego Daily Scrum oraz zagrożenia na drodze do celu Sprintu. Na wyjściu (adaptacja) jest zaktualizowany Sprint Backlog, w szczególności plan prac do następnego Daily Scrum.

Co to tak naprawdę oznacza?

Oznacza to tyle, że każdy Daily Scrum to okazja do tego by zaktualizować plan na drodze do realizacji Celu Sprintu. Na bazie posiadanej wiedzy o postępach i problemach, zaplanować kolejny dzień prac – najefektywniej jak potrafimy, tak by zwiększyć szanse na osiągnięcie końcowego celu. Jednym słowem plan na dziś (bo złożoność, coś może wyskoczyć itp.) ale cały czas z myśleniem o szerszej perspektywie.

Wyzwania

(Opisuję tylko część z tych, które najczęściej obserwuję – cdn.)

a) Plan? Jaki plan? Robotę trzeba robić!

Po czym poznać?

  • planowanie Sprintu kończy się szybkim określeniem zakresu Product Backlogu jaki Dev Team sądzi, że zrealizuje
  • plan zespołu na Sprint można skwitować mniej więcej tak: przecież każdy wie co mamy zrobić!
  • zaraz po planowaniu musimy się spotkać, żeby zaplanować kolejny dzień:)
  • Daily Scrum przypomina sytuację: a co by tu dzisiaj ugotować na obiad?

b) Walczyłem, walczę i będę walczył dzisiaj

„…I was developing, I’m developing and I will be developing…”

Po czym poznać?

  • Daily Scrum to w zasadzie opowiadanie o tym czym się zajmuję i jak bardzo jestem zajęty
  • opowiadam o wszystkim co robiłem od ostatniego Daily: obiad, pogadałem, na refinemencie byłem, czytałem dokumentację
  • mój plan to albo kontynuacja bycia zajętym albo nie mam pomysłu co zrobić
  • dużo “mówione” i małe zrobione (zamknięte/skończone/oddane)
  • brak poczucia co tak naprawdę zostało zrobione
  • nie jest jasne (ni cholery nie wiadomo:))  co zostało do zrobienia by skończyć

c) Ja wiem co będę robił

Po czym poznać?

  • członkowie zespołu opowiedzieli o tym co zrobili, że nie mają problemów i co będą robić – ale brzmi to jak indywidualna perspektywa niepowiązana współpracą
  • mam “swoje” zadanie i nie widzę szerszego horyzontu
  • wracamy do tematów już omówionych przez innych członków zespołu

d) Po co nam Sprint Backlog, przecież wszystko mamy w głowie

Po czym poznać?

  • Dev Team uznaje, że “skoro każdy przecież wie czym się zajmuje” to wizualizacja jest zbędna
  • Sprint Backlog (“używamy JIRY”) służy głównie do wpisywania komentarzy i trackowania spędzonego czasu a nie współpracy
  • pytanie o element ze Sprint Backlogu “przewraca” poprzednie ustalenia albo wprowadza konsternację w stylu “to my to mamy w backlogu?”
  • tablica, burndown charty, diagramy cumulative flow diagram, tagi blockerów itp. to czary mary i coco jambo Scrum Mastera – a my tu robimy poważną robotę.

I ich konsekwencje

  • DevTeam nie zadaje sobie pytania o stan zagrożenia realizacji Celu Sprintu
  • często do ostatniego dnia Sprintu nie wie co zrealizuje w ramach Przyrostu
  • gdy pojawi się “wybuch” złożoności w końcowej części Sprintu duża część elementów Sprint Backlogu spada na kolejne Sprinty
  • Product Owner zaskakiwany jest stopniem realizacji na koniec Sprintu – w konsekwencji ciężko planować przyszłość prac nad produktem

Co można zrobić by ich uniknąć?

  • zakończyć Sprint Planning – uwaga! z planem. Możecie, np. spróbować popatrzeć od końca Sprintu (co kiedy musimy mieć zrobione), możecie stworzyć coś co przypomina diagram gantt’a, narysować w osi czasu, dostępnych dni/ osób itp. Z czasem wypracujecie swoją efektywną metodę. Ważne by kończyć Sprint Planning ze świadomością co będziemy robić na początku Sprintu (może kilka pierwszych dni?)
  • popracować nad wielkością elementów. Im większy PBI tym większa złożoność, więcej rzeczy może wybuchnąć. Im mniejsze elementy tym łatwiej kontrolować ich postęp i ryzyka.
  • spróbujcie przeprowadzić Daily Scrum od strony celu – tj. jak to co zrobiliśmy wpływa na realizację celu. Co możemy zrobić dziś by jak najszybciej ku niemu się zbliżyć? Jak podzielić się pracą by zmniejszyć ryzyko niepowodzenia jego realizacji? Może to przyjąć postać omawiania postępów prac według uporządkowania (tak jak wskazał to PO). Pomocną praktyką może się okazać omawianie elementów od końca – co jeszcze musimy zrobić by “zamknąć” te story – skończone znaczy bezpieczne.
  • zamiast mówić o tym co zrobiłem/ zrobię spróbujcie popatrzyć na realizację od strony elementów Sprint Backlogu – co zrobiliśmy w kontekście danego elementu, czego brakuje by go “skończyć”, jak dziś możemy to zrobić?
  • zadajcie sobie pytania o ocenę szans realizacji planu. Czy biorąc pod uwagę liczbę pozostałych dni “damy radę”?
  • zadajcie sobie pytanie jak będzie wyglądało Sprint Review? Co i jak pokażemy? Co w takim razie musimy zrobic po kolei by to miało szansę spełnienia?
  • prowadźcie/ korzystajcie z dodatkowy wizualizacji – jeśli wykres spalania przypomina równinę to znak, że warto pomyśleć o aktualności planu.

Podsumowanie

Daily Scrum to trochę jak bicie serca Sprintu, w pewien sposób odlicza czas do Sprint Review i dyskusji o przyszłości produktu. Bardzo rzadko widuję efektywne Sprint Review kiedy Daily Scrum kulało podczas Sprintu.

Obserwujcie więc Wasze Daily Scrum, bo bez inspekcji i adaptacji marnujemy tylko swój czas.