Pe măsură ce companiile trec cu soluții software de la on-premise la cloud, adesea își stabilesc obiectivul de a deveni mai „agile”. Acest lucru ar trebui să se aplice deseori în mod ideal pentru orice la nivel de întreprindere. Și, desigur, peste tot în același timp.
Transformarea proceselor ar putea fi ușor posibilă, cel puțin în teorie. Puteți defini ceremoniile scrum și reatribuiți oameni pe noi roluri (cum ar fi Scrum Masters, Product owners, delivery managers și Scrum Teams).
Puteți aduce instrumente precum plăcile Jira, Azure ADO și Miro și le puteți utiliza obligatoriu. Dar cum rămâne cu procesele care conectează instrumentele împreună? Ce zici de a transforma mințile, comportamentele și modurile de lucru ale oamenilor? Devine clar că acestea nu se vor transforma fără probleme și nici nu se vor termina rapid. Acum, să observăm de ce.
Cuprins
Ce este o inițiativă de transformare a livrării și de ce o fac companiile?
O mare parte a companiilor de astăzi încă lucrează conform modelului de livrare în cascadă. Asta inseamna ca:
Întregul proces ar putea dura de la câteva luni până la câțiva ani și, după cum puteți vedea, utilizatorii vor vedea rezultatele numai la sfârșitul acelui proces. Deci, după o lungă așteptare, vine momentul adevărului (sau al eșecului).
Dacă ceva se schimbă în acest timp lung și produsul final ar trebui să arate puțin diferit, aceasta este o situație numită cerere de modificare. Designul trebuie redeschis, reluat și reaprobat. Prelungește întregul program de timp cu o altă parte.
În mod clar, acest lucru nu este agil în niciun caz. Fiecare modificare necesită o repornire a întregului proces înainte.
Trecerea la Agile
Deci, cum să ieșim din această situație și să o schimbăm pentru a deveni agili? Oamenii lucrează în amenajarea cascadei de mulți ani sau chiar secole. Au roluri și responsabilități cu care se simt confortabil și nu doresc să schimbe status quo-ul. Motivul principal pentru aceasta este că a face această schimbare înseamnă, în cele din urmă, pierderea unei părți din puterea pe care o aveau până acum.
Acesta este motivul principal pentru care o astfel de schimbare extrage cel mai puternic nivel de rezistență din partea oamenilor pe care le puteți crea.
#1. Restructurarea echipei
Primul și relativ simplu de făcut este să restructurați oamenii în echipe scrum. Împărțiți-le în funcție de zonele funcționale sau de orice altă împărțire logică care are sens.
Despărțirea se desfășoară de obicei fără probleme; problema începe când îți dai seama că oamenii sunt încă legați de structurile originale. Chiar dacă fac deja parte din noile echipe scrum, practic, nu sunt. Încă mai lucrează la acel setup vechi pentru că au încă responsabilități care nu s-au încheiat odată cu procesul de restructurare a echipei (pentru că de ce ar fi – leadershipului nu îi pasă mult de ceea ce trebuie terminat, ci mai ales de ceea ce trebuie început).
Deci, practic, ajungi cu o echipă de scrum care nu este o echipă de scrum dedicată în totalitate. Este un grup de oameni care acum pur și simplu are mai mult de lucru. Nu este atât de mult timp pentru muncă în cadrul echipei scrum pe cât se așteaptă conducerea.
În același timp, așteptarea este ca oamenii să își termine activitățile inițiale, precum și această nouă așteptare în interiorul echipelor scrum. Este o configurație determinată să eșueze chiar de la început.
#2. Programarea ceremoniilor Scrum
A ordona echipelor să programeze mai multe apeluri regulate (ceremonii de sprint) este ușor de definit și de început. Cel puțin, presupunând că echipele tale scrum nu sunt formate din oameni din 3+ fusuri orare (ceea ce este adesea cazul).
Problema începe atunci când oamenii nu se vor alătura ceremoniilor în mod regulat. În funcție de cine lipsește și cât de des, acest lucru poate evolua spre diferite tipuri de probleme. De exemplu:
- Dacă proprietarii de produse nu participă la ceremoniile de planificare și perfecționare, echipa nu are povești noi la care să lucreze. Sau descrierea poveștilor este atât de slabă încât restul echipei nu poate începe să lucreze la ele.
- Dacă maeștrii de scrum lipsesc la apeluri, echipa nu are orchestrarea de bază a scrumului și s-ar putea pierde în timp în cele din urmă.
- Dacă membrii echipei de dezvoltare lipsesc adesea, nu se pot sincroniza între ei, iar comunicarea în interiorul echipei este mult mai grea. De asemenea, sunt necesare mai multe întâlniri pentru a ajunge din urmă, ceea ce elimină încă o dată din echipă.
În cele din urmă, nu este neapărat vina oamenilor că ratează ceremoniile. Doar că configurarea nu le va permite să participe la apeluri (vezi mai sus despre sarcinile anterioare paralele).
#3. Stabilitatea echipei
S-ar putea să aveți o echipă scrum cu structură și ceremonii, dar dacă acea echipă nu este stabilă pe o perioadă mai lungă de timp – să zicem cel puțin o jumătate de an, în mod ideal, un an de stabilitate ar fi cerința mea minimă personală – atunci o astfel de echipă poate nu evoluează și nu se îmbunătățește cu adevărat.
În continuare, probabil că nu vei ajunge niciodată la o echipă scrum complet independentă care se ocupă de sprinturi ca de obicei. În cele din urmă, va trebui să educi și să înveți în mod constant oamenii din cadrul echipei pentru a înțelege mentalitatea și procesele Scrum. Este o problemă obositoare să ai.
Aceasta este o problemă foarte subestimată, în special de către conducerea sau conducerea companiei. A numi echipele de oameni doar „resurse” și a planifica „utilizarea” lor de la un trimestru la altul este un drum instantaneu către iad.
#4. Noi roluri pentru aceiași oameni
Un alt obstacol de depășit este reatribuirea persoanelor existente în diferite roluri noi. Cei care au condus anterior echipe cu putere maximă ar putea deveni acum proprietari de produse, de exemplu. Aceasta este o poziție puternică într-o echipă scrum, dar poate fi văzută ca un rol mai slab în raport cu configurația existentă.
Brusc, proprietarii de produse trebuie să se sincronizeze cu Scrum Master sau cu managerii de program. Ei sunt încă responsabili pentru conținut, dar nu atât pentru procesele de livrare. Această situație impune renunțarea la unele responsabilități pe care oamenii le aveau anterior și, prin urmare, este greu de înghițit.
#5. Modalități de lucru
Acesta este interesant și îl aud din când în când destul de des – trebuie să învățăm noi moduri de lucru pentru a deveni relevanți pe piața în evoluție, unde agilitatea este așteptarea de bază. Dar ce înseamnă exact acele moduri de lucru?
Dacă mă întrebați pe mine, este clar ce înseamnă managementul prin asta – să obțineți (mult) mai mult într-un timp mai scurt. După înființarea echipelor scrum, se așteaptă ca fiecare membru al echipei să obțină dintr-o dată niște rezultate incrementale documentate de la o zi la alta. Dacă nu este cazul, conducerea va începe să se întrebe de ce procesul agil nu funcționează bine.
Din senin, conducerea se așteaptă ca fiecare oră să conteze și că echipele scrum nu au, practic, timp inactiv, doar pentru că, probabil, nu există spațiu pentru toate procesele scrum în vigoare. Și aceasta este definiția „noilor moduri de lucru” din perspectiva leadershipului, pe scurt.
Desigur, această așteptare nu se bazează pe verificarea realității. Este iluzional să ne așteptăm ca oamenii din companie să înceapă să lucreze mai mult în aceeași perioadă, doar pentru că unele procese de zi cu zi se vor schimba. Adică, unii dintre ei ar putea, chiar dacă sunt doar o minoritate. Cu toate acestea, chiar și acest grup este redus și mai mult prin aglomerarea lor cu mai multe sarcini în același timp.
Diferența dintre țintă și realitate
Nu există nicio îndoială că descrierea obiectivului final este adesea bună și are mult sens. Se învârte în jurul următoarelor principii:
- Echipe Scrum stabilizate care lucrează la restanțe independente cu KPI și OKR clare.
- Proprietarii de produse trebuie să construiască foi de parcurs solide și să planifice conținutul prioritizat pentru a le livra conform unor calendare concrete.
- Conținutul de backlog definit cu funcții relevante deja detaliate înainte de începerea lucrărilor.
- Procese de testare fiabile executate împreună cu munca obișnuită de dezvoltare a sprintului.
- Lansări regulate în producție – cel puțin o dată pe lună, dar în mod ideal după fiecare sprint finalizat.
- Urmărirea riscurilor și problemelor și comunicarea între diferitele echipe scrum în cazul dependențelor.
Apoi, când vine vorba de realitate, pot spune că niciunul dintre punctele de mai sus nu este ușor de realizat.
- Formezi echipele scrum, dar acestea sunt în continuă schimbare (de la un sfert la altul). Investiți timp pentru a învăța echipa despre procesele scrum, iar odată ce în sfârșit încep să le accepte și să-și schimbe modul de lucru, reorganizezi echipele pentru perioada următoare. Foile de parcurs sunt modificate, mutate sau anulate.
- Proprietarii de produse nu au nicio idee reală despre detaliile foii de parcurs și (doar pentru că aveau astfel de obiceiuri înainte) își vor atribui sarcinile de a construi conținutul de backlog direct echipei. Ca urmare, echipa nu are timp să dezvolte conținutul, deoarece trebuie mai întâi să descopere ce să dezvolte.
- Procesele de testare sunt doar manuale și necesită o mulțime de subpași și aprobări și procese complicate de urmat. Asta înseamnă că testarea nu se poate termina în același sprint ca și dezvoltarea.
- În consecință, lansarea în producție rămâne cu câteva sprinturi în urmă.
- Comunicarea dintre diferitele echipe scrum este haotică și ineficientă, deoarece fiecare echipă are fiecare sprint de multe activități de realizat. De fapt, proprietarii de produse tind să atribuie echipei prea mult conținut la fiecare sprint. Nu există nicio șansă ca echipa să le finalizeze pe toate, așa că sunt în mod constant sub stres de termen limită.
Corectarea Greșelilor
Având experiență din câteva proiecte de transformare agilă, aș dori să rezumă câteva dintre cele mai mari greșeli pe care le-am experimentat și să dau câteva opinii subiective cu privire la eventuala depășire a acestora.
#1. Responsabilități corecte pentru roluri corecte
Dacă încercați să îndoiți definiția și să distribuiți responsabilitățile în alt mod decât ar trebui să fie prin scrum/agile, dați întreaga inițiativă la eșec.
- Proprietarii de produse trebuie să dețină conținutul și să mențină restanțele. Ei sunt responsabili pentru poveștile de backlog, iar dacă poveștile de backlog nu sunt bine definite, este la latitudinea lor să ia măsuri și să o repare. Pe de altă parte, ei nu ar trebui să aibă nicio influență asupra sarcinilor oamenilor echipei Scrum sau asupra deciziilor legate de bugetul proiectului.
- Scrum Masters nu va avea nicio responsabilitate în ceea ce privește conținutul backlog. Ei fac parte din echipă pentru a orchestra ceremoniile și pentru a educa echipa într-un mod agil de lucru. Nu ar trebui să fie secretar pentru Product Owners. Dimpotrivă, ei vor proteja echipa de dezvoltare împotriva proprietarului produsului și a părților interesate externe.
- Fiecare echipă scrum trebuie să aibă desemnat un lider de livrare. Această persoană va conecta PO, SM și echipa de dezvoltare într-o configurație funcțională, va defini procesele de livrare și va rezolva orice potențiale riscuri, probleme sau conflicte pe care le-ar putea avea echipa. Liderul de livrare este persoana potrivită pentru a decide întrebările privind personalul și bugetul proiectului. Această persoană se străduiește să creeze un mediu pentru echipă în care toată lumea să poată performa cel mai bine.
- Responsabilitatea echipei de dezvoltare este să dezvolte poveștile din restanță. Ele pot ajuta PO să construiască conținut pentru unele povești (în principal cele care sunt prea tehnice), dar nu sunt responsabili sau nici măcar responsabili pentru poveștile care construiesc crearea conținutului foii de parcurs.
#2. Echipa stabilă
Investiția în educația agilă a echipei este importantă și trebuie să fie un proces rapid. Lăsarea acestor cunoștințe să dispară la fiecare câteva luni este doar o pierdere de timp pentru toată lumea.
Primele cinci sprinturi pe care le puteți folosi ca curbă de învățare pentru ca echipa să cunoască și să exerseze activitățile de bază de scrum. Odată ce acestea sunt clare pentru întreaga echipă, procesul de îmbunătățire continuă al echipei scrum poate începe. Dar dacă oamenii din cadrul echipei se schimbă în mod regulat, te vei afla într-o buclă constantă de transferuri de cunoștințe și educație.
O astfel de echipă probabil nu va atinge niciodată potențialul maxim de performanță, iar echipa de conducere va continua să se întrebe de ce înainte (înainte de transformarea agilă) era mai eficientă decât pare acum.
Așadar, construiți echipa, investiți cunoștințele și, odată ce echipa este încrezătoare în noile procese, păstrați-le așa cum este și dezvoltați-vă în continuare. De aici va începe drumul constant către perfecțiune.
#3. Matricea RACI
Este o bună practică de a construi și de a conveni asupra matricei RACI (responsabil, responsabil, consultat, informat) între toate echipele chiar înainte de începerea reală a muncii. Acest lucru poate elimina o mulțime de confuzii chiar de la început.
Este destul de important, mai ales în stadiile incipiente ale inițiativelor de transformare. În caz contrar, oamenii vor începe să ridice întrebări despre cine ar trebui să facă ce în ce situație, mai ales în cele care nu au fost abordate în mod explicit prin comunicările echipei.
Iată un exemplu de astfel de matrice RACI pentru unele dintre responsabilități. Proiectul dvs. poate avea un set diferit. Este important să le surprindeți pe cele relevante.
TaskRequestor Delivery LeadProduct Owner Scrum MasterDev TeamSprint Planning SessionsC/ICA/IRC/IDeliver Release IncrementN/AIA/IC/IRSprint ReviewC/IIRICSprint RetrospectiveIIA/IRC/IRefine the BacklogIA/IRAC/I
Concluzie
Ar putea fi încă multe de scris, deoarece există multe modalități și multe locuri în care transformarea agilă poate duce în afara pistei. Scopul a fost de a sublinia unele dintre problemele pe care le consider a fi repetate des.
Inițiativa în sine este o idee bună. Cu toate acestea, poate deveni rapid un coșmar pentru toți participanții dacă respectați niște reguli de bază. Am evidențiat câteva dintre ele, dar folosiți doar bunul simț și veți fi bine. 🙂
Apoi, consultați resursele bune de învățare pentru certificarea Agile.