Praca z wieloma zespołami w Scrumie, czyli jak startować i kończyć sprinty

Cykl: Kreatywni
2 lutego 2015

4

Jeżeli macie do czynienia z kilkoma i więcej zespołami scrumowymi, które pracują nad rozwojem tego samego produktu, wcześniej czy później będziecie musieli w jakiś sposób skoordynować ich pracę. Mój pierwszy, większy projekt, w którym musiałem się z tym uporać liczył pięć zespołów scrumowych. Staraliśmy się planować sprinty tak, żeby między jednym a drugim zespołem był tydzień przerwy. Wówczas, wydawało nam się, że jest to rozsądne podejście. Każdy kolejny zespół, który planował swój sprint, dokładnie wiedział, co zaplanował poprzedni. Tydzień czasu, to całkiem sporo. Poszczególni Właściciele Produktu (z każdym zespołem pracował inny) mogli sobie spokojnie wszystko przemyśleć – ustawić priorytety, wyłapać zależności. Spokojnie i bez stresu można było ruszyć z kolejnym sprintem. Jak się szybko okazało, problemem nie było to, kiedy zespoły planowały sprinty, ale kiedy te sprinty kończyły. W zasadzie, nigdy nie mieliśmy takiego komfortu, żeby móc pokazać klientowi zintegrowany system, który działał − licząc na jego ewentualne uwagi, komentarze, krytykę. Ciągle jakiś zespół kończył, a inny w tym czasie zaczynał.

Zespoły, które mają różne daty startu i końca sprintu
Zespoły, które mają różne daty startu i końca sprintu

Z czasem, zdecydowaliśmy, żeby zsynchronizować daty startu i końca wszystkich sprintów. Niestety, ze względu na mocne zależności między zespołami oraz fakt, że mieliśmy tylko jednego architekta i eksperta od UI-a, nie udało nam się tego zrealizować do końca. W zamian za to, wprowadziliśmy zasadę, że między jednym a drugim spotkaniem planistycznym może być maksymalnie jeden dzień różnicy. W ten sposób, w ciągu kilku dni (maksymalnie pięciu), wszystkie zespoły ruszały i, odpowiednio, kończyły prace. Co sprint mogliśmy pokazywać całość powstającej aplikacji klientowi. Była interakcja, mogliśmy przedyskutować jego uwagi i propozycje, wymienić się spostrzeżeniami. Jedynym mankamentem było dość duże obciążenie architekta i kolegi od UI.

Synchronizacja sprintów, z jednodniową obsuwą pozwala również na pewną dowolność w definiowaniu długości sprintów. Dla zespołów najważniejsze jest, żeby równo zacząć i skończyć prace. Jednak sam sprint może trwać dwa razy dłużej niż pozostałe, co widać na rysunku poniżej.

Zespoły, które mają zsynchronizowane daty startu i końca sprintu
Zespoły, które mają zsynchronizowane daty startu i końca sprintu

Synchronizacja sprintów działa, jeżeli macie nie więcej niż dziesięć zespołów. Jeżeli jest ich więcej, polecam metodę „Dużej Sali”, którą podpatrzyłem u Mike Cohna.

Duża Sala

Technika jest bardzo prosta. Zapraszamy wszystkie zespoły scrumowe w firmie do dużej sali i… planujemy sprint.  Żeby uniknąć niepotrzebnego chaosu, trzeba to spotkanie naprawdę dobrze przygotować, zwłaszcza mam tutaj na myśli poszczególnych Właścicieli Produktu. Spotkania, w których miałem wątpliwą przyjemność uczestniczyć, a które zakończyły się totalną porażką, prawie zawsze były powodowane nieodpowiednim przygotowaniem grupy, zajmującej się rozwojem produktu. Wyobraźcie sobie, że mamy do czynienia z dziesięcioma i więcej Właścicielami Produktu, którzy muszą się komunikować, mieć wspólną wizję tego, co chcą osiągnąć w swoich sprintach. Jeżeli grupa ta nie zacznie nadawać na tych samych falach, to koniec. Projektowa Wieża Babel.

Technika „Dużej Sali”, jak sama nazwa wskazuje wymaga większego pomieszczenia, w którym zmieściłyby się wszystkie zespoły scrumowe, które biorą udział w planowaniu. Główny Właściciel Produktu (Szef Grupy Produktowej) robi krótkie wprowadzenie, mówi o celach, o tym, co chcemy osiągnąć i jaka jest wizja produktu. Następnie, zaczyna się praca w podgrupach. Każdy zespół „zawłaszcza” sobie kawałek wolnej przestrzeni i zaczyna planować swój sprint. Sala może być dowolnie zorganizowana. Żeby zwiększyć ilość wolnego miejsca, dobrze jest pozbyć się krzeseł, stolików. Zespoły siadają w kuckach, opierają się o ścianę.

Sam brałem kilka razy udział w tego typu spotkaniach i za każdym razem było to dla mnie bardzo inspirujące doświadczenie. Dużo dobrej energii krąży w powietrzu. Jeżeli prace naszego zespołu zależą od odpowiedniego dostarczenia historyjek przez drugi zespół, osoby z innego zespołu „wpadają” do nas z krótką wizytą i wspólnie decydujemy, co dalej.

Komunikacja między poszczególnymi zespołami może odbywać się „paszczowo” (ktoś krzyczy: „Hej luuuudzie, potrzebuję Architekta!”) albo za pomocą określonego systemu znaków. Mike Cohn zaproponował, żeby wykorzystywać do tego tzw. Kod Flagowy MKS (skrót od Międzynarodowego Kodu Sygnałowego), który jest wykorzystywany do komunikacji różnego rodzaju informacji w żegludze. Zdefiniował cztery proste komunikaty, które możecie zobaczyć na rysunku poniżej:

Komunikaty wykorzystywane podczas planowania sprintu techniką "Dużej Sali"
Komunikaty wykorzystywane podczas planowania sprintu techniką „Dużej Sali”

W ten sposób, możemy dużo sprawniej się komunikować. Flagi mogą być wydrukowane na kartkach A4 i, w razie potrzeby, umieszczane obok zespołów.

Takie planowanie zajmuje cały dzień, to fakt. Jego dużą zaletą, poza tym, że ułatwia komunikację, pracę z zależnościami, a także osobami, które są „dobrem deficytowym” (Architekt, Właściciel Produktu) jest to, że bardzo mocno jednoczy zespoły wokół jednego celu, wizji, która jest wspólna dla wszystkich. A to jest coś, co często szwankuje w dużych projektach. Między innymi, dzięki takim metodom, możecie sobie z tym sprawnie poradzić.