Zbyt duży, by skalować – Przewodnik po optymalnym rozmiarze zespołu Scrum

Posłuchaj wersji audio tego artykułu

Niezależnie od tego, czy pracujesz w małym startupie, czy nad nowym produktem w dużej firmie, prawdopodobnie dojdziesz do punktu, w którym masz zbyt wiele osób w jednym zespole. Wczesne rozpoznanie znaków uchroni Cię przed dotarciem do najbardziej nieefektywnego etapu zespołu.

Każdy produkt jest inny, podobnie jak pracujące nad nim zespoły. W związku z tym podział zespołu będzie również wymagał podjęcia pewnych decyzji, które odzwierciedlają okoliczności. Niektóre rzeczy do rozważenia to:

• Jak zachować integralność know-how, gdy koledzy z zespołu nie współpracują już ze sobą?
• Czy należy podzielić funkcje (np. zespoły front-end i back-end)?
• Czy nowe zespoły powinny mieć osobne zaległości?
• Czy zespół zarządzający produktem powinien odpowiednio się rozwijać?

Kiedy powinieneś zacząć tworzyć drugi zespół?

Najbardziej oczywistą wskazówką do rozpoczęcia myślenia o podziale zespołu lub dodaniu nowego zespołu jest zwiększenie budżetu. Może to nastąpić w przypadku nowej rundy inwestycyjnej w startup lub nowych celów dla Twojego produktu w przedsiębiorstwie. Jeśli wzrost budżetu jest tak znaczny, że Twój zespół powiększy się 3x lub więcej, to oczywiste, że będziesz musiał podzielić swój obecny zespół, aby rozpowszechniać know-how. Jednak decyzje nie są tak jednoznaczne, gdy zwiększanie budżetu jest stopniowe i kończy się dodaniem kilku nowych osób do listy. Jeśli, powiedzmy, planujesz powiększyć swój zespół z 7 do 11 osób, czy to wymaga podziału? Agile promuje małe zespoły, ale promuje również osoby i interakcje ponad procesy i narzędzia. Posiadanie dwóch lub więcej zespołów nieuchronnie tworzy więcej procesów, aby móc pracować w synchronizacji.

Co mówią eksperci?

Jeff Bezos, założyciel Amazona, stosuje zasadę dwóch pizzy zarówno w przypadku spotkań, jak i zespołów. Oznacza to, że każdy powinien mieć tylko tyle osób, ile dwie pizze mogą wyżywić podczas lunchu.

Przewodnik Scrum sugeruje, aby mieć od trzech do dziewięciu członków zespołu, którzy faktycznie wykonują backlog sprintu. Oznacza to, że nie uwzględnisz właściciela produktu lub mistrza scrum w sumie, chyba że którykolwiek z nich wdraża elementy backlogu sprintu.

Te liczby wydają się mieć intuicyjny sens, ale kryje się za nimi również trochę matematyki. Jeśli myślisz o zespole, każda osoba jest jak węzeł i łączy się z innymi węzłami. Są to relacje interpersonalne między kolegami z drużyny. Mogą być przyjazne, konkurencyjne, złośliwe lub opiekuńcze. Niezależnie od relacji między dwojgiem ludzi, nadal jest to połączenie, które wymaga od każdej osoby pewnych zdolności umysłowych. Wraz ze wzrostem zespołu liczba tych linków nie rośnie liniowo. Wzór na połączenia między węzłami to \(n(n-1)/2\). Oto wykres wzrostu linków:

Wykres wyraźnie ilustruje z matematycznego punktu widzenia, dlaczego zespoły działają najefektywniej, gdy nie są zbyt duże. Jeśli weźmiemy od 3 do 9 członków zespołu sugerowanych przez Przewodnik Scrum, otrzymamy od 3 do 36 linków. Gdybyśmy dorośli do 15 osób, mielibyśmy ponad 100 linków. Taki zespół mógłby działać sprawnie tylko wtedy, gdyby jego obowiązki były bardzo dobrze określone i rzadko się pokrywały lub gdyby istniały nieoficjalne podgrupy. Nie jest to również przypadek ani pożądane, gdy pracujesz w oparciu o zasady Agile.

Oznaki, że zespół staje się za duży

Codzienny Scrum

Czasem nazywany codziennym standupem, codzienny scrum jest spotkaniem całego zespołu w celu omówienia postępów i utrudnień w sprincie. Przewodnik Scrum sugeruje, aby odmierzać czas na 15 minut i jest to dobry papierek lakmusowy dla wielkości zespołu. Jeśli zaczniesz zauważać, że Twój zespół przekracza 15-minutowy pasek, może to oznaczać jedną z dwóch rzeczy:

• Codzienne scrumy nie są wydajne. Ludzie wchodzą w zbyt wiele szczegółów. Albo nie ma jasnego porządku mówienia i zabranie głosu przez członków zespołu zajmuje trochę czasu. Być może właściciel produktu lub scrum master wykorzystuje codzienny scrum jako okazję do dostarczania różnych aktualizacji niezwiązanych ze sprintem.
• Zespół jest za duży. Jeśli codzienne scrumy są skuteczne, ale nadal przekraczasz 15 minut, możesz po prostu mieć zbyt wiele osób w zespole. Powinieneś również zacząć zauważać, że ludzie tracą zainteresowanie, ponieważ istnieje limit informacji, które dana osoba może przyjąć. Jeśli zbyt wiele osób dostarcza aktualizacje, trudno jest śledzić postępy wszystkich i rozumieć stan zespołu . To sprawia, że ​​ludzie zwracają się do wewnątrz i zastanawiają się tylko nad swoimi postępami, zamiast szukać możliwości pomocy innym.

Pielęgnacja i planowanie sprintu

Zarówno grooming, jak i planowanie sprintu to czynności związane z dzieleniem historyjek użytkowników i szacowaniem czasu ich dostarczenia lub rozmiaru. Chociaż posiadanie większej liczby osób może pomóc zespołowi w podejmowaniu lepszych decyzji, posiadanie zbyt wielu osób może doprowadzić zespół do impasu. Zawsze istnieją różne sposoby na wykonanie tego samego zadania, a liczba argumentów po każdej stronie rośnie wraz z liczbą osób w zespole.

Podobnie jak w przypadku codziennego scrum, nie pomyl nieefektywnej sesji planowania ze zbyt dużym zespołem. Ostatecznie zadaniem mistrza scrum jest sprawienie, aby ceremonie scrum były wydajne i efektywne.

Z mocą wsteczną

Podczas retrospektywy członkowie zespołu mogą rozwiązywać wszelkie spory lub konflikty i wymyślać sposoby usprawnienia swojego procesu pracy. Retrospektywy uczą nas sztuki kompromisu, ponieważ pozwalają szukać wspólnej płaszczyzny między różnymi partiami. Zespół jest tak potężny, jak jego członkowie są gotowi iść na kompromis w kwestii różnic.

Jednak, podobnie jak w przypadku planowania sprintu, zbyt wielu członków zespołu tworzy zbyt wiele powiązań, z których wszystkie są potencjalnymi punktami konfliktu. Zacznij zauważać, czy podczas retrospekcji znajdujesz coraz mniej wspólnej płaszczyzny. Może to oznaczać, że zespół jest zbyt duży i skorzystałby na podziale.

Jak podzielić zespół

Na pierwszy rzut oka rozdzielenie zespołu jest stosunkowo łatwym zadaniem. Podziel członków zespołu na dwie grupy, upewnij się, że każda ma podobnie doświadczonych ludzi i zdefiniuj cele dla nowych zespołów. Jest jednak kilka rzeczy do rozważenia, które mogą mieć duży wpływ na przyszły sukces nowych zespołów.

Morale zespołu

Prawdopodobnie jedną z najważniejszych rzeczy, o których należy pamiętać, jest morale zespołu. Ostatecznie to ludzie w zespole będą musieli pracować w nowym składzie. Jeśli zespół jest dojrzały pod względem zasad Agile, powinien być w stanie samodzielnie dokonać podziału. Jest to najbardziej pożądany wynik, ponieważ członkowie zespołu najlepiej znają swoje wewnętrzne relacje — kto z kim najlepiej współpracuje i kto mógłby skorzystać na byciu w oddzielnych zespołach.

Zespoły wielofunkcyjne

Scrum promuje zespoły wielofunkcyjne „ze wszystkimi umiejętnościami zespołu niezbędnymi do stworzenia przyrostu produktu”. Dotyczy to skalowania do dwóch lub więcej zespołów. Dla wielu programistów, zwłaszcza jeśli są nowicjuszami w Agile, naturalną tendencją jest myślenie wzdłuż linii technicznych. Na przykład zespoły często chcą podzielić się na zespoły back-end i front-end. Może to mieć sens w niektórych rzadkich przypadkach, ale jako menedżer produktu powinieneś odradzać to przez większość czasu. Zespół pełen front-enderów nie jest w stanie samodzielnie dostarczyć przyrostu produktu i naturalnie zacznie bardziej myśleć o możliwościach technicznych, które go łączą. Zamiast tego powinni skupić się na kliencie i sposobie zaspokojenia jego potrzeb.

Inną interesującą kwestią są role niezwiązane z rozwojem w zespole. W różnych sytuacjach zespół może obejmować projektanta, analityka biznesowego lub specjalistę ds. kontroli jakości. Po podzieleniu zespołu, zwłaszcza jeśli nie zatrudniasz zbyt wielu nowych osób, pojawia się dylemat, co zrobić z tymi rolami. Czy powinni podzielić swój czas między zespoły? Czy powinieneś zatrudnić nowe osoby, które byłyby oddane tylko jednemu zespołowi? Czy powinni współpracować z zespołami programistycznymi, czy być częścią zespołu produktowego?

Naprawdę nie ma jednej dobrej porady, ponieważ każdy produkt jest inny. Decyzje te najlepiej podejmować wspólnie z zespołem, pamiętając, że po drodze może być konieczna korekta kursu.

Czy zespoły powinny mieć oddzielne zaległości?

Jeśli zespół jest podzielony, naturalnym pytaniem jest, czy powinni pracować nad tymi samymi zaległościami, czy mieć osobne. W celu uzyskania wskazówek możemy zajrzeć do Scaled Agile Framework.

Scrum@Skala

Scrum@Scale to metodologia opracowana przez twórcę Przewodnika Scrum. Scrum@Scale nie jest zbyt nakazowy i nie opisuje szczegółowo, jak radzić sobie z zaległościami produktowymi. Odnotowuje jednak dwa punkty:

• Proces na poziomie zespołu jest taki sam, jak opisany w Przewodniku Scrum.
• Właściciele produktów tworzą zespół właścicieli produktów, w którym tworzą jeden ujednolicony backlog. Ma to na celu uniknięcie powielania pracy i stworzenie widoczności w firmie. Jednocześnie zespoły mają osobne rejestry, które zasilają elementy z ujednoliconego rejestru.

Zasadniczo Scrum@Scale obrazuje nowe zespoły z ich własnymi PO i zaległościami. Po prostu dodaje kilka dodatkowych struktur, aby koordynować pracę między zespołami. Scrum@Scale działa najlepiej z kilkoma, dziesiątkami lub setkami zespołów, ale może dostarczyć cennych informacji, nawet jeśli pracujesz z dwoma zespołami.

Scrum na dużą skalę (LeSS)

LeSS promuje ciekawe podejście do backlogu produktu. W LeSS właściciel produktu współpracuje z dwoma do ośmiu zespołami. Może wydawać się niemożliwe, aby jeden OP współpracował z tak wieloma zespołami. Filozofia LeSS polega na tym, że PO działa na poziomie abstrakcyjnym i przekazuje zespołom obowiązki związane z udoskonalaniem pozycji zaległości produktu. W takim przypadku międzyfunkcyjne zespoły programistyczne powinny również obejmować wiedzę z dziedziny biznesowej, aby móc dostarczyć przyrost produktu. W LeSS istnieje tylko jeden zaległości.

Jak być na bieżąco

Dla menedżera produktu wiele zespołów oznacza więcej pracy polegającej na śledzeniu postępów i odpowiadaniu na zapytania.

Priorytetowe spotkania

Jeśli uczestniczyłeś w codziennych scrumach jednego zespołu, kontynuowanie tego nawyku najprawdopodobniej będzie bezproduktywne. Potraktuj codzienne scrumy jako okazję do wpadnięcia, aby uzyskać puls zespołów i przypomnieć im, że jesteś dostępny do dyskusji.

Twoja obecność w sesjach planowania sprintu będzie zależeć od dojrzałości zespołów. Jeśli w zespołach jest dużo świeżych twarzy lub nie współpracowały z Agile od dłuższego czasu, konieczne będą pewne wskazówki z Twojej strony. Nawet jeśli czujesz się pewnie, pozwalając zespołowi planować bez Twojej obecności, upewnij się, że możesz wpaść lub porozmawiać z zespołem na czacie głosowym podczas planowania, jeśli pojawią się jakiekolwiek pytania.

Przeglądy sprintów będą musiały pozostać twoim najwyższym priorytetem i wszystkie z nich powinny być brane pod uwagę. Przeglądy sprintów to szansa na uzyskanie opinii z pierwszej ręki od wszystkich obecnych interesariuszy i samego zespołu. To czas, w którym założenia są walidowane i nie można ich przegapić.

Zaangażuj więcej ze Scrum Masterami

Chociaż możesz zmniejszać swoje zaangażowanie w niektóre ceremonie scrumowe, powinieneś podwoić swoją współpracę z mistrzem scrum. Po podziale zespołu może być więcej niż jeden, w takim przypadku będziesz musiał ściśle współpracować z nimi wszystkimi.

Upewnij się, że możesz im ufać, że przedstawią rzetelny obraz postępów zespołu i wszelkich problemów pojawiających się podczas sprintów. Te relacje pozwolą Ci być na bieżąco bez konieczności angażowania się we wszystkie ceremonie scrumowe.

Przedstaw Scrum Scrum

Czasami nazywany meta scrum, scrum of scrum to nowa ceremonia, która jest zwykle wprowadzana jako skala procesów scrum. Jest repliką codziennego scrum na wyższym poziomie. Każdy zespół wyznacza ambasadora, z którego wszyscy spotykają się codziennie na forum scrum, aby omówić postępy i przeszkody. Ta ceremonia służy również do podkreślenia wszelkich problemów technicznych między zespołami, które mogą wymagać rozwiązania.

Rozważ poszerzenie zespołu produktowego

Jeśli konfiguracja Scrum wymaga aktywnego zaangażowania menedżera produktu w zespół, rozważ dodanie większej liczby osób po stronie produktu. Istnieje kilka sposobów podejścia do tego.

Młodsi menedżerowie produktu. Jednym ze sposobów jest przyjęcie dla siebie bardziej strategicznej roli, przy jednoczesnym dodaniu młodszych menedżerów produktu do wykonywania niektórych codziennych obowiązków. Mogliby podjąć się niektórych zadań, takich jak zapewnienie jakości (QA), pisanie specyfikacji dla historyjek użytkownika lub tworzenie makiet wysokiego poziomu dla nowych funkcji.

Analitycy biznesowi. Innym sposobem jest zatrudnienie jednego lub więcej analityków biznesowych w zespołach lub obok nich. Menedżer produktu może współpracować z analitykami biznesowymi, aby zidentyfikować założenia dotyczące produktu, a następnie pozwolić analitykom biznesowym na znalezienie sposobów ich weryfikacji poprzez badania lub nowe funkcje.

Wniosek

Wraz z rozwojem zespołu prawdopodobnie zaczniesz zauważać pewne oznaki, że staje się zbyt duży, zwłaszcza w:

• Codzienny scrum. Jeśli przekraczasz 15-minutowe ramy czasowe podczas codziennych scrumów i widzisz, że ludzie zaczynają tracić zainteresowanie.
• Planowanie sprintu. Jeśli coraz częściej wpadasz w impas podczas planowania sprintów.
• Z mocą wsteczną. Jeśli zaczniesz zauważać, że podczas retrospektyw coraz trudniej jest osiągać kompromisy.

Wszystko to wskazuje na to, że być może będziesz musiał podzielić zespół. Podział zespołu jest pozornie łatwym zadaniem, ale ma też trwałe konsekwencje, a każdy menedżer produktu musi wziąć pod uwagę kilka rzeczy:

• Morale zespołu. Najlepiej byłoby pozwolić zespołowi zdecydować, w jaki sposób chce się podzielić, aby zminimalizować liczbę zerwanych dobrych relacji roboczych.
• Zespoły wielofunkcyjne. Zespoły powinny posiadać wszystkie umiejętności niezbędne do stworzenia przyrostu produktu.
• Rejestr produktów. Zdecyduj, czy Twoje zespoły będą miały osobny, czy jeden ujednolicony rejestr.

Śledzenie dwóch lub więcej drużyn będzie wymagało ustalenia priorytetów. Skuteczny menedżer produktu powinien zaplanować, w jaki sposób będzie na bieżąco z nowymi zespołami:

• Priorytetowe spotkania. Zastanów się, które ceremonie Agile są warte twojego czasu, a które można zignorować.
• Współpracuj z mistrzami scrum. Używaj scrum masterów jako pełnomocników zespołu i zbieraj od nich informacje.
• Rozwiń zespół produktowy. Dodaj ludzi do współpracy i pomagaj w codziennych powtarzalnych zadaniach lub przeprowadzaj badania użytkowników i analizy rynku.

Korzystając z tych sugestii, powinieneś być w stanie uzyskać czysty podział zespołu. Jeśli Twoje zespoły wciąż się rozwijają i w przyszłości będziesz dodawać jeszcze więcej zespołów, powinieneś przeczytać o Scaled Agile Framework, która zawiera sugestie dotyczące struktury i procesów Agile na dużą skalę.