Prea mare pentru a fi la scară – Ghid de dimensiune optimă a echipei Scrum

Ascultă versiunea audio a acestui articol

Indiferent dacă lucrați într-un mic startup sau la un produs nou într-o companie mare, este posibil să ajungeți într-un punct în care aveți prea mulți oameni într-o echipă. Identificarea devreme a semnelor te va scuti de a ajunge la cel mai ineficient stadiu al echipei.

Fiecare produs este diferit, la fel și echipele care lucrează la el. Astfel, împărțirea unei echipe va necesita, de asemenea, să luați unele decizii care reflectă circumstanțele dvs. Câteva lucruri de luat în considerare sunt:

• Cum să menții integritatea know-how-ului atunci când colegii de echipă nu mai lucrează împreună
• Ar trebui să împărțiți funcții (de exemplu, echipe front-end și back-end)?
• Ar trebui noile echipe să aibă restanțe separate?
• Ar trebui echipa de management de produs să crească în consecință?

Când ar trebui să începi să creezi o a doua echipă?

Cel mai evident indiciu pentru a începe să vă gândiți la o împărțire a echipei sau la adăugarea unei noi echipe este atunci când bugetul dvs. crește. Acest lucru se poate întâmpla la o nouă rundă de investiții într-un startup sau la noi obiective pentru produsul dvs. într-o întreprindere. Dacă creșterea bugetului este atât de substanțială încât echipa ta va crește de 3 ori sau mai mult, atunci este deloc o idee că va trebui să-ți împărțiți echipa actuală pentru a distribui know-how-ul. Cu toate acestea, deciziile nu devin atât de clare atunci când creșterea bugetului este progresivă și ajungi să adaugi câțiva oameni noi la listă. Dacă, să zicem, aveți planuri de a vă crește echipa de la 7 la 11 oameni, este nevoie de o divizare? Agile promovează echipele mici, dar promovează și indivizii și interacțiunile peste procese și instrumente. A avea două sau mai multe echipe creează inevitabil mai multe procese pentru a putea lucra în sincronizare.

Ce spun experții?

Jeff Bezos, fondatorul Amazon, a folosit regula celor două pizza atât pentru întâlniri, cât și pentru echipe. Asta înseamnă că fiecare ar trebui să aibă doar atât de mulți oameni câte două pizza pot hrăni la prânz.

Ghidul Scrum sugerează să existe între trei și nouă membri ai echipei care execută de fapt stocul de sprint. Asta înseamnă că nu veți include proprietarul produsului sau Scrum Master în total, decât dacă unul dintre ei implementează elementele de sprint backlog.

Aceste numere par să aibă sens intuitiv, dar există și o anumită matematică în spatele lor. Dacă te gândești la o echipă, fiecare persoană este ca un nod și se conectează la alte noduri. Acestea sunt relațiile interpersonale dintre colegii de echipă. Pot fi prietenoși, competitivi, plini de răutate sau grijulii. Oricare ar fi relația dintre doi oameni, ea rămâne o legătură care necesită o anumită capacitate mentală din partea fiecărei persoane. Pe măsură ce o echipă crește, numărul acestor legături nu crește liniar. Formula pentru legăturile dintre noduri este \(n(n-1)/2\). Iată diagrama de creștere a linkurilor:

Graficul ilustrează clar din punct de vedere matematic de ce echipele funcționează cel mai eficient atunci când nu sunt prea mari. Dacă luăm cei 3 până la 9 membri ai echipei sugerați de Scrum Guide, ajungem să avem între 3 și 36 de link-uri. Dacă am crește la 15 persoane, am avea peste 100 de link-uri. O echipă a acestuia ar putea funcționa eficient doar dacă sarcinile lor erau foarte bine definite și rar se suprapuneau sau dacă existau câteva subgrupuri neoficiale. Nici nu este cazul sau nu se dorește atunci când se lucrează pe principii Agile.

Semne că echipa devine prea mare

Scrum zilnic

Denumit uneori standup-ul zilnic, scrumul zilnic este o întâlnire a întregii echipe pentru a discuta despre progresul și impedimentele sprintului. Ghidul Scrum sugerează să cronometreze acestea la 15 minute și acesta este un bun test de turnesol pentru dimensiunea echipei. Dacă începi să observi că echipa ta depășește bara de 15 minute, atunci poate indica unul dintre două lucruri:

• Scrumurile zilnice nu sunt eficiente. Oamenii intră în prea multe detalii. Sau nu există o ordine clară a vorbirii și este nevoie de timp pentru ca colegii de echipă să vorbească. Poate că proprietarul produsului sau maestrul scrumului folosește scrumul zilnic ca o oportunitate de a oferi diverse actualizări care nu au legătură cu sprintul.
• Echipa este prea mare. Dacă scrumurile zilnice sunt eficiente, dar încă depășești cele 15 minute, atunci s-ar putea să ai pur și simplu prea mulți oameni în echipă. De asemenea, ar trebui să începeți să observați că oamenii își pierd interesul, deoarece există o limită a cantității de informații pe care o persoană poate prelua. Dacă prea mulți oameni oferă actualizări, devine greu să urmăriți progresul tuturor și să înțelegeți starea echipei. . Acest lucru îi face pe oameni să se întoarcă spre interior și să reflecteze doar asupra progresului lor, mai degrabă decât să caute oportunități de a-i ajuta pe alții.

Grooming și Sprint Planning

Atât îngrijirea, cât și planificarea sprintului sunt activități legate de defalcarea poveștilor utilizatorilor și de estimarea timpului sau mărimii lor de livrare. Deși ai mai mulți oameni poate ajuta echipa să ia decizii mai bune, a avea prea mulți oameni ar putea duce echipa într-un impas. Există întotdeauna modalități diferite de a îndeplini aceeași sarcină și numărul de argumente de fiecare parte crește odată cu numărul de oameni din echipă.

Ca și în cazul scrumului zilnic, nu confundați o sesiune de planificare ineficientă cu echipa prea mare. În cele din urmă, este datoria maestrului scrum să facă ca ceremoniile de scrum să fie eficiente și eficiente.

Retrospectiv

În timpul unei retrospective, membrii echipei pot rezolva orice argumente sau conflicte și pot găsi modalități de a-și îmbunătăți procesul de lucru. Retrospectivele ne învață arta compromisului, deoarece ne face să căutăm un teren comun între diferite părți. O echipă este la fel de puternică pe cât sunt dispuși membrii săi să facă compromisuri cu privire la diferențele lor.

Cu toate acestea, ca și în cazul planificării sprintului, prea mulți membri ai echipei creează prea multe legături, toate acestea fiind puncte potențiale de conflict. Începeți să observați dacă găsiți un teren din ce în ce mai puțin comun în timpul retrospectivelor. Poate fi un semn că echipa este prea mare și ar avea de câștigat de a fi împărțită.

Cum să împărțiți echipa

Pe față, împărțirea echipei este o sarcină relativ ușoară. Împărțiți membrii echipei în două grupuri, asigurați-vă că fiecare are oameni cu experiență similară și definiți obiectivele noilor echipe. Cu toate acestea, există destul de multe lucruri de luat în considerare care ar putea avea un impact mare asupra succesului viitor al noilor echipe.

Moralul echipei

Probabil că unul dintre cele mai importante lucruri de reținut este moralul echipei. La sfârșitul zilei, oamenii din echipă sunt cei care vor trebui să lucreze în noua compoziție. Dacă echipa este matură în ceea ce privește principiile Agile, atunci ar trebui să poată face ei înșiși separarea. Acesta este rezultatul cel mai de dorit, deoarece membrii echipei își cunosc cel mai bine relațiile interne - cine lucrează cel mai bine cu cine și cine ar putea beneficia de a fi în echipe separate.

Echipe multifunctionale

Scrum promovează echipe interfuncționale „cu toate abilitățile ca o echipă necesare pentru a crea o creștere a produsului”. Acest lucru este valabil atunci când scalați la două sau mai multe echipe. Pentru o mulțime de dezvoltatori, mai ales dacă sunt noi în Agile, tendința naturală este să gândească alături de linii tehnice. De exemplu, echipele doresc adesea să se împartă în echipe de back-end și front-end. Acest lucru ar putea avea sens în unele ocazii rare, dar în calitate de manager de produs, ar trebui să sfătuiți împotriva acestui lucru de cele mai multe ori. O echipă plină de interlocutori nu este capabilă să livreze un produs de sine stătător și va începe în mod natural să se gândească mai mult la capacitatea tehnică, care este ceea ce îi unește. În schimb, ar trebui să se concentreze asupra clientului și asupra modului de a-și satisface nevoile.

