Bardzo często słyszymy pytania na temat Scruma w większej skali. I chociaż bardzo chcielibyśmy zająć się nimi wszystkimi, musimy tego słonia jeść po kawałku. Tak więc w cyklu „dziś pytanie, dziś odpowiedź” – kto synchronizuje prace Zespołów Scrumowych?
Wyzwania Skalowania
Zacznijmy od tego, że skalowanie Scrum to temat rzeka. I wcale nie chodzi nam o lanie wody, ale o fakt, że problemów jest niezliczona ilość. Z zupełnie innymi wyzwaniami będziemy się borykać w przypadku 4-5 zespołów, a na inne problemy trafimy przy trzydziestu czy czterdziestu Scrum Teamach.
Co więcej, skala wcale nie jest jedynym wyznacznikiem ani problemów, ani też potencjalnych rozwiązań. Możliwych jest wiele różnych konfiguracji Product Backlogów, Product Ownerów, Proxy Product Ownerów i nie tylko. O wielu z nich na pewno jeszcze będziemy pisali na blogu i mówili na naszym kanale na YouTube.
Czy jeśli rozwijamy sześć systemów, to potrzebujemy sześciu PO? A może uda się to zmieścić w jednym backlogu? Czy potrzebujemy Scrum of Scrums? Jak rozwiązać zależności? Jak zbudować zespół, jeżeli mamy kilkanaście warstw i komponentów?
Niestety, większość odpowiedzi na pytania dotyczące skalowania zaczynamy od ulubionych słów wszystkich konsultantów, czyli „to zależy”. Nie bez powodu mamy w swojej ofercie agile’owe wsparcie dla zwinnych firm, gdzie najpierw poznajemy organizację, a dopiero potem doradzamy i proponujemy rozwiązania.
Na pytanie „Kto synchronizuje prace Zespołów Scrumowych?” też odpowiemy w powyższy sposób. Ale postaramy się też przy tej okazji opowiedzieć na pytanie od czego „to zależy”.
Akcja Komunikacja
Od dawna głośno mówimy, że „ten cały agile” to tak naprawdę zdrowy rozsądek, który stosujemy w mniej lub bardziej zdefiniowany sposób. A gdy zaczynamy działać rozsądnie, nie tylko stajemy się bardziej zwinni, ale też unikamy wielu dziwnych problemów. I wtedy synchronizacja dzieje się sama.
Jeżeli potrzebujemy zsynchronizować prace kilku zespołów, to przede wszystkim zastanówmy się nad tym, czy w ogóle jest jeden wspólny efekt ich pracy. Jeśli tak jest, to pewnie mamy tu do czynienia z jednym backlogiem i jednym Product Ownerem. Taka konstrukcja powoduje, że to niejako PO dba o to, żeby podział prac pomiędzy zespołami był sensowny. „Niejako” jest tu jednak bardzo zasadne i wrócimy do tego pod koniec tekstu.
W przypadkach Scruma w dużej i bardzo dużej skali często mamy wielu Product Ownerów, którzy wspólnie dbają o spójność realizowania wymagań. Mniej lub bardziej formalne spotkania PO sprawiają, że prace przebiegają płynnie, nikt na nikogo nie czeka. Pomóc może w tym też planowanie przez wydania (patrz: Release Planning).
Jeśli w takiej konfiguracji współpracują ze sobą zespoły pracujące z różnymi PO, czasami pomagają konstrukcje typu Scrum of Scrums. Takie spotkania synchronizacyjne przedstawicieli zespołów (czasami Scrum Masterów, czasami reprezentantów) powodują, że pojawiają nam się swego rodzaju przekaźniki informacji. Ważne jednak, żeby nie był to jedyny sposób na komunikację.
W tekście pod tytułem Feature Team vs. Component Team pokazywaliśmy jeden z wielu punktów widzenia na organizację Zespołów Deweloperskich, który może w ogóle ograniczyć potrzeby synchronizacji. Jeżeli mamy zespoły realizujące funkcjonalności end-to-end, to punktów styku z innymi może być mniej… lub więcej. Wszystko zależy od architektury naszego systemu i zakresu odpowiedzialności poszczególnych zespołów.
Jest jednak jedna część wspólna dla wszystkich wspomnianych pomysłów.
Synchronizacja czy Samoorganizacja?
Warto rozmawiać. Żeby się z kimkolwiek zsynchronizować, musi następować komunikacja. I tutaj sięgniemy do koncepcji pod tytułem „skin in the game„, która mówi, że najlepiej skomunikują się Ci, którym najbardziej zależy na wykonywanych pracach.
Jeżeli więc mówimy o tym, żeby efekt naszych prac był biznesowo spójny oraz o tym, żeby zespoły nie czekały na siebie wzajemnie, wydaje się że będzie to odpowiedzialnością PO. W końcu to oni „maksymalizują wartość prac zespołu”. Waste w postaci oczekiwania na kogoś innego na pewno nie sprzyja temu celowi.
Z kolei w przypadku prac deweloperskich, synchronizacji prac bieżących i uniknięcia wzajemnego grzebania sobie w kodzie, to same Zespoły Deweloperskie powinny nauczyć się i opracować sposoby na synchronizację i komunikację.
Bo to samoorganizacja będzie tu najważniejsza. W tym wydaniu rozumiana jako chęć do odbywania spotkań i synchronizacji, które sami czujemy, że są nam potrzebne. Nikt za nas tego nie zrobi, bo nikt nie wie z czym się borykamy. A centralnie sterowana samoorganizacja nie działa, chociaż oczywiście możemy liczyć na podpowiedzi dobrych praktyk. Pomogą nam w tym Scrum Masterzy i/lub Agile Coachowie, ale to my sami musimy wspólnie wypracować rozwiązanie swoich problemów.
Wróćmy do PO zapewniającego odpowiedni podział backlogów pomiędzy zespoły. Warto przy tej okazji wspomnieć, że równie sensowny podział mogą wypracować same Development Teamy. Przede wszystkim, jeśli widzimy, że mają na to pomysł – nie blokujmy ich samoorganizacji.
A co ze Scrum Masterami? No cóż, oni nie mają skin in the game ani w kontekście synchronizowania backlogu ani dewelopmentu. Oni są odpowiedzialni za to, aby zespoły w których pracują nauczyły się synchronizować i komunikować bez ich potrzeby.
Co nie znaczy, że nie mogą (i nie powinni) tego procesu wspierać. Ale o tym innym razem…
