Scrum jak Waterfall, czyli jak zarządzać efektywnością zespołów, żeby dowozić na czas

Case Study: Jak szacować terminy i brać odpowiedzialność za wyniki?

Dla jednego z naszych klientów prowadziliśmy skomplikowany projekt budowy platformy sprzedażowej dla produktów finansowych. Nasz partner już na wstępie posiadał wysokie standardy procesowe i metodyki realizacji projektów, skłaniając się powoli ku metodykom zwinnym.

Ważne jednak, że poprzedni etap projektu był etapem waterfall – nie startowaliśmy z pracami od zera, ale dołączając do klienta już w trakcie pracy nad rozwiązaniem. Dlatego cały zespół projektowy (nasz i klienta) musiał płynnie przejść z jednej metody wykonywania projektu, do realizacji w scrumie. 

Nasz zespół projektowy składał się z ponad 20 osób, w tym głównie developerów. Jednak dla powodzenia całego projektu mieliśmy też grupę osób w rolach analityków biznesowo-systemowych, a także testerów. Do tego Scrum Master jako osobna rola, ze względu na liczbę osób w teamie i poziom skomplikowania projektu.  

Co ważne, nasz partner miał jedno bardzo istotne oczekiwanie. Chociaż realizowany przez nas etap budowy platformy sprzedażowej miał być prowadzony w metodykach zwinnych i nie umawialiśmy się na konkretny termin oddania, to jednak w miarę szybko po uruchomieniu projektu mieliśmy oszacować datę wdrożenia.

Nie jest to standardowe działanie w scrumie, ale dzięki odpowiednim procesom, standardom i narzędziom, prowadząc projekty agile’owe, można dosyć dokładnie szacować datę realizacji, nie pozbawiając się zalet, jakie niesie za sobą zwinność w software developmencie.

Etapy budowania docelowego modelu scrum oraz planowania realizacji

Etap 1.0

Ponieważ rozpoczynając współpracę z klientem przechodziliśmy z modelu waterfallowego, to wspólnie w zespole zdecydowaliśmy, że gwałtowne przejście do realizacji w pełnym scrumie może być zbyt ryzykowne.

Pracując ponad dwudziestoosobowym zespołem i wdrażając pierwsze standardy oraz narzędzia (choćby Jirę), postanowiliśmy na starcie etapu nie dzielić zespołu i potraktować dalsze wyceny poszczególnych funkcjonalności/historyjek na poziomie story pointów, ale przeliczanych 1:1 w zgodzie z czasem (przelicznik godzinowy).

Odstaje to od standardów scrumowych, ale takie podejście pomogło płynnie rozpocząć pracę i krok po kroku wyedukować zespół po stronie klienta, jak docelowe story pointy powinny tak naprawdę wyglądać.  

Wyceny, podobnie jak na poprzednim waterfallowym etapie, realizowane były ekspercko. Grupa liderów po naszej stronie dokonywała kolejnych wycen, a zespół realizował taski wierząc, że wycena jest prawidłowa. Kolejnym zadaniem, które nie było do końca zgodne z podręcznikowym scrumowym podejściem, było równoległe uruchomienie sprintów analitycznych razem ze sprintami developerskimi.

Wynikało to ze wspomnianej już wcześniej prośby klienta, aby dokładnie wskazać datę wdrożenia. Pomóc w tym miał Fix Version Report. Jednak, aby go użyć, niezbędna była wycena wszystkich historyjek przypisanych w backlogu do tego etapu wytwórczego i to na poziomie bardzo szczegółowym. 

Sam start budowania backlogu był ważnym etapem w kontekście architektury i schematu wiązania historyjek w epiki, wersje itp. Wiedzieliśmy, że musi być to przemyślane, ponieważ później wszelkie raportowanie danych z Jiry będzie bardzo ułatwione (np. będziemy mieć możliwość kontekstowego wybierania na poziomie merytorycznym danej wersji czy wszystkich historyjek związanych z kontraktami integracyjnymi).  

Cały ten etap trwał 3 sprinty. 

Etap 2.0

Na tym etapie powoli zbliżaliśmy się do zbudowania docelowego modelu scrum w projekcie. Cały nasz team podzieliśmy najpierw na dwa, a następnie na trzy zespoły scrumowe, tak aby powoli zachodziła w nich bliska współpraca, komunikacja i samoorganizacja.

