W pracy spotkałem się z różnymi formami wizualizacji sprint backlogu czy przepływu wartości przez system. Od najprostszych fizycznych tablic typu 'to do, ongoing, done' do bardzo rozbudowanych elektronicznych wersji (Jira, TFS, Redmine, Target Process). W większości przypadków to zespół miał możliwość dostosować sobie swoją scrumową (lub kanbanową) tablicę do swoich potrzeb. Czasem wymagało to prowadzenia (niestety) dwóch tablic - gdyż np. elektroniczna wersja wymagana była do zapewnienia transparencji do klienta lub PO, który znajdował się w innej lokacji. Spotkałem się też z ciekawymi i zakręconymi tablicami - szalonymi eksperymentami 🙂 Łączyło je wszystko jedno - były tworem eksperymentów. I takim eksperymentem zajmiemy się dzisiaj.
Zacznijmy od tego po co nam właściwie tablica?
- Pokazujemy w jaki sposób (jakimi zadaniami) zrealizujemy cel sprintu
- Wiemy ile jeszcze pracy nam zostało, a co już jest zrobione - czyli gdzie jesteśmy obecnie
- Diagnozujemy gdzie są potencjalne ryzyka (np. wąskie gardła)
- W jaki sposób najbardziej optymalnie podzielić się pracą w zespole - codzienne planowanie
- Zapewniamy transparencję naszej pracy do interesariuszy (co buduje zaufanie)
- Wizualizujemy stan akcji usprawniających
- Oraz aby spełnić inne potrzeby, o których w tej chwili nie pomyślałem 🙂
Chciałbym wam przedstawić ewolucję pewnej tablicy pewnego zespołu (od momentu, w którym do nich dołączyłem).
Przy okazji bardzo dziękuję chłopakom, że pozwolili mi się tą historią z Wami podzielić. Sam proces zmiany i techniki były wspierane co prawda przeze mnie, ale cały wkład (kształt procesu, tablicy) to już całkowicie zasługa samego zespołu.
Wersja początkowa
Tablica wyglądała tak:
Moją pierwszą reakcją było: o co chodzi w tej tablicy? Sam kiedyś eksperymentowałem z łańcuchem krytycznym przy planowaniu sprintu, ale nigdy rezygnując jednocześnie z tablicy przepływowej. Na szczęście nie zacząłem od rewolucji i 'narzucenia' jedynego słusznego kształtu tablicy. Postanowiłem poobserwować, zadawać pytania i odzwierciedlać (w skrócie - marudzić 😉 ).
Po pytaniach o kształt tablicy, zespół wymienił następujące korzyści, które chcieli uzyskać:
- możliwość planowania daty ukończenia zadania
- co za tym idzie - uzyskać większą przewidywalność ukończenia zadań
- dodatkowo: możliwość rozplanowania sobie pracy i zobaczenia zależności (kto gdzie jest zajęty) -> w skrócie, wstęp do łańcucha krytycznego
To co ja zauważyłem to:
- duże zadania (po kilka dni)
- rozpoczynanie wielu rzeczy na raz
- karteczki nie odzwierciedlały faktycznych stanów zadań
- nie wiadomo kiedy mamy coś 'DONE'
- zadania często nie kończyły się w dniach zaplanowanych przez zespół
- (po jakimś czasie) członkowie zespołu nie wiedzieli co się dzieje z zadaniami, kiedy brakuje w danym dniu kogoś, kto się tym zadaniem zajmował
Co było dalej
Krok pierwszy - obserwacja, odzwierciedlenie, potrzeba zmiany.
- odzwierciedlałem do zespołu każdy przykład niejasności, braku spójności tablicy ze stanem faktycznym
- zadawałem pytania ("czy to już jest DONE, czy jeszcze nie?"; "to w jaki sposób te zadania przybliżą nas do celu sprintu?" i inne takie 🙂
Po jakimś czasie część osób w zespole zaczęło otwarcie mówić, że tablica jest dla nich nieczytelna i nie pomaga w planowaniu zadań. Porozmawiałem w między czasie z doświadczonym członkiem zespołu - przedstawiłem pomysł wizualizacji procesu dostarczania funkcjonalności w produkcie (produktach) rozwijanych przez zespół. Zasugerowałem też, że są inne opcje wizualizacji - np. tablica stanów. Jednym słowem - wzmocniłem potrzebę zmiany i zebrałem koalicję 🙂
Krok drugi - wizualizacja strumienia wartości.
Zrobiliśmy sobie ćwiczenie, gdzie rozrysowaliśmy cykl życia naszych wymagań. Celem było uświadomienie sobie nawzajem jaką ścieżkę musi przebyć potrzeba klienta od 'poczęcia' do dostarczenia. Skupiliśmy się na stanie rzeczywistym, nie na 'idealnym'. Taki był wynik:
Krok trzeci - draft nowej tablicy.
W ostatni dzień sprintu, już po spotkaniach zrobiliśmy z zespołem draft tablicy. Skupiliśmy się na tym, aby zwizualizować potencjalne 'wąskie gardła' - czyli stany oczekiwania zadań. Okazało się, że możemy rozbić przepływ na dwie części - dla zadań oraz wizualizacja przepływu funkcjonalności na poziomie Product Backlogu.
Co ciekawe - pojawił się też pomysł aktualizacji samego procesu release'u softu tak, aby składał się on z mniejszej liczby kroków. Postanowiliśmy skorzystać z okazji i zrobić to.
Krok czwarty - tablica v0.1
Pierwszy dzień sprintu - stworzyliśmy pierwszą wersję tablicy.
Dalsze kroki:
Pierwsze obserwacje:
- Wow, ale mamy dużo tych stanów
- Dolna część tablicy (ścieżka US) jest nieużywana za bardzo (jeszcze)
- Po 2 dniach sprintu udało się zamknąć 9 zadań (w tym 90% akcji z retrospekcji) -> wcześniej w pierwszym tygodniu sprintu (z trzech) udawało się zamknąć 2-3 zadania.
Dalsza obserwacja i wyciągnięcie wniosków z zespołem (po iteracji), w szczególności:
- jak tablica wpłynęła na transparencję zadań
- co się stało z cycle time dla historyjek w sprincie
- jak wpłynęło to na naszą przewidywalność
- jak oceniają tablicę pozostali interesariusze (np. PO)
- czy ilość stanów spełnia swoją rolę? Czy dolna część tablicy będzie wartościowa?
- w jaki sposób praca z tablicą może nam wskazać drogę skracania procesu delivery?
Podsumowując: tablica scrum'owa (czy kanbanowa) jest moim zdaniem jednym z podstawowych narzędzi pracy zespołu, a co za tym idzie - także jednym z obszarów zainteresowań Scrum Mastera. Warto moim zdaniem zachęcać zespół do eksperymentowania z tym narzędziem - jednocześnie przedstawiając dobre praktyki czy to z branży czy z własnego doświadczenia 🙂
Jednocześnie warto pamiętać, że to co zadziałało w jednym miejscu, niekoniecznie sprawdzi się w innym.
A jak jest u Ciebie? Czy ośmielisz się wrzucić zdjęcie swojej tablicy?