Cum să abordați tranziția de la Scrum la SAFe

Implementarea echipelor Scrum funcționale într-o organizație este o provocare în sine, iar mulți eșuează în mod constant la acest pas. Cu toate acestea, odată ce aveți mai multe echipe foarte dependente care operează în același produs sau flux de valoare, aveți nevoie de ceva mai puternic.

Este necesar să se utilizeze un cadru de scalare care să acopere echipele Scrum. Oferându-le procese și reguli de urmat pentru a se sincroniza unul cu celălalt, a se alinia și pentru a nu se pierde pe parcurs.

Adesea ajungi cu echipe Silo, ceea ce înseamnă practic echipe scrum independente care lucrează pentru obiectivul lor local, dar abia au habar despre obiectivul comun final al întregului program. Aici intervine Scaled Agile Framework (SAFe).

Ce este SAFe?

Sursă: scaledagileframework.com

SAFe este o abordare care aplică un cadru și procese agile organizațiilor ierarhice din trecut. Acesta acoperă nivelurile și procesele structurii, dar în loc să le recreeze, reintroduce un al doilea sistem într-un mod organic, care este familiar pentru majoritatea părților interesate existente ale sistemului original.

SAFe este construit în jurul mai multor valori de bază.

Aliniere

• Toate echipele scrum trebuie să înțeleagă viziunea și strategia și care este obiectivul final spre care mărșăluiesc.
• Conectați strategia între echipe și conduceți-le către execuția comună.
• Comunicați cu echipele printr-un limbaj comun unificat pe care îl pot înțelege cu ușurință.
• Verificați în mod constant dacă echipele înțeleg obiectivele și viziunea.
• Echipele trebuie să fie centrate pe client și ar trebui să înțeleagă cine sunt clienții și de ce au nevoie. Actualizați strategia pentru a reflecta acest lucru.

Transparenţă

• Creați un mediu în care toată lumea poate lucra cel mai bine și fără lipsă de încredere.
• Comunicați deschis argumentele și faptele dvs. Fii direct și sincer și nu ascunde fapte importante în fața echipelor.
• Eșuează rapid și transformă greșelile în momente de învățare. Dacă ceva se dovedește a nu avea succes, dă-ți seama curând și învață din el. Apoi, schimbă-ți strategia.
• Vizualizați munca pe care o construiți, astfel încât toată lumea să poată înțelege mai bine.
• Oferiți acces rapid la informațiile necesare.

Respect pentru oameni

• Subliniază ce înseamnă să fii om. Nu trata oamenii ca pe resurse.
• Valorificați diversitatea oamenilor și opiniile acestora. Sprijiniți feedback sincer.
• Creșteți și educați oamenii prin coaching și mentorat.
• Îmbrățișați că clientul dvs. este cel care vă consumă munca.
• Construiți parteneriate de lungă durată în cadrul echipelor și în afara echipelor.

Îmbunătățire necruțătoare

• Construiți un mediu în care rezolvarea problemelor este motivarea echipelor.
• Reflectați la modul în care ați procedat săptămâna trecută și identificați ce se poate face mai bine data viitoare.
• Luați faptele drept cel mai important argument pentru îmbunătățirea lucrurilor.
• Oferiți timp și spațiu pentru inovații. Oferă echipelor posibilitatea de a experimenta și de a încerca diferite rute, chiar dacă acestea nu sunt cele mai sigure.

SAFe aduce un nivel de colaborare și comunicare sistemelor Agile scalate. Nu înlocuiește Activitățile individuale Scrum Team Sprint pe care le faci astăzi.

O parte cheie a fiecărui SAFe este Agile Release Train (ART). Este o echipă stabilă și de lungă durată de echipe Scrum (de obicei, până la 12 echipe separate) care aduce în mod regulat noi funcționalități incrementale după fiecare lansare de sprint. Ei dezvoltă, furnizează și susțin una sau mai multe soluții într-un flux de lucru.

Sursă: scaledagileframework.com

Rolurile SAFe

SAFe se bazează pe oameni cu seturi diferite de responsabilități. Respectarea așteptărilor pentru roluri este factorul crucial care va determina cât de reușită va fi implementarea cadrului. Prin urmare, este, de asemenea, important să înțelegem care sunt aceste roluri și care este scopul lor.

#1. Echipa Agile

Echipele Agile sunt interfuncționale, ceea ce înseamnă că pot acoperi întreaga zonă pe care o implementează în cadrul echipei în sine. Ele sunt, de asemenea, entități care se organizează automat, care definesc, construiesc, testează, implementează și lansează incremente de valoare.

