Comparați 5 cadre de scalare agilă: pe care ar trebui să îl utilizați?

Publicat: 2022-08-18

Imaginează-ți asta: la începutul unui proiect, adunați o echipă unică, eficientă, interfuncțională de persoane angajate în atingerea obiectivelor de produs. Pentru a îmbunătăți performanța, vă asigurați că echipa este competentă în Agile. Cererea pentru produs crește, crescând cerințele și extinzând stocul. Tu și alte părți interesate realizați că echipa trebuie extinsă. Suna familiar?

Scalingul permite mai multor echipe să lucreze împreună pentru a-și menține agilitatea. Dacă există mai multă muncă de făcut decât poate face echipa ta într-o perioadă rezonabilă de timp, este timpul să se extindă. Pentru a face acest lucru, totuși, trebuie să selectați cadrul potrivit și există mai multe dintre care să alegeți. Alegeți prost și implementarea ar putea eșua, perturbând productivitatea și având repercusiuni financiare semnificative.

Cadrul cel mai potrivit pentru echipa dvs. va varia, în funcție de factori precum finanțarea disponibilă, abordarea organizațională și complexitatea produsului.

Când ar trebui să scalați?

Există o serie de criterii cheie de îndeplinit înainte de a lua în considerare scalarea:

Puteți gestiona dezvoltarea cu o singură echipă?

Implementarea cadrelor Agile scalate poate fi complexă și consumatoare de timp, așa că nu scalați dacă nu este necesar. Atunci când volumul de muncă al echipei tale depășește capacitățile sale, atunci scalarea este necesară.

Echipa ta este agilă?

Poate cel mai important criteriu este competența echipei tale în abordările Agile. Dacă echipa ta nu are experiență în Agile, atunci scalarea va crea mai multe probleme.

Practicile de dezvoltare ale echipei tale necesită îmbunătățiri?

Dacă practicile de inginerie ale echipei tale nu sunt eficiente, este posibil ca scalarea să nu producă rezultatele dorite. Practici precum implementarea corectă a DevOps și o conductă CI/CD sunt vitale pentru coerența între echipe. De asemenea, fără asigurarea standardizată a calității, poate fi dificil să testați funcții noi.

Echipa dvs. oferă incremente integrate?

Scalare implică integrarea mai multor echipe care colaborează la același produs, unde fiecare echipă produce caracteristici care funcționează împreună. Următorul tabel detaliază cele patru configurații posibile de echipe și produse. Rețineți că doar unul necesită scalare.

Numărul de echipe	Numărul de produse	Scenariu
1	1	O echipă gestionează dezvoltarea unui singur produs. Nu este necesară scalarea.
1	Mai mult de 1	O echipă lucrează la mai multe produse, astfel încât un manager de proiect poate fie să creeze o coadă de produse și să le dezvolte unul câte unul, fie să înființeze mai multe echipe care lucrează fiecare la un produs separat. Nu este necesară scalarea.
Mai mult de 1	Mai mult de 1	Numărul de produse este egal cu numărul de echipe. Nu este necesară scalarea.
Mai mult de 1	1	Mai multe echipe lucrează împreună pentru a oferi o soluție de produs mare - aceasta este configurația în care un manager de proiect ar trebui să implementeze un cadru Agile la scară.

Alegerea unui cadru de scalare

Există numeroase cadre de scalare Agile din care să alegeți, dar ne vom concentra pe cinci dintre cele mai utilizate soluții: Scaled Agile Framework (SAFe), Nexus, Large-Scale Scrum (LeSS), Scrum@Scale și Disciplined Agile (DA) . Am descoperit că acestea sunt cele mai eficiente cadre și pot fi aplicate la o serie de scenarii și organizații. Următoarele secțiuni vă vor echipa cu informațiile de care aveți nevoie pentru a face cea mai bună alegere pentru contextul dvs. unic de scalare.

1. Scaled Agile Framework (SAFe)

SAFe este cel mai popular cadru pentru scalarea Agile. Un sondaj din 2021 a constatat că 37% dintre practicienii Agile îl folosesc, în mare parte datorită configurațiilor sale multiple, toate care se concentrează pe fluxuri de valoare și au ghiduri și proceduri bine definite.

Deoarece SAFe este folosit pentru a furniza soluții complexe care necesită mai mult de 50 de oameni, organizează echipe în trenuri de eliberare agile (ART). Pentru a sincroniza echipele într-un ART, SAFe folosește iterații de increment de program — similare cu sprinturile Scrum — și fiecare iterație durează de obicei între opt până la 12 săptămâni. Această abordare permite managerilor de produs să rămână concentrați asupra obiectivelor generale și să supravegheze eficient o foaie de parcurs de produs complexă, fără a introduce modificări excesive.

SAFe se bazează pe cadrul Scrum, dar cu câteva diferențe cheie: adoptarea SAFe are loc mai degrabă la nivel de întreprindere decât la nivel de echipă; și în timp ce Scrum acordă proprietarului produsului singura autoritate asupra prioritizării, SAFe încurajează o abordare mai democratică.

