.st0{fill:#FFFFFF;}

Deskalowanie Zespołów Scrumowych 

 24 czerwca, 2024

Tomasz Dzierżek

Kilka Celów Sprintu, indywidualna i niezależna praca poszczególnych osób w zespole, „po co nam Daily”, „nie mamy co pokazać na Review” i tak dalej… Brzmi znajomo? Rozwiązanie to może być deskalowanie.

 

Deskalowanie Zespołów Scrumowych

Jednym z najczęstszych powodów stanu rzeczy opisanego we wstępie jest niedopasowanie Scruma do specyfiki naszej pracy. Oczywiście, zawsze powtarzamy, że to metodyki są dla nas, a nie my dla metodyk – warto jednak wybrać to, co pasuje do naszych celów. Ale może też być też inna, prostsza, przyczyna takiego stanu rzeczy.

Jeff Sutherland (ten Jeff Sutherland) od zawsze mówił, że siedmioosobowe Zespoły Scrumowe (a w tamtych czasach jeszcze Zespoły Deweloperskie) dzielił nam mniejsze. Prosta matematyka sugeruje, że w każdym z takich mniejszych zespołów będą się znajdowały trzy albo cztery osoby (plus Product Owner i Scrum Master).

Trzy albo cztery osoby to świetna wielkość grupki szturmowej albo zespołu zadaniowego, który faktycznie robi jedną rzecz i jest skupiony na pojedynczym celu. W Scrum Guide 2020 przeczytamy o tym, że „[Scrum Team] to spójna grupa profesjonalistów skupionych na pojedynczym celu określanym jako Cel Produktu.” Taką konfigurację bardzo łatwo jest uzyskać, jeżeli mamy trzy bądź cztery osoby. Trudno zaś żeby wszyscy skupili się na jednym Celu Produktu, jeżeli tych osób jest kilkadziesiąt.

W skali mikro, jeżeli mamy problem z tym, że potrzebujemy kilka Celów Sprintu, żeby pokryć kilka różnych grupek, to prawdopodobnie mierzymy się z tym samym problemem. Rozwiązaniem może być deskalowanie, ale najpierw upewnijmy się, że to faktycznie jest nasz problem.

 

Wszystko wychodzi na Daily

Najlepszym miejscem, gdzie możemy zobaczyć czy mamy faktycznie do czynienia z jednym zespołem, czy z jakimiś formalnymi bądź nieformalnymi podgrupami jest Daily Scrum. Jeżeli na Daily trzy osoby żywo rozmawiają o swoich pracach, a pozostałe cztery osoby śpią, a w połowie czasu sytuacja się odwraca, to prawdopodobnie na siłę skleiliśmy dwa zespoły w jeden.

Mogło się też tak zdarzyć, że zespół się nam po prostu rozrósł i poszczególne osoby wyspecjalizowały się w pewnych aspektach naszego produktu. W takiej sytuacji naturalne jest, że wszystkie wymagania związane z tymi aspektami będą trafiały do tych konkretnych osób. Pytanie tylko, czy faktycznie w dalszym ciągu mamy jeden zespół czy już stworzyły się nam podgrupy?

Niezależnie od powodu, warto w takim przypadku zainteresować się deskalowaniem, czyli zmniejszeniem skali. Możemy to osiągnąć przez podział dużego zespołu na mniejsze bądź też na przekazanie części zespołu do innego Product Ownera i innego backlogu. W obu przypadkach celem jest posiadanie mniejszych i bardziej „sfokusowanych” zespołów.

Scrum Guide mówi, że Scrum Team jest spójną grupą i „nie dzieli się na podzespoły, nie obowiązuje w nim hierarchia”. Z kolei doświadczenie mówi, że jeżeli taki siedmio-ośmioosobowy zespół podzielimy na dwa mniejsze, to zaoszczędzimy też czas na Wydarzeniach Scrum. Np. Planowanie zamiast dwóch godzin będzie trwało godzinkę, a Daily skrócą się z 15 minut do 5.

Przede wszystkim, dzieląc zespoły na małe, zyskamy skupienie i w naturalny sposób zacznie działać więcej mechanizmów scrumowych, bo ludzie faktycznie będą widzieli potrzeby do synchronizowania się, a wszystkich będzie interesowało to co robią inni. Bo tych „innych” będzie tylko kilka osób.

 

Indywidualne prace w zespole scrumowym

Opisywany powyżej sposób postępowania nie zadziała w sytuacji, w której nie mamy nawet trzy-czteroosobowego zespołu, ale każdy robi zupełnie co innego i są to prace totalnie niezależne.

Zawsze powtarzamy, że zespół to jest jedna grupa ludzi ze wspólnym celem. Ten cel musi jednak być bliski. Nadużywany przez nas przykład to budowa domu – co z tego, że grupka 10 osób ma za cel „przekazanie przyszłym właścicielom domu do użytku”, skoro cztery osoby układają kostkę na podjeździe, cztery osoby sadzą rośliny w ogrodzie, a dwie osoby montują panele fotowoltaiczne?

Wiele osób w powyższej sytuacji powie, że te 10 osób jest jednym zespołem, bo przecież „budują dom”. Zastanówmy się jednak, co się stanie, gdy osoby od paneli znikną z placu budowy na dwa miesiące. Pozostała część „zespołu” nawet tego nie zauważy! A to już jasno pokazuje nam, że ci ludzie nie są jednym zespołem i nie mają jednego wspólnego celu.

Próbując ubrać takie osoby w jeden zespół nagle okaże się, że potrzebujemy kilku Celów Sprintu, bo przecież jedni muszą posadzić tuje, drudzy muszą ułożyć podjazd, a trzeci muszą zamontować pierwszą partię paneli. I oczywiście szybko wyjdzie to na Daily, bo przecież problemy osób zajmujących się ogrodem są zupełnie inne i niezwiązane z osobami układającymi kostkę.

Jeszcze gorzej jest, kiedy prace są zupełnie indywidualne i każda pojedyncza osoba zajmuje się czymś zupełnie innym. Wtedy jeśli dowolna osoba z naszego „zespołu” nie przyjdzie do pracy, to nikogo to nie będzie obchodziło, bo jego praca nie ma wpływu na żadną inną osobę.

Ale to już temat na inny tekst. Albo na newsletter, gdzie raz w tygodniu rozsyłamy tego typu wiadomości na Twój adres e-mail. Zdarzają się też zniżki, promocje oraz ekskluzywne propozycje dla subskrybentów. Również niniejszy tekst oryginalnie został rozesłany do czytelników naszej listy mailingowej, a zadziało się to ponad rok temu!

Tomasz Dzierżek


23+ lat doświadczenia w IT, 15+ lat doświadczenia w Scrum i agile, PSM III (i inne), konsultant zwinnych procesów i zespołów, Agile Coach, trener

Your email address will not be published. Required fields are marked

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}