Forum Scrum

Empiryzm twierdzi, że wiedza pochodzi z doświadczenia i podejmowania decyzji na podstawie tego, co jest znane.

Posiadanie więcej niż dziewięciu członków wymaga zbyt dużej koordynacji. Duże Zespoły Deweloperskie generują zbyt dużą złożoność, aby proces empiryczny mógł nimi zarządzać

Przewodnik Scrum przytacza te problemy, które są obecne w zespołach powyżej 9 członków. To są obawy, a nie punkty załamania, a zespół Scrum składający się z więcej niż 15 członków może działać. Jednakże nie będzie on tak efektywny jak zespół o odpowiedniej wielkości. Idealnie byłoby rozdzielić je na dwa zespoły i postępować zgodnie z Przewodnikiem Nexusa dotyczącym skalowania Scruma do wielu zespołów. To jest metoda Scrum.org na skalowanie Scruma. Możesz również przyjrzeć się SAFe, jako drugiej metodzie skalowania zwinnego.

Największym problemem, jaki znajdziesz, prawdopodobnie nie jest praca, ale wydarzenia. Utrzymanie czasu Daily Scrum w granicach 15 minut może być wyzwaniem przy 7 osobach, a podwojenie wielkości zespołu sprawia, że jest to o wiele trudniejsze. Rozszerzenie pola czasowego jest nie-go (po 15 minutach, zaczynasz tracić korzyści ze spotkania „stand up”), i będziesz musiał lepiej przygotować się do innych wydarzeń, wyjaśniając rzeczy z wyprzedzeniem.

Jak rozumiem, twoja praca jako Scrum Master w tym scenariuszu staje się trudniejsza, ale nie niemożliwa. Możesz mieć 15-osobowy Zespół Scrumowy, ale ponieważ wydarzenia są oparte na długości sprintu, a nie na wielkości zespołu, znajdziesz się mniej w roli służebnej, a bardziej w roli lidera. Musisz się dodatkowo skupić na tym, aby wszystko było zrobione efektywnie, ponieważ masz mniej miejsca (i mniej czasu) w swoim harmonogramie jako margines błędu. Ktoś, kto zbacza z kursu, będzie miał większy wpływ na duży zespół niż na mały.

.