Putem vorbi de transformare Agile atunci când agilitatea este practicată doar la nivel de echipă distinctă? Aceasta este o întrebare-capcană pentru că da, putem avea doar echipe Agile, însă cu cât echipele sunt mai agile și sunt mai presate cu solicitări non-agile, cu atât această configurație împinge echipele într-o zonă de demotivare. Întrebările care decurg firesc de aici sunt atunci: ce înseamnă și când ar trebui făcută scalarea Agile la nivelul întregii organizații? Cum ne poate ajuta această scalare și cu ce ne încurcă dacă o întârziem?
A vorbi despre scalare la nivelul organizației și a înțelege ce este scalarea necesită în primul rând să vizualizăm organizația pe trei nivele: Strategic, Coordonare și Operațional. La nivel strategic, vorbim despre managementul portofoliului: ce va face compania Fit for Future? Cum prioritizăm potrivit cu direcția strategică? Câtă muncă poate fi susținută în organizație? Sau este munca efectuată aliniată cu strategia? Cu alte cuvinte, muncim la ceea ce ar trebui să muncim? Cheltuim capacitate și buget pe ceea ce trebuie? Dacă avem multe inițiative de optimizare, de exemplu, avem și un obiectiv de optimizare prezent? Avem capabilitățile necesare pentru a susține strategia pe următorii ani? Avem un mecanism prin care măsurăm și urmărim acest lucru? Este acest mecanism transparent?
Pe următorul nivel, cel de coordonare/tactic, atenția este pe fluxul de generare al valorii. Aici inițiativele din portofoliu se întâlnesc cu inițiative/cerințe de alt tipar, cel de business as usual. Ele sunt segmentate în bucățele mai mici și prioritizate pentru a duce ideea de la concept la realitate. Cum? Prin activități care generează valoare, prin optimizarea interacțiunilor dintre echipe, prin verificarea constantă a capacităților și alocarea de noi capacități acolo unde este nevoie. Coordonarea este vitală pentru ca fluxul dintre portofoliu și echipele de implementare să fie cât mai eficient și să fie neîntrerupt. Scopul este ca, de la ideea din portofoliu la implementarea ei, să treacă un timp cât mai scurt. Multe transformări Agile apar la nivel operațional/execuție, al treilea nivel, cel de echipe. Însă scalare înseamnă să urmărim cum interacționează o echipă cu celelalte, cum interacționează cu nivelul de coordonare, cum ne asigurăm că ceea ce ajunge la echipe este coordonat, prioritar și aliniat la strategie. Dezirabil este ca nivelul de coordonare să grupeze echipele într-un stream de valoare, pentru a le putea da și obiective orientate spre client, cât mai aliniate din perspectiva priorității. În felul acesta, nivelurile inferioare reinterpretează adaptat și eficient direcțiile din zona de portofoliu.
Alinierea strategiei cu execuția, ca marcă a agilității organizaționale, poate fi obținută prin implementarea unui cadru de lucru specializat. Cele mai cunoscute cadre de lucru pentru scalare sunt:
SAFe - Scaled Agile Framework este un set de tipare de organizare și flux de lucru menite să implementeze practicile agile la scara întregii întreprinderi. SAFe se bazează pe trei arii majore de cunoștințe: dezvoltarea agilă de software, dezvoltarea lean de produse și gândirea la nivel de sistem. SAFe promovează alinierea, colaborarea și livrarea în cadrul unui context complex, cu mai multe echipe agile implicate.
Modelul de maturitate Kanban, introdus de David Anderson este o alternativă sustenabilă la Scaled Agile Framework, deși nu este la fel de dezvoltat și de detaliat.
LeSS - Large-Scale Scrum este, în esență, un scrum obișnuit aplicat dezvoltării la scară largă. LeSS se bazează pe ideea că un framework de scalare ar trebui să fie minimalist (să includă cât mai puține reguli, roluri și artefacte). Însă LeSS și SAFe se suprapun în privința practicării scrum la nivel de echipă, a susținerii unui backlog comun între multe echipe, în privința planificării colaborative în cadrul mai multor echipe, precum și aplicarea principiilor generale de pull și auto-organizare cu care orice echipă agile este deja familiarizată. Less însă nu este nici pe departe atât de complet ca SAFe, care acoperă foarte bine și nivelul Strategic.
DA - Disciplined Agile, numit anterior DAD (Disciplined Agile Delivery) este un cadru decizional care vizează procesele orientate pe educație/învățare, care oferă o fundație solidă pentru a scala livrarea agilă a soluțiilor în cadrul întrepriderilor. DA folosește Scrum, Kanban, precum și cunoștințele privind transformarea, în zone de activitate precum resursele umane, finanțe, governance, DevOps, management de portofoliu și altele.
Indiferent de cadrul de lucru ales, scalarea Agile va fi contracarată de "inamici" din interiorul sau exteriorul organizației, care vor împinge spre păstrarea status quo-ului. În funcție de specificul cultural și operațional al întreprinderii am putea întâlni forțe opoziționale precum:
Priorități care se suprapun. Ce poate fi mai rău decât ca fiecare să aibă prioritatea lui sau ca prioritizarea să se bazeze pe "cheful" operațional ori pe cât de vocală este solicitarea? Rezultatul dezastruos este un flux de valoare extrem de fragmentat și o livrare deficitară.
Modul vechi de a face lucrurile. Tensiunea, conflictul între modul tradițional de a face lucrurile în organizație ne trage mult înapoi, chiar și pe cei care intră în adopție Agile.
Lipsa de aliniere între echipe.
Optimizarea defectuoasă a proceselor existente ori a modului de lucru, din dorința de a câștiga timp.
Presiunile de tip push constante către echipe.
Revenirea către vechiul mod de lucru, din comoditate și din neîncrederea în ceilalți.
Constrângerile.
Dacă apariția "inamicilor" nu poate fi prevenită, e important să avem o strategie pentru contracararea lor. Optim este să instituim "turnuri de apărare" care să poată nu doar bloca influența "inamicilor", ci preferabil să o absoarbă, să o transforme și să o refracte apoi în mod pozitiv. Astfel de "turnuri" sunt:
Implicarea stakeholderilor la toate nivelurile;
Utilizarea de roluri specializate pentru a susține evoluția echipelor;
Existența unei echipe care să conducă procesul de transformare;
Alinierea între cerere și capacitate disponibilă;
Prioritizare coerentă între arii de business;
Dacă știm că nu putem vorbi de transformare Agile atunci când agilitatea este practicată doar la nivel de echipă individuală, întrebarea care decurge de multe ori este dacă putem scala Agile la nivelul întregii organizații din start sau este necesar să începem să construim Agile mai întâi în echipe, după care să extindem la toată organizația?
În teorie, am putea porni concomitent și de jos în sus, și de sus în jos, însă, cel mai probabil, în urma unei abordări care pornește de sus în jos ori care urmărește obținerea scalării după doar două săptămâni de training intensiv, rămân echipe care nu se agilizează în timp, ci se blochează în interiorul iterațiilor și lucrează tot cum lucrau anterior. De aceea, este important ca scalarea să fie începută după minim șase luni de creștere Agile a echipelor. De asemenea, încă de la început trebuie mapat fluxul de livrare al valorii, pentru a identifica cea mai bună structură organizațională.
Scalarea Agile nu e ușoară, ci are o complexitate și intensitate care poate fi copleșitoare pentru organizație, cu rezultate câteodată întârziate față de așteptări, în special pentru că depinde de schimbarea modului de gândire a oamenilor. Însă, odată ce apar rezultatele reale, beneficiile sunt nenumărate, iar mulțumirea celor care au participat activ la transformare este de nemăsurat.
Cred cu tărie că, indiferent de modelele de transformare aplicate de organizații, Agile, SAFe sau oricare altul, orice organizație trebuie să treacă o dată la câțiva ani printr-o transformare, pentru a rămâne competitivă și eficientă.
de Nóra Dobre
