Jak dobrać wielkość zespołu? 

Kiedy musimy zrobić coś w kilka osób, to zawsze pojawią się problemy z komunikacją, nieporozumienia i brak zgrania chociażby w stylu czy sposobie pracy. Wraz z nimi pojawi się także pytanie: jak dobrać wielkość zespołu, żeby nam to nie przeszkadzało?

Dlaczego zespół?

Gdy możemy coś zrobić sami – robimy to sami. Jest wiele sytuacji, w których takie rozwiązanie sprawdza się najlepiej. Nie musimy wtedy nikomu nic tłumaczyć, a jeśli posiadamy odpowiednie kwalifikacje, to wszystko będzie zrobione dokładnie tak, jak tego chcemy.

Jeśli jednak nie posiadamy wszystkich niezbędnych umiejętności, gdy zadanie wymaga synchronizacji wielu osób lub gdy chcemy je zrobić szybciej – wtedy tworzymy odpowiedniej wielkości zespół. Co niestety łatwiej powiedzieć, niż zrobić

„Project Manager to ktoś, komu wydaje się, że dziewięć kobiet urodzi jedno dziecko w miesiąc.” – stare informatyczne porzekadło

Pamiętajmy, że więcej ludzi, to nie zawsze znaczy szybciej! W tym miejscu zwykle pada przykład kopania studni, gdzie więcej osób tak naprawdę niekoniecznie podniesie tempo prac, bo nie dla każdej pary rąk znajdzie się zajęcie. Tak samo ręczne składanie zegarków wymaga dwóch rąk jednego zegarmistrza i tego procesu nijak nie przyspieszymy.

Na drugim krańcu spektrum znajduje się np. sprzątanie śmieci z plaży. Tutaj sprawa jest prosta – im więcej ludzi, tym szybciej te zadanie zostanie wykonane. Jest to doskonały przykład pracy idealnie skalowalnej.

Niestety, większość naszych zajęć, w tym tworzenie oprogramowania, znajduje się gdzieś pomiędzy tymi dwiema skrajnościami.

Wielkość Zespołu Scrumowego

Zanim zaczniemy rozpatrywać Zespół Scrumowy i jego kompetencje, warto zastanowić się, jakiej powinien być wielkości. Scrum Guide wyraźnie mówi, że Zespół Deweloperski powinien liczyć od trzech do dziewięciu osób, a więc zawierający go Scrum Team – od czterech (osobny Product Owner, Scrum Master jako członek zespołu) do jedenastu (zarówno PO jak i SM poza Zespołem Deweloperskim).

„There is plenty of data to show that team sizes over 7 result in significantly lower productivity. Any team over 7 in size should be split up into multiple SCRUMs.” – Jeff Sutherland

Nic nie jest jednak takie proste. Jeff Sutherland, jeden z twórców Scruma, otwarcie mówi, że wielkość zespołu nie powinna przekroczyć siedmiu osób. Każde osiem osób powinno zostać podzielone na dwa odrębne zespoły.

Skąd taka różnica pomiędzy wizją Jeffa Sutherlanda, a tym co zostało zawarte w Scrum Guide? Dlaczego wspomina on o „mnogości danych sugerujących, że zespoły większe niż siedem osób skutkują zauważalnie niższą produktywnością”?

Efekt Ringelmanna

Bardzo często w naszych tekstach i filmach odwołujemy się do ludzkiej natury. Każdym z nas rządzą podobne mechanizmy, których w długim terminie nie da się oszukać. Jednym z takich mechanizmów jest efekt Ringelmanna.

Maksymilian Ringelmann na początku XX wieku badał zależność pomiędzy wielkością grupy, a wkładem poszczególnych osób w wykonywaną pracę. Okazało się, że z każdą kolejną osobą wydajność i skuteczność wszystkich współpracujących spada.

Przypisywane jest to dwóm czynnikom: spadkowi motywacji oraz spadkowi koordynacji. Ten pierwszy wynika z mniejszego poczucia przydatności (zasługi się rozmywają), zmniejszonej identyfikowalności poszczególnych osób (leniwe osoby mogą się ukryć pomiędzy pracowitymi), rozmytymi celami (nie każdy identyfikuje się z celem grupy) i brakiem zaangażowania.

Spadek koordynacji wynika bezpośrednio z liczby ścieżek komunikacyjnych pomiędzy osobami. Dla pięcioosobowego zespołu jest ich dziesięć, dla siedmioosobowego – dwadzieścia jeden, a przy dwunastu będzie ich aż 66. Nie ma szans, żeby przy większych zespołach wszyscy wiedzieli o wszystkim. To powoduje nieporozumienia i spadki w koordynacji.

Demonstracją efektu Ringelmanna jest badanie, w którym uczestnicy wykonywali fizyczną pracę (przeciąganie liny) w grupach o różnej liczności. Niezależnie od jakości współpracy i tego czy uczestnicy byli prawdziwi, czy byli to badacze udający wysiłek, osoby poddawane testom tym mniej wkładały siły, im więcej było osób.

Gdy się nad tym chwilę zastanowimy, to nie powinno być w tym nic dziwnego.

Idealna wielkość zespołu

Jeff Bezos, twórca Amazona, zwykł mawiać, że każdy zespół i każdą grupę roboczą powinno dać się nakarmić dwiema pizzami. To sugeruje liczność w okolicy 4-8 osób. Oczywiście, zależy to od wielkości pizzy i pojemności żołądków, ale na pewno nie miał on na myśli kilkunastoosobowych, nieefektywnych potworków.

Często cytowane badanie Hackmana i Vidmara z 1970 roku mówi o odczuciach samych członków zespołu związanych z pracą w grupach różnej wielkości. Analizując odpowiedzi sugerujące, że zespół jest zbyt duży albo zbyt mały, określili „idealną wielkość zespołu” na 4.6 osób. Humanizując ten wynik powiedzielibyśmy, że grupa powinna mieć około 5 osób.

Z kolei dane analizowane przez Larry’ego Maccherone wspominały zaś, że zespoły liczące od 1 do 3 osób są najbardziej produktywne, ale efekty ich pracy są niższej jakości niż grup liczących 3-5 i 5-9. Te przedostatnie też były najbardziej produktywne.

Jaki zespół zbudować?

Przede wszystkim musimy pamiętać, żeby zespół posiadał wszystkie kompetencje niezbędne do wykonania powierzonej mu pracy. To bardzo ważny slogan, bo podkreśla on powód budowania zespołu – chcemy poprawnie i efektywnie zrealizować jakieś zadanie, działając w grupie.

Po zaznajomieniu się z literaturą i badaniami, zapytany o idealną wielkość zespołu, zasugerowałbym, żeby zespół składał się z minimalnej liczby osób, które są absolutnie niezbędne do osiągnięcia zamierzonego celu. Idealnie byłoby, gdybyśmy zmieścili się w pięciu osobach.

Jeśli zaś okazuje się, że tak stworzony zespół zawiera więcej osób niż siedem, to koniecznie należy przemyśleć inny podział pracy. Sugerowana przez Scrum Guide wielkość zespołu to tylko sugestia – im mniej, tym lepiej. Być może wcale nie potrzebujemy kompetencji z dziesięciu różnych obszarów i czternastu odrębnych aplikacji w jednym Zespole Scrumowym.

Ale skalowanie metodyk zwinnych to temat na zupełnie inny tekst.