SAFe are patru niveluri de implementare:

SAFe esențial

Essential SAFe este baza SAFe și trebuie stăpânit înainte de a trece la oricare dintre configurațiile ulterioare. Utilizează roluri Scrum consacrate, cum ar fi Scrum Master, manager de produs și proprietar de produs și, de asemenea, introduce un nou rol: inginer de tren de eliberare. Această persoană acționează ca un servitor-lider și antrenor ART, îndrumând echipele pentru a-și alinia obiectivele. Într-un ART pot exista între cinci și 12 echipe, fiecare ART capabil să ofere o soluție completă.

Soluție mare

Această configurație se află deasupra Essential SAFe și introduce un concept numit „tren de soluții”. Este folosit la construirea de soluții mari și complexe care necesită coordonarea mai multor ART-uri – potențial sute sau chiar mii de oameni – care lucrează pe același flux de valoare. De exemplu, dacă lucrați la Microsoft și aveți trei echipe separate care programează Excel, Word și PowerPoint, toate contribuie la același flux de valoare: Microsoft Office.

Portofoliu

Portofoliul constă din mai multe ART care lucrează pe diferite fluxuri de valoare. Continuând cu exemplul Microsoft: echipe separate care lucrează la produsele Office, Skype sau Xbox ale companiei.

Full SAFe

Această configurație combină toate straturile - Esențial, Soluție mare și Portofoliu - pentru a coordona managementul echipei la nivel de întreprindere.

Utilizați SAFe dacă organizația dvs.:
Este o întreprindere mare, bine stabilită. Este competent în Scrum. Are resurse financiare pentru a le angaja pentru roluri suplimentare. Construiește soluții complexe care pot necesita un număr mare de echipe în viitor. Ia o abordare rigidă pentru a urma practicile de bază ale cadrului. Are leadership Agile, care sprijină luarea deciziilor transfrontaliere.

2. Nexus

Cadrul Nexus se bazează și pe Scrum, dar este mai ușor decât SAFe, necesitând doar mici ajustări care facilitează colaborarea între trei până la nouă echipe. Implementarea Nexus nu necesită roluri suplimentare. Mai degrabă, un reprezentant din fiecare echipă se alătură unei echipe de integrare centrală care aliniază munca către un singur obiectiv. Similar cu Scrum, toate echipele se reunesc pentru o sesiune de planificare a sprintului, ale cărei rezultate formează stocul de produse partajat. Pentru a verifica progresul, fiecare echipă ține o întâlnire zilnică asemănătoare unui stand-up, iar echipa de integrare se întâlnește și pentru a raporta progresul echipei lor.

În timpul unui sprint, echipele participă la o sesiune de rafinare pentru a stabili prioritățile și estimarea restanțelor. Deoarece complexitatea gestionării restanțelor crește odată cu numărul de echipe, Nexus impune sesiuni de rafinare. Echipele se reunesc pentru recenzii și retrospective după fiecare sprint.

Utilizați Nexus dacă organizația dvs.:
Este un startup care are nevoie de un cadru ușor. Este competent în Scrum. Are resurse financiare limitate. Construiește soluții simple.

3. Scrum la scară largă (LeSS)

LeSS este aproape identic cu Nexus, dar are diferențe minore, cum ar fi convențiile de denumire și sesiuni suplimentare de planificare a sprinturilor specifice echipei. De asemenea, diferă prin capacitatea sa de a fi extins cu cea de-a doua configurație, LeSS Huge, care susține colaborarea a mai mult de opt echipe.

LeSS Huge adoptă o abordare centrată pe client pentru organizarea dezvoltării. Pentru a gestiona eficient munca, este necesar ca proprietarul produsului să împartă stocul de produse la nivel înalt în „restanțe” mai mici de articole mai granulare și apoi să le sorteze în continuare – în zone de cerințe.

Aceste zone de cerințe sunt gestionate de proprietarii de produse de zonă (APO). APO-urile sunt specializate în domeniile legate de fiecare zonă și lucrează cu mai multe echipe la soluții pentru zona lor. Fiecare cerință stocată în backlog aparține doar unei zone de cerințe, iar fiecare zonă este gestionată de un singur APO. Împreună, proprietarul produsului și APO formează o echipă responsabilă de prioritizarea cu o viziune la nivel de produs.

Folosiți mai puțin și mai puțin uriaș dacă organizația dvs.:
Este un startup care are nevoie de un cadru ușor. Este competent în Scrum. Are resurse financiare limitate. Construiește soluții complexe care pot necesita un număr mare de echipe în viitor.

4. Scrum@Scale

Scrum@Scale este o extensie a Scrum și probabil cel mai ușor cadru de învățat și de înțeles. Se scala de la o echipă la o echipă de echipe.