Un alt aspect interesant este rolurile de non-dezvoltare în echipă. În diverse situații, o echipă poate include un designer, un analist de afaceri sau un specialist în calitate. Odată ce împărțiți o echipă, mai ales dacă nu angajați prea mulți oameni noi, apare o dilemă cu privire la ce să faceți cu aceste roluri. Ar trebui să-și împartă timpul între echipe? Ar trebui să angajezi oameni noi, care s-ar dedica doar unei echipe? Ar trebui să lucreze cu echipele de dezvoltare sau să facă parte din echipa de produs?

Nu există într-adevăr un sfat unic bun pentru acest lucru, deoarece fiecare produs este atât de diferit. Aceste decizii sunt cel mai bine luate împreună cu echipa, ținând cont de faptul că ar putea fi necesar să corectați cursul pe parcurs.

Ar trebui echipele să aibă întârzieri separate?

Dacă o echipă este împărțită, atunci întrebarea naturală este dacă ar trebui să lucreze cu același întârziere sau să aibă altele separate. Ne putem uita la Scaled Agile Framework pentru îndrumare.

Scrum@Scale

Scrum@Scale este o metodologie dezvoltată de creatorul Scrum Guide. Scrum@Scale nu este foarte prescriptiv și nu descrie în mod specific cum să gestionați întârzierile de produse. Totuși, remarcă două puncte:

• Procesul la nivel de echipă este același cu cel prezentat în Ghidul Scrum.
• Proprietarii de produse formează o echipă de proprietari de produse, unde creează un singur backlog unificat. Acest lucru se face pentru a evita dublarea muncii și pentru a crea vizibilitate în cadrul companiei. În același timp, echipele au întârzieri separate care alimentează articolele din stocul unificat.

Deci, în esență, Scrum@Scale imaginează noile echipe cu propriile lor OP-uri și restante. Se adaugă doar câteva structuri suplimentare pentru a coordona munca dintre echipe. Scrum@Scale funcționează cel mai bine cu mai multe, zeci sau sute de echipe, dar poate oferi câteva informații valoroase chiar dacă lucrați cu două echipe.

Scrum la scară largă (LeSS)

LeSS promovează o abordare interesantă a stocului de produse. În LeSS, un proprietar de produs lucrează cu două până la opt echipe. Ar putea părea imposibil ca un singur OP să lucreze cu atât de multe echipe. Filozofia LeSS este că PO lucrează la un nivel abstract și deleagă echipelor responsabilitățile de rafinare a articolelor din backlog de produs. În acest caz, echipele de dezvoltare interfuncțională ar trebui să includă și cunoștințe în domeniul afacerii pentru a putea oferi o creștere a produsului. În LeSS, există un singur întârziere.

Cum să fii la curent

Pentru un manager de produs, mai multe echipe înseamnă mai multă muncă de urmărire a progresului și de răspuns la întrebări.

Prioritizează întâlnirile

Dacă ai participat la scrum-urile zilnice ale unei singure echipe, continuarea acestui obicei va fi cel mai probabil neproductivă. Luați în considerare scrumurile zilnice ca o șansă de a vă prezenta pentru a obține un puls al echipelor și a le aminti că sunteți disponibil pentru discuții.

Prezența ta la sesiunile de planificare a sprintului va depinde de maturitatea echipelor. Dacă echipele includ o mulțime de fețe proaspete sau nu au lucrat cu Agile de mult timp, atunci va fi necesară o îndrumare din partea dvs. Chiar dacă vă simțiți încrezător în a lăsa echipa să planifice fără prezența dvs., asigurați-vă că sunteți disponibil pentru a intra sau pentru a conversa vocal cu echipa în timpul planificării lor, dacă apar întrebări.

Evaluările Sprint vor trebui să rămână prioritatea ta principală și toate acestea ar trebui să fie prezente. Evaluările Sprint sunt o șansă de a obține feedback direct din partea oricăror părți interesate prezente și a echipei în sine. Este un moment în care ipotezele sunt validate și nu trebuie ratate.

Implicați-vă mai mult cu Scrum Masters

Deși s-ar putea să vă reduceți angajamentul cu unele dintre ceremoniile de scrum, ar trebui să vă dublați parteneriatul cu scrum master. S-ar putea să fie mai mult de unul acum după despărțirea echipei, caz în care, ar trebui să lucrați îndeaproape cu toți.

Asigurați-vă că aveți încredere în ei pentru a oferi o perspectivă sinceră asupra progresului echipei și a oricăror probleme care apar în timpul sprinturilor. Aceste relații te vor permite să fii la curent fără a fi nevoie să te angajezi în toate ceremoniile scrum.

Introduceți Scrum of Scrums

Uneori numită meta scrum, o scrum of scrums este o nouă ceremonie care este de obicei introdusă ca scala proceselor scrum. Este o replică a scrumului zilnic la un nivel superior. Fiecare echipă desemnează un ambasador, care se întâlnesc cu toții la scrums de scrums în fiecare zi pentru a discuta despre progres și impedimente. Această ceremonie este, de asemenea, folosită pentru a evidenția orice probleme tehnice între echipe care ar putea trebui rezolvate.

Luați în considerare extinderea echipei de produse

Dacă configurația dvs. de scrum necesită ca managerul de produs să se implice activ cu echipa, luați în considerare adăugarea mai multor persoane la partea de produs. Există câteva moduri de a aborda acest lucru.

Manageri juniori de produs. O cale este să vă asumați un rol mai strategic pentru dvs., în timp ce adăugați manageri de produs juniori care să se ocupe de unele dintre treburile zilnice. Aceștia ar putea prelua unele sarcini precum asigurarea calității (QA), scrierea specificațiilor pentru poveștile utilizatorilor sau crearea de machete la nivel înalt pentru noi funcții.

Analisti de afaceri. O altă modalitate este de a avea unul sau mai mulți analiști de afaceri să lucreze în sau alături de echipe. Managerul de produs poate lucra cu analiștii de afaceri pentru a identifica ipotezele despre produse și apoi îi poate lăsa pe analiștii de afaceri să găsească modalități de a le valida fie prin cercetare, fie prin noi funcții.

Concluzie

Pe măsură ce echipa dvs. crește, este posibil să începeți să observați câteva semne că devine prea mare, mai ales în:

• Scrum zilnic. Dacă depășiți intervalul de timp de 15 minute în timpul scrumurilor zilnice și vedeți că oamenii încep să-și piardă interesul.
• Planificarea sprintului. Dacă ajungi în impas în timpul planificării sprintului din ce în ce mai des.
• Retrospectiv. Dacă începi să observi că devine din ce în ce mai greu să ajungi la compromisuri în timpul retrospectivelor.

Toate acestea indică faptul că ar putea fi nevoie să împărțiți echipa. Împărțirea unei echipe este aparent o sarcină ușoară, dar are și consecințe de durată și fiecare manager de produs are câteva lucruri de luat în considerare atunci când face acest lucru:

• Moralul echipei. În mod ideal, ar trebui să lăsați echipa să decidă cum dorește să se despartă pentru a minimiza numărul de relații bune de lucru abandonate.
• Echipe multifunctionale. Echipele ar trebui să aibă toate abilitățile necesare pentru a crea o creștere a produsului.
• Restante produs. Decideți dacă echipele dvs. vor avea un stoc separat sau unic.

Urmărirea a două sau mai multe echipe va cere să stabiliți priorități. Un manager de produs eficient ar trebui să planifice modul în care va fi la curent cu noile echipe:

• Prioritizează întâlnirile. Gândește-te prin ce ceremonii Agile merită timpul tău și care pot fi ignorate.
• Interacționează cu maeștrii scrum. Folosiți Scrum Masters ca proxy pentru echipa dvs. și adunați informații de la ei.
• Extindeți echipa de produse. Adăugați oameni care să lucreze cu dvs. și să vă ajute fie cu sarcini repetitive zilnice, fie să efectueze cercetări despre utilizatori și analize de piață.

Folosind aceste sugestii, ar trebui să puteți avea o împărțire curată a echipei. Dacă echipele dvs. continuă să crească și veți adăuga și mai multe echipe în viitor, ar trebui să citiți despre Scaled Agile Framework, care oferă sugestii de structură și proces pentru Agile la scară.