Fiecare echipă Agile are setul de abilități pentru a-și executa domeniul de aplicare convenit și angajat. Echipa implementează acest scop prin incremente la fiecare sprint într-un mod previzibil. Previzibilitatea este crucială pentru că numai atunci echipa se poate angaja să livreze obiective concrete în timp concret. Comunicarea și livrarea sunt valorile cruciale pe care echipa trebuie să le îmbunătățească în mod constant.

Echipa agilă este o parte fundamentală a sesiunilor de planificare Program Increment (PI) pentru a crea povești și a le planifica în Sprints. În cele din urmă, ei se angajează să își respecte propriile obiective PI.

Scrum Master antrenează echipa Agile și facilitează întâlnirile de echipă. Îndepărtează impedimentele și protejează echipa de influența externă. Ei participă la întâlnirile Scrum ca parte a ART.

Product Owner (PO) este un alt membru special al echipei. PO este vocea clientului și are o influență directă asupra poveștilor și a prioritizării acestora. OP comunică cu alte OP-uri pentru a defini și prioritiza poveștile din acumularea echipelor.

#2. Management de produs

Managementul produselor se află deasupra echipelor scrum și are grijă de alinierea între echipe. Aceștia trebuie să acopere următoarele responsabilități:

• Îndepliniți obiectivele de afaceri, asigurându-vă că echipele de dezvoltare creează produse și soluții fezabile și durabile.
• Înțelegeți nevoile clienților și asigurați-vă că produsele sunt finalizate într-o perspectivă definită a clientului.
• Asigurați-vă că există în permanență suficiente funcții pregătite în backlog.
• Sprijiniți fluxul de lucru prin panourile de program și în stocul programului.
• Determinați sfera următorului program de creștere, oferind prioritate caracteristicilor create de echipe. Managementul produsului este responsabil în ultimă instanță pentru definirea următorului PI.

#3. Arhitect de sistem / Inginerie

Echipa de ingineri analizează și dezvoltă conținutul agreat al poveștilor de backlog. Ei sunt parte de expertiză a echipei și acoperă următoarele responsabilități:

• Creați și mențineți pista arhitecturală, astfel încât noile funcții să poată utiliza facilitatorii tehnologici.
• Participați activ la planificarea creșterii programului. Fiți prezent în timpul demonstrațiilor de sistem la sfârșitul fiecărei creșteri de program.
• Lucrați cu echipe agile pentru a implementa noi elemente de activare a arhitecturii. Numai acest lucru va permite echipelor să construiască noi funcții.
• Ajutați echipele agile să definească soluții și decizii de design la nivel înalt. Propuneți soluții alternative și cea mai bună abordare pentru activitățile de demonstrare a conceptului în cadrul echipelor agile.
• Ei creează o pistă arhitecturală. Este o definiție a facilitatorilor tehnologici gata să fie consumați de caracteristicile care sunt definite de echipele respective.

#4. Proprietari de afaceri / Părți interesate

Acestea sunt echipele externe echipelor Scrum, dar ele încă joacă un rol important în cadrul SAFe în fiecare etapă a execuției.

Înainte de planificarea PI:

• Oferiți contribuții pentru activitățile de rafinare a restanțelor.
• Participați la planificarea pre-PI după cum este necesar.
• Asigurarea faptului că obiectivele de afaceri sunt înțelese și acceptate de către părțile interesate cheie ale trenului, inclusiv Release Train Engineer (RTE), Product Management și System Architects.

În timpul planificării PI:

• Furnizați contextul și viziunea de afaceri pentru viitorul PI.
• Participați la revizuirea proiectului de plan și atribuiți valoare afacerii obiectivelor PI ale echipei.
• Participați la evaluarea managementului și ajutați la rezolvarea problemelor care vor duce la acceptarea Planului final.

După planificarea PI:

• Participați activ la menținerea alinierii afacerii și dezvoltării, deoarece prioritățile și domeniul de aplicare se schimbă inevitabil.
• Ajută la validarea definiției produselor minime viabile (MVP) pentru Program Epics și ghidează decizia de pivotare sau perseverență bazată pe livrarea MVP.
• Participați la demonstrația sistemului pentru a vedea progresul și pentru a oferi feedback.
• Participați la evenimentele Sprint Planning și Sprint Retrospective ale echipei Agile, după cum este necesar.
• Participați la gestionarea lansărilor, concentrându-vă pe domeniul de aplicare, calitate, opțiuni de implementare, lansare și considerente de piață.

#5. Release Train Engineer (RTE)