Każdy z zespołów posiadał grupę developerów oraz testerów, a analitycy dołączali do zespołów w poszczególnych sprintach. Jednocześnie uruchomialiśmy pozostałe standardy (na początek głównie zebrania scrumowe), a także zaczęliśmy liczyć story pointy zgodnie z metodyką (wcześniejsza edukacja pozwoliła wreszcie oderwać je od miernika, jakim jest czas).

Także wyceny były już liczone za pomocą Scrum Pokera i tym samym odpowiedzialność za wycenę przesunęliśmy na każdego z członków zespołu. 

W momencie, kiedy uruchomiliśmy już elementy scrumowe, zaczęliśmy się bacznie przyglądać burndown chartowi (wykresowi spalania), jako podstawowemu narzędziu do kontroli optymalnego sposobu pracy zespołu. Natomiast w momencie, w którym analiza backlogu pozwoliła już wycenić wszystkie historyjki, bardzo przydatne okazało się już wcześniej wspomniane narzędzie Fix Version. 

Capacity – podstawa wydajności zespołu developerskiego

Wiedzieliśmy, że dostępność osób niezbędnych dla danego sprintu warto planować do przodu. Pierwsza i podstawowa metoda, to oczywiście plan urlopów/nieobecności. Dodatkowo zastosowaliśmy prosty Excel, pokazujący dostępność developerów — w końcu to oni w pierwszej linii spalali story pointy i byli kluczową grupą ekspertów w zespole.

To właśnie ich obecność stała się czynnikiem decyzyjnym w odniesieniu do pojemności story pointów w każdym sprincie. Proste obliczenia na podstawie samej (nie)obecności developerów były bardziej miarodajne niż planowanie sprintu w oparciu o efekty działań z poprzednich dwóch tygodni.

Narzędzia: czego używać, żeby monitorować postępy i zarządzać projektem w czasie

Narzędzia: Sprint burndown chart

Korzyści, które możemy odnieść stosując sprint burndown chart:

• Monitorowanie postępów w sprincie w czasie rzeczywistym;
• Ocena, jak wiele pracy pozostało do wykonania;
• Wczesne wykrycie problemów w danym sprincie;
• Wsparcie komunikacji w zespole;
• Motywacja w zespole;
• Wsparcie optymalizacji sposobu pracy w zespole.

Sprint burndown chart to narzędzie, które pozwala wykryć wiele nieprawidłowości w projekcie, zaczynając od bardzo podstawowych błędów jak choćby niewłaściwe/nierzetelne użytkowanie Jiry. Wiele z efektywności prac developerskich tracimy przez proste niedopatrzenia, jak np. brak szybkiego przekierowania taska w Jirze na kolejną osobę.  

Możemy z jego pomocą również odkryć, że nasze historyjki są zbyt obszerne. Jeżeli jakaś historyjka w sprincie wymaga kilku czy nawet kilkunastu dni realizacji, warto pociąć ją na mniejsze elementy.

Przy zbyt długim software developmencie, praca testerów zaczyna być nieoptymalna — zazwyczaj już drugiego dnia sprintu testerzy powinni powoli startować z testami. Z naszej strony rekomendujemy historyjki poniżej 13 story pointów.

Narzędzia: Fix Version Report

Korzyści, które możemy odnieść stosując Fix Version Report:

• Śledzenie postępu prac nad konkretną wersją produktu;
• Strategiczna kontrola nad backlogiem (w projektach zwinnych backlog żyje i często dochodzą nowe historyjki. Przy zastosowaniu tego narzędzia product owner może zyskać szerszy pogląd na całość realizacji. Zobaczyć, że kolejne zmiany oddalają nas od wdrożenia i podjąć odpowiednie kroki, np. okroić MVP, żeby wypuścić je na czas);
• Dokładne zaplanowanie prac nad daną wersją;
• Ciągłe doskonalenie procesów pracy
• Koordynacja działań (biznes-technologia) w celu osiągnięcia celów.

Aby rozwiać wszelkie wątpliwości, że projekt pozbawiliśmy elastyczności kosztem daty wdrożenia, to chociaż wystartowaliśmy z poziomu 1100 story pointów, ostatecznie MVP rozbudowało się do 1400 story pointów.

Scrum nie służy do zamknięcia backlogu, ale choćby dzięki wymienionym wyżej narzędziom, umożliwia ocenę i konsekwencję działań, a także przejrzyste planowanie prac oraz realizację sprintów w określonych z góry terminach. 

Chcesz wiedzieć się więcej o zarządzaniu efektywnością zespołów IT?