Coraz częściej słyszymy, że im mniejszy zespół tym lepszy. Czy na pewno? Postanowiliśmy podjąć temat i przygotować rozprawkę w temacie „małe zespoły – plusy i minusy”. Jak myślicie, które podejście „wygra”? Czy 4-osobowe zespoły to remedium na wszystkie bolączki zwinności?
Wygrani i przegrani
Oczywiście nie będzie tutaj jednoznacznych wygranych i przegranych. Każda organizacja jest inna, każdy Zespół Deweloperski jest inny i nie można generalizować. Nasz tekst oprzemy o pewne powtarzalne obserwacje, które są na tyle uniwersalne, że pozwalają nam twierdzić, że małe zespoły… no właśnie.
Układając sobie schemat dzisiejszego wpisu znalazłem dużo więcej cech „mniej-pozytywnych” niż pozytywnych. Szanowny czytelniku wiedz, że nie będę porównywał wszystkich małych i dużych zespołów, a skupię się wyłącznie na tych, które liczą maksymalnie 4-5 osób. Czy na pewno są lepsze? Czy dzięki nim osiągniemy więcej, dostarczymy szybciej, będziemy lepsi?
Według badań naukowców idealny rozmiar zespołu to 4,6 (to już wiecie). Dlaczego więc #białko próbuje udowodnić, że się mylą? Podważanie badań bez przeprowadzenia własnych brzmi groteskowo. Mamy jednak coś innego niż badania – praktyczną wiedzę i obserwacje, które pozwalają nam postawić tezę. Emanacja tej tezy znajduje się w tytule dzisiejszego wpisu. Ale zacznijmy od początku…
Rozpocznijmy od pozytywów
Pozytywy jak najbardziej istnieją. Mniejszy zespół to najczęściej brak problemów z komunikacją. Jesteśmy w stanie dotrzeć z informacją do każdego z członków zespołu, jesteśmy też w stanie zadbać o to, aby każdy rozumiał go w taki sam sposób. Mniejsze zespoły to również brak podgrupek, po prostu nie ma na to miejsca. Mniejsze zespoły to również mniejsza okazja do powstawania konfliktów. Dodatkowo, decyzje zwykle podejmowane są szybciej. W mniejszych zespołach nie ukryją się nam ludzie, którzy nie chcą wziąć odpowiedzialności za przygotowanie rozwiązania.
Te wszystkie powody, choć na pewno dałoby się wypisać ich jeszcze więcej, pokazują, że mniejszy zespół nie do końca musi oznaczać coś złego. Posiadając mniejszy zespół każdy z jego członków ma szansę poczuć się tak samo, jak inni. Każdy wie wszystko, jest w taki sam sposób traktowany i w taki sam sposób ma przełożenie na powstający Produkt. Sytuacja idealna? Owszem, jednak jak zawsze wszystko, jak zaraz zobaczycie jest pięknie, dopóki nie sięgniemy do szczegółów.
Załóżmy, że w chwili obecnej mamy 2 zespoły 8-9 osobowe. Zespoły te są w pełni cross kompetencyjne, mają swojego Product Ownera, Scrum Mastera, mają swoje Backlogi – jednym słowem jest jak powinno być. Dzielimy?
Czas na kwestie negatywne
Zanim dojdę do samego podziału, odpowiedzmy sobie na moje ulubione pytanie „po co?”. Co chcemy osiągnąć tą zmianą? Nie oszukujmy się, w krótkim okresie będzie gorzej a i w długim może być różnie. Może… to słowo klucz. Nikt tego nie wie, choć są pewne uwarunkowania, które pozwalają twierdzić, że może być różnie. Jeśli nie powiemy „po co?” mamy gotowy przepis na katastrofę.
Istnieje oczywiście szansa, że odpowiedź na pytanie „po co?” została udzielona. Nie łudźmy się jednak, że podział zespołów na mniejsze spowoduje, że z momentem jego wprowadzenia prędkość działania zespołów wzrośnie. Wręcz przeciwnie, prędkość ta na pewno spadnie. Wpływ na to będą miały nowa sytuacja, nowy układ, niepewność, konieczność przygotowania Backlogu, konieczność ponownej organizacji zespołów. To, co do tej pory robiliśmy w jednym zespole, teraz będziemy robić w dwóch. Czy potrzebni są nam dwaj PO/SM? Pewnie nie, ale potrzebne będą nam dwa Planowania, dwa Daily, dwie Retrospektywy. Sprint Review może odbywać się wspólnie, jednak pozostałe wydarzenia / procesy (np. Refinement) to konieczność jeszcze większego zaangażowania unikalnych ludzi.
Kolejną kwestią są zależności. Zwykle nie da się podzielić Deweloperów na 4 osobowe zespoły bez zależności. Samo wydzielenie mikro-zespołów spowoduje, że tematy, którymi będą w stanie się zająć będą małe, a to z kolei spowoduje, że chcąc dostarczyć funkcjonalności w określonym czasie (np. w jeden Sprint) będziemy musieli zaangażować więcej niż jeden zespół. Jak się pracuje z zależnościami? Każdy wie? Po co się w to pchać?
Rekomendacja zespołu #białko
Jeśli jeszcze komuś nie wystarczy… mam wisienkę na torcie. Nie ma firmy, gdzie mielibyśmy 16 równorzędnych deweloperów (wracając do przykładu z początku). Zawsze jest tak, że wśród załogi mamy seniorów, midów i juniorów. Tak działa prawie każda firma i takie są uwarunkowania rynkowe – brak ludzi do pracy. Powyższe powoduje, że będziemy mieć zespoły różnych kompetencji i prędkości. Coś jak Polska A i Polska B. Nie da się podzielić ludzi tak, aby każdy zespół miał taką samą siłę wytwórczą. Czym to się skończy? Opcji jest kilka. Ludzie zaczną się zwalniać, bo nie będą mieli szansy na rozwój (nie będzie od kogo się uczyć). Zespoły „gorsze” będą dostawały mniej atrakcyjne tematy albo zadania dotyczące utrzymania. Ostatnia z wielu opcji, mimo formalnego podziału na zespoły, dalej będziemy działać w nieformalnych zespołach 8 osobowych, tracąc czas na wydarzenia w mniejszym gronie.
Analizując możliwość stworzenia zespołów 4-osobowych wyobrażam to sobie tak:
- 1 programista, 1 analityk, 2 testerów, albo
- 2 programistów, 1 analityk, 1 tester, albo
- 1 programista, 2 analityków, 1 testera
Istnieje skończona liczba konfiguracji, zwróćcie proszę uwagę, że każda z nich jest problematyczna. Posiadając jednego programistę nie mam z kim skonsultować wymyślonego przez siebie rozwiązania, nie ma mi kto zrobić np. Code Review. Jasne, można szukać pomocy na zewnątrz, ale uwaga, mamy zależności.
„Czy będzie ktoś, kto zrobi mi to Code Review?”
„Czy będzie miał czas dla 'mojego’ zespołu?”
Jeśli mamy dwóch programistów, to mamy jednego analityka (czy da radę wyprodukować tyle materiału, żeby mieli co dewelopować) i testera (przepis na wąskie gardło w testach lub niską ich jakość). Każdy z tych wariantów ma jakiś defekt. Ludzi jest po prostu za mało! Czy zwiększenie liczby członków zespoły do 5 osób pomoże? Może pomóc, ale nie ma gwarancji, że tak właśnie będzie.
A może chodzi o kontrolę? Mniejsze zespoły łatwiej kontrolować, rozliczać, nadzorować, mieć nad nimi pieczę. Czy jednak o to chodzi w zwinnym podejściu? Czy nie powinno być tak, że to właśnie odpowiednio dobrany zespół sam będzie siebie regulował? Tak chyba powinno być, mamy wtedy pewność, że właściwe decyzje, najlepsze dla zespołu podejmują właściwe osoby. I będą czuły tego konsekwencje.