RTE organizează activitățile oamenilor și echipelor din cadrul ART. Acesta este rolul unui Scrum Master pentru întregul program. Următoarele sunt principalele responsabilități:

• Gestionați și optimizați fluxul de valoare prin ART.
• Stabiliți și comunicați calendarele anuale pentru Sprinturi și Creșteri de Program (PI).
• Fiți moderatorul întâlnirilor de planificare a PI.
• Organizați echipele și ajutați-le să creeze un rezumat al obiectivelor PI identificate. Transferați obiectivele echipelor în obiectivele generale ale Planului PI.
• Reunește echipele pentru a comunica și a rezolva riscurile și dependențele între ele.
• Conectați managementul de produs, proprietarii de produse și alte părți interesate externe pentru a alinia părțile la strategia lor comună.
• Orchestrați atelierele de inspectare și adaptare cu scopul de a îmbunătăți continuu procesele și activitățile deja existente.
• Evaluați nivelul actual de maturitate al adoptării metodologiei agile de către echipe și definiți elementele de acțiune ulterioare pentru a îmbunătăți echipele în viitor.

#6. Conducere

Leadership-ul definește strategia programului și oferă echipelor toate instrumentele și sprijinul necesar pentru a le permite munca. În cele din urmă, ei definesc sistemul în care funcționează toate celelalte. De aceea este esențial să existe o echipă de management care să ofere echipei scopul și definiția corectă a valorilor. Responsabilitățile lor principale sunt următoarele:

• Condus de exemplu.
• Adoptă o mentalitate de creștere.
• Evidențiați valorile și principiile SAFe.
• Dezvoltați oamenii.
• Conduceți schimbarea.
• Încurajează siguranța psihologică.

Planificarea creșterii programului (PI).

PI Planning este un eveniment de două până la trei zile cu scopul de a înțelege și de a se angaja în munca pentru următorul program de creștere. Aceasta ar putea fi perioada din trimestrul următor, de exemplu.

Managementul produsului deține prioritizarea caracteristicilor identificate în timpul planificării PI. Echipele agile dețin planificarea capacității, crearea poveștii, estimarea și angajamentul față de obiectivele PI.

Planificarea PI este esențială pentru SAFe. Dacă nu faci planificarea PI, asta înseamnă practic că nu faci SAFe.

Procesul PI

Sursă: scaledagileframework.com

Planificarea PI începe cu unele intrări pe tabel. Fiecare flux de lucru își va colecta nevoile și ideile despre ceea ce ar dori să construiască în continuare pentru produsele lor. Apoi îl aduc la PI ca intrare:

• Top 10 caracteristici de implementat în continuare,
• ART Backlog de epopee sau caracteristici gata de formulat,
• Viziunea proprietarului produsului.

Discuția începe între diferitele fluxuri de lucru. Fiecare dintre ei își prezintă viziunile și trăsăturile. Ei scot în evidență ceea ce este important de implementat în continuare și de ce au nevoie pentru a reuși în timp ce fac asta. Acest lucru ar putea însemna mai multe lucruri diferite:

• Activarea este furnizată de alte fluxuri de lucru pentru a le permite să continue cu funcțiile.
• Dependența de alte fluxuri de lucru și necesitatea de a face comanda o prioritate.
• Problemele curente care sunt prezente în sistem și care trebuie rezolvate mai întâi pentru a continua.
• Provocări de personal pentru echipă. S-ar putea ca mai multe roluri cheie în cadrul echipei încă lipsesc pentru implementarea conținutului pe care o necesită funcțiile.
• Constrângerile bugetare împiedică fluxul de lucru să execute viziunea în cronologia dată.
• Orice alte riscuri, probleme, ipoteze sau dependențe pe care echipa le poate recunoaște și este nevoie de o discuție mai amplă în restul echipelor SAFe pentru a se alinia la obiectivul comun.

Tutorial PI

Planificarea PI în sine este adesea împărțită în mai multe zile, de obicei două până la trei zile, în care agenda poate fi după cum urmează:

Ziua 1

• Discutați declarația afacerii și obiectivele cheie viitoare care formează viziunea și strategia generală a programului. Conducerea deține această parte și comunică clar echipei.
• Așezați pe masă toate caracteristicile din fluxurile de lucru și acordați-le prioritate în conformitate cu viziunea comună.
• Intră în viziunea Arhitecturii și definește principalele obiective ale cerințelor de dezvoltare. Evidențiați provocările tehnice și conveniți asupra rezolvării impedimentelor din cadrul echipelor.

Ziua 2

• Explicați în detaliu echipelor procesul de planificare. Subliniați rezultatele așteptate odată ce PI este închis.
• Faceți echipele de echipă pentru prima dată în timpul planificării. Scopul echipei este de a crea proiecte de planuri și de a identifica impedimentele și riscurile.
• Odată terminat breakout-ul, echipele vor prezenta și revizui proiectele de planuri pe care le-au creat în fața celorlalte echipe.
• Următorul pas este pentru management, unde ei revizuiesc planurile și oferă direcții pentru inițiativele de rezolvare a problemelor care urmează. Ajustările la planuri se fac pe baza provocărilor, riscurilor și impedimentelor.

Ziua 3

• Începeți ziua cu ajustări de planificare care sunt acum în conformitate cu ședința de conducere din ziua precedentă.
• Echipele vor dezvolta planurile finale și vor rafina riscurile și obstacolele. Proprietarii de afaceri vor atribui valoare afacerii obiectivelor echipei.
• În continuare, echipele vor prezenta planurile finale în fața întregului public.
• Riscurile rămase la nivel de program sunt discutate și se aplică informațiile despre riscul ROAM (rezolvat, deținut, acceptat, atenuat).
• Echipele votează pentru încrederea lor în rezultatele planificării programului.
• Dacă voturile sunt prea scăzute sau încrederea generală este încă scăzută, are loc o planificare suplimentară.
• După angajamentul PI, RTE plănuiește o retrospectivă pentru echipe pentru a discuta cum decurge planificarea și ce trebuie îmbunătățit pentru runda următoare. Conducerea afirmă ce se va întâmpla în continuare, alături de instrucțiunile finale.

Rezultatul PI

Rezultatul final al planificării PI este lista de caracteristici planificate pentru finalizare conform sprinturilor în următoarea perioadă PI. Toate dependențele cunoscute au un plan exact pentru rezolvarea și deblocarea progresului pentru funcții.

Echipele se vor angaja la obiectivele și domeniile lor. Dacă există obiective suplimentare care nu fac neapărat parte din listă, tratați-le ca obiective neangajate. Acestea pot fi eventual rezolvate dacă timpul și resursele permit acest lucru.

Echipele vor documenta și urmări toate riscurile programului și vor avea un plan exact despre cum să le facă față.

De asemenea, echipele vor surprinde fiecare idee retrospectivă cu care au venit la întâlnirea lor retrospectivă și le vor marca ca lecții de învățare pentru următoarea sesiune de planificare a PI.

În ceea ce privește în special echipele, există puține așteptări concrete, cum ar fi:

• Echipele se angajează la obiective cu valori de afaceri.
• Echipele își vor calcula capacitatea pe sprint, astfel încât să poată estima mai bine fezabilitatea conținutului foii de parcurs.
• Ei iau în considerare și sarcina reală pentru fiecare sprint.
• Poveștile sunt duse la sprinturile concrete ale fiecărui flux de lucru în funcție de capacitatea oferită.
• Echipele votează pentru încredere în planul PI și conținutul de livrat.

Concluzie

Acest lucru nu trebuie să pară evident, chiar și după ce am citit toate faptele de mai sus, dar vă pot spune că transformarea unei organizații mari în SAFe este o sarcină extrem de provocatoare. Da, în unele cazuri, poate părea o misiune imposibilă. Chiar dacă unele dintre aceste principii de bază sunt aplicate, de obicei sunt necesare multe iterații pentru a te converti într-o stare în care poți spune în siguranță că acum ești SAFe :).

Foarte des, progresul distruge niște principii și reguli ierarhice vechi, care pur și simplu nu vor muri, indiferent cât de mult ai încerca. Puteți avea o planificare extinsă PI și rezultate de un fel, pe care le puteți chiar numi cu încredere. Dar ce înseamnă cu adevărat dacă echipele din fluxul de lucru pur și simplu nu vor funcționa într-o metodologie agilă adecvată?

Pot spune doar că aici nu este loc pentru hibrizi. Fie sunteți în – cu toate procesele, oamenii și mentalitatea potrivite, fie sunteți afară dacă cel puțin unul dintre aspectele metodologiei nu este într-adevăr îndeplinit.

Bineînțeles, înainte de a lua în considerare implementarea SAFe, trebuie să fiți clar că ați stăpânit deja principiile și modurile de lucru ale echipei Agile. Nu doar din perspectiva conducerii, ci lăsați echipele să voteze și să-și exprime părerea sinceră. S-ar putea să fii surprins de rezultate.

Apoi, consultați resursele de învățare bune pentru certificarea agilă.

A fost de ajutor articolul?

Multumim pentru feedback-ul dvs!