O componentă de bază a cadrului este Scrum of Scrums (SoS). Fiecare echipă alege un individ care să-i reprezinte în întâlnirile SoS, care de obicei au loc zilnic după stand-up-urile individuale ale echipei. Scopul întâlnirii SoS din fiecare zi este de a ajuta coordonarea și comunicarea între echipe și de a facilita gestionarea ușoară a oricăror dependențe sau suprapuneri.

Rolurile unice din acest cadru includ SoS master, în esență o versiune la scară a unui Scrum Master, și proprietarul șef de produs, care lucrează cu proprietarii de produse din echipă pentru a forma un backlog comun pentru SoS.

Scrum@Scale este mai puțin prescriptiv decât alte cadre, permițând organizațiilor să se extindă în propriul ritm. Dacă numărul de echipe continuă să crească și întâlnirile SoS devin prea mari, organizațiile pot escalada cadrul într-un Scrum of Scrum of Scrums (SoSoS).

Utilizați Scrum@Scale dacă organizația dvs.:
Este o întreprindere mare. Necesită o abordare flexibilă a scalarii. Este competent în Scrum. Construiește soluții complexe care pot necesita un număr mare de echipe în viitor.

5. Agil disciplinat (DA)

DA diferă de celelalte cadre prin faptul că acționează mai mult ca o cutie de instrumente din care poți alege cele mai potrivite strategii de scalare, mai degrabă decât un cadru rigid cu reguli pe care trebuie să le respecti. Este un hibrid bazat pe context de diverse cadre, inclusiv Scrum și Kanban, care poate fi adaptat nevoilor fiecărui proiect, centrat pe principiul „Alegerea este bună”. DA se bazează pe ideea că fiecare echipă și organizație este unică în dimensiune, distribuție și domeniu, iar fiecare membru al echipei este unic, cu propriile abilități și experiențe.

Poate fi aplicat la nivelul echipei de dezvoltare software sau la nivel de întreprindere. Pentru acesta din urmă, setul de instrumente DA identifică ce diverse funcții de afaceri - cum ar fi finanțele, operațiunile IT și managementul furnizorilor - ar trebui să se adreseze și prezintă o serie de opțiuni pentru a face acest lucru.

DA distinge trei faze ale proiectului — Inițiere, Construcție și Tranziție — și fiecare cuprinde obiective de proces orientate spre livrare. Deoarece acest cadru se concentrează pe ciclul de viață complet al livrării, spre deosebire de doar build, introduce mai multe roluri decât celelalte cadre. Rolurile principale, întâlnite în fiecare echipă DA, sunt părțile interesate, membrul echipei, liderul echipei, proprietarul produsului și proprietarul arhitecturii. Există, de asemenea, cinci roluri de sprijin, adesea folosite temporar pentru a ajuta la scalare: specialist, expert în domeniu, expert tehnic, tester independent și integrator.

DA poate fi folosit pe deasupra celorlalte cadre pentru a scala mai mult.

Utilizați DA dacă organizația dvs.:
Este o întreprindere mare, bine stabilită. Este Agil, dar nu aderă în mod specific la Scrum. Necesită o abordare mai flexibilă. Are resurse financiare pentru a le angaja pentru roluri suplimentare.

Alegeți cu atenție și scalați încet

Scalarea echipelor Agile și integrarea perfectă a muncii lor este dificilă, dar poate fi ușoară prin selectarea celui mai bun cadru. Utilizați diagrama de mai jos ca prim pas pentru a vă ghida procesul de luare a deciziilor.

O diagramă de flux în care fiecare întrebare are o opțiune da sau nu. Prima întrebare este „Organizația dumneavoastră este competentă în Scrum?” Opțiunea fără duce la un răspuns, „DA”. Opțiunea da duce la o a doua întrebare: „Organizația dumneavoastră construiește soluții complexe?” Opțiunea nu pentru această întrebare duce la un răspuns, „Nexus”. Opțiunea da duce la o a treia întrebare, „Este organizația ta un startup?” Opțiunea da pentru această întrebare duce la un răspuns „Mai puțin/mai puțin uriaș”. Opțiunea nu duce la o a patra întrebare: „Organizația dumneavoastră necesită o abordare flexibilă?” Opțiunea da pentru această întrebare duce la un răspuns, „Scrum@Scale”. Opțiunea nu duce, de asemenea, la un răspuns, „SAFe”. — Alegerea cadrului potrivit depinde de un număr de variabile.

Sunt încrezător că printre cele prezentate aici veți găsi cadrul de scalare care se potrivește experienței, abordării, bugetului și produselor organizației dvs. Indiferent de cadrul pe care îl alegeți, este esențial să nu vă grăbiți – scalați treptat pentru a minimiza întreruperile și planificați schimbările cu mult timp în avans.

Ați folosit aceste cadre în vreuna dintre activitățile dvs. de scalare? Povestește-ne despre experiențele tale în secțiunea de comentarii.