Praktyka stosowania Burn Down Charts w kontekście SAFe i Scrum

W tym artykule planuję opowiedzieć, jak w naszej praktyce stosujemy diagram spalania (Burn Down Chart) w procesie pracy według metodologii SAFe

Zacznę chyba od najciekawszego. Mianowicie od tego, że stosowanie tego diagramu w SAFe nie powinno mieć żadnej specyfiki względem stosowania tego diagramu w SCRUM. Czy powinno?

SAFe u nas różni się obecnością takiej roli, jak RTE, w przeciwieństwie do SCRUM, gdzie jej nie ma. Burn Down Chart - to narzędzie śledzenia wolumenu prac w sprincie i jest potrzebne przede wszystkim dla zespołu SCRUM, a nie dla kogoś z zewnątrz, czyż nie?

Tak więc przejdę jednak do tego, jak używamy Burn Down Chart, niezależnie od wszystkiego, i pozostając wciąż wewnątrz frameworku SAFe.

Jestem w roli Scrum Master i staram się wyświetlać ten diagram codziennie dla całego Dev Team. Środek, którego używam - to czat zespołowy, wzmianka całego zespołu przez "@", zrzut ekranu aktualnego stanu diagramu. Wzmianka całego zespołu - to dość delikatne narzędzie i ważne jest, by używać go jak najrzadziej(czyż nie powinniśmy, my, Scrum Masterzy, pomagać zespołowi pracować w komforcie i z minimalnie możliwą utratą koncentracji?)

W rezultacie zespół codziennie widzi aktualny stan sprintu i jest w stanie śledzić następujące zdarzenia

• Pojawienie się nieplanowanej pracy
• Długie zawieszanie zadań w niezakończonym statusie
• Nadmierne zakładanie ryzyk
• Zrozumienie - czy praca idzie we właściwym tempie

Dalej postaram się rozwinąć każde z tych zdarzeń i podać przykłady z własnej praktyki.

Pojawienie się nieplanowanej pracy

Na tym diagramie bardzo dobrze widać, jak pojawia się nowa praca (w drugi wtorek dwutygodniowego sprintu).

Przypadek z praktyki: "Programista, jako członek zespołu scrumowego, podzielającego zasady agile, świetnie współpracuje z Productem bezpośrednio. Product mówi mu, że to trzeba szybciutko zrobić, sam przecież rozumiesz, tu szybko i ryzyka minimalne.

Programista jest świetny, wie wszystko o agile i o ważności dostarczania wartości biznesowej, idzie i wrzuca na tablicę historyjkę z backlogu, oceniona przez zespół na 6 sp.

Reszta zespołu (oprócz programisty i Producta) zauważa to na porannym update diagramu. Na standupie zespół podejmuje decyzję, co zrobić z tą sytuacją. Najprawdopodobniej historyjka zostaje wyrzucona ze sprintu, Productowi i Programiście zespół daje do zrozumienia, że tak robić nie można, product może umieścić tę historyjkę w następnym sprincie w razie potrzeby.

Oczywiście, w idealnym przypadku zespół powinien zauważyć pojawienie się nowej pracy na standupie i bez diagramu. Ale diagram jest dobrym wskaźnikiem, który sprowadza ryzyko niezauważenia tak ważnej dla całego zespołu zmiany do minimum.

Ważne jest tu zrozumienie, że scenariusz mógłby potoczyć się różnie w zależności od poziomu zespołu. W świetnych zespołach Właściciel produktu raczej by tak nie zrobił, a jeśli już by zrobił, to argumentowałby nie tym, że «to można szybciutko zrobić», ale tym, że «oceniam na 55% prawdopodobieństwo, że jeśli zrobić to teraz, to może zwiększyć nasz zysk o 20% w następnym miesiącu» lub jeszcze jakąś inną mierzalną metryką.

Długie zawieszanie zadań w niezakończonym statusie

Widzimy tutaj, że bardzo długo praca nie zostaje ukończona nawet częściowo. Może to sygnalizować różne problemy, wymienię niektóre z nich

• Zła dekompozycja zadań

  Bardzo często początkujące zespoły mówią o niemożności dekompozycji. U nich wszystko spala się w ostatni dzień, praca nie jest zrównoleglana itd. Oczywiście, trzeba nad tym pracować Scrum Masterowi i wyjaśniać zespołowi wartość dekompozycji.

• Nieoptymalnie sformułowany DOD

  DOD (Definition of Done) - opis kryteriów gotowości User Story w sprincie. Czasem ich w ogóle nie ma lub są opisane bardzo abstrakcyjnie. To całkiem może być problemem, który, oczywiście, powinien pomóc rozwiązać Scrum Master

Nadmierne zakładanie ryzyk

W tym przypadku widzimy sytuację, gdy zespół przełożył ryzyka.

Możliwe, że jakaś historia została przeszacowana. Możliwe, że to bardziej systemowy problem i trzeba zwiększyć wolumen pracy przy planowaniu sprintu. W każdym razie ta sytuacja nie jest poprawna. Wszak biznes planował, że zostaną zrealizowane właśnie zadania sprintu i właśnie do końca sprintu. W zależności od tego, jak zostały zaplanowane zależności, tutaj najprawdopodobniej trzeba będzie przeprowadzić spotkania w celu skorygowania oczekiwań.

W mojej praktyce tak było, gdy znalazło się rozwiązanie szybsze niż omawiane przy szacowaniu. Omawialiśmy całą drużyną, którą historię będziemy mogli zamknąć do końca sprintu, i na retrospektywie uzgodniliśmy, że będziemy starać się przeglądać kod podczas groomingu. Okazało się, że wystarczyło po prostu zajrzeć do kodu, aby zrozumieć, że rozwiązanie jest znacznie prostsze.

Zrozumienie - czy praca idzie we właściwym tempie

Tutaj chciałbym zwrócić uwagę na graficznie nieudane sposoby prezentacji Burn Down Chart

W górnej części obrazu podano przykład niezbyt udanej realizacji graficznej z dwóch powodów, które przedstawię poniżej.

• Nie widać wpadnięcia nowych SP do sprintu

  Tutaj, na górnym diagramie, praktycznie nie widać, że dodano nieplanowaną pracę. Na dolnym jest to bardziej czytelne.

• Niepoprawnie wyświetlana jest względna pozostała ilość pracy

  Zgodnie z górnym diagramem pozostały jeszcze 3 dni pracy. W rzeczywistości są 2, w dzień wolny, możliwe, że ktoś planuje odpocząć.

Oczywiście, komuś takie drobiazgi mogą wydać się nieistotne. Ale trzeba rozumieć, że każdy członek zespołu tylko kątem oka spojrzy na ten diagram i powinien on przekazać maksimum przydatnej informacji.