Scrum Forum

Empirismul afirmă că cunoștințele provin din experiență și din luarea deciziilor pe baza a ceea ce se știe.

Având mai mult de nouă membri necesită prea multă coordonare. Echipele mari de dezvoltare generează prea multă complexitate pentru ca un proces empiric să poată fi gestionat

Ghidul Scrum citează aceste probleme ca fiind prezente în echipele de peste 9 membri. Acestea sunt preocupări, nu puncte de eșec, iar o echipă Scrum cu mai mult de 15 membri poate funcționa. Cu toate acestea, nu va fi la fel de eficientă ca o echipă de dimensiuni corespunzătoare. Ideal ar fi să îi separați în două echipe și să urmați Ghidul Nexus pentru extinderea Scrum la mai multe echipe. Aceasta este metoda Scrum.org pentru scalarea Scrum. Ați putea, de asemenea, să vă uitați la SAFe, ca o a doua metodă pentru scalarea agile.

Cea mai mare problemă pe care o veți găsi probabil nu este forța de muncă, ci evenimentele. Menținerea unui timp de Scrum zilnic boxat la 15 minute poate fi o provocare cu 7 persoane, iar dublarea acestei dimensiuni a echipei face acest lucru mult mai dificil. Extinderea intervalului de timp nu este o soluție (după 15 minute, începeți să pierdeți beneficiile unei întâlniri „stand up”) și va trebui să vă pregătiți mai bine pentru celelalte evenimente, clarificând lucrurile în avans.

După cum înțeleg eu, munca dvs. ca Scrum Master în acest scenariu devine mai dificilă, dar nu imposibilă. Poți avea o echipă Scrum de 15 oameni, dar deoarece evenimentele se bazează pe durata sprintului și nu pe mărimea echipei, te vei regăsi mai puțin în rolul de servitor și mai mult în cel de lider. Trebuie să vă concentrați mai mult pentru a vă asigura că lucrurile sunt făcute eficient, deoarece aveți mai puțin loc (și mai puțin timp) în programul dvs. ca marjă de eroare. Cineva care pleacă pe o tangentă va avea un impact mai profund asupra unei echipe mari decât asupra uneia mici.

.