Tipare de Adoptie Scrum – Diseminarea în Restul Organizatiei

Revin cu un articol de încheiere a subiectului „Tipare de adopție Scrum”, în care, pe de o parte vă voi prezenta, după cum am promis, tiparele identificate de Mike Cohn pentru diseminarea Scrum în restul organizației, iar pe de altă parte voi împărtăși din experiența mea pe întregul subiect. Împărtășesc din experiența mea deoarece mă simt obligat să aduc și o contribuție personală la „știința și arta” Agile, nu numai să citez din alții, cu sau fără ghilimele! 🙂

După folosirea unuia dintre tiparele de adopție prezentate în articolul anterior se pune problema diseminării Scrum în restul organizației, în cazul în care nu am ales tiparul „Totul pe o carte”. Mike identifică pentru acest efort de diseminare alte trei tipare, toate bazându-se pe folosirea experienței acumulate de primele echipe care au făcut tranziția:

1. Divide și altoiește (”Split and Seed”)
2. Crește și divide (”Grow and Split”)
3. Coaching intern (”Internal Coaching” – da, știu, sunt tare la traducere și adaptare…)

Primele două tipare sunt în mod evident înrudite și sunt un fel de diviziune celulară: o echipă Scrum existentă este divizată pentru a forma două echipe noi.

În cazul primului tipar – „Divide și altoiește” – echipa este împărțită în două, dar nu la maturitate, ci la începutul tinereții, când nu le știe pe toate cele ce țin de Agile, dar știe de ajuns ca cele două jumătăți să devină, dacă vreți, portaltoaiele (de aici și „altoiește”) pe care adăugăm noi membri, care să învețe și ei despre Agile/Scrum.
Cel de-al doilea tipar – „Crește și divide” – se referă la strategia prin care adăugăm membri la o echipă Scrum dincolo de mărimea optimă de cinci, până la nouă oameni, până la momentul în care putem să o împărțim în două echipe complete, chiar dacă ele vor fi la limita de jos a dimensiunii optime.
Aceste două tipare înrudite sunt iterate până când toată organizația a trecut prin transformarea Agile.
Al treilea tipar – „Coaching intern” – presupune identificarea în echipele Scrum a persoanelor care au înțeles cel mai bine procesul și alocarea lor ca și Agile Coachi interni pentru echipele noi.

Dacă este să vorbim despre avantajele specifice fiecărui tipar în parte, „Divide și altoiește” pe de o parte permite adăugarea de echipe noi mai repede decât celelate, iar pe de altă parte, în fiecare echipă nouă avem pe cineva cu experiență în Scrum. În cazul tiparului „Crește și divide”, pe de o parte nu trebuie să distrugem echipe existente (ele au timp să crească), iar pe de alta, membrii echipelor simt mai multă continuitate de la un Sprint la altul. În ceea ce privește tiparul „Coaching intern”, el are avantajele că nu trebuie să dividem echipe care funcționează bine, coachii pot fi aleși unul căte unul pentru fiecare echipă (nu toți cei ce înțeleg și au experiență sunt capabili să-i învețe și pe alții) și de asemenea ei pot fi mutați de la o echipă la alta.

Alegerea între cele trei tipare se face în funcție de răspunsurile la două întrebări:

• Cât de repede dorim să diseminăm Scrum și la celelalte echipe?
• Avem în organizație destui coachi interni buni care să asiste echipele noi?

Primele două tipare sunt de preferat când dorim ca transformarea Agile să se facă rapid. „Divide și altoiește” este rapid dar și riscant (schimbarea componenței echipei afectează întotdeauna productivitatea), pe când „Crește și divide” este mai puțin rapid, dar și mai puțin riscant, fiind poate modul cel mai natural în care se pot răspândi ideile și practicile Agile în organizație, altfel decât de la sine.
Dacă răspunsul la cea de-a doua întrebare este pozitiv, atunci putem folosi tiparul „Coaching intern”, fie separat, fie pentru a augmenta una dintre primele două abordări. Acest tipar funcționează cel mai bine în anumite condiții, spune Mike:

1. Când organizația este îndeajuns de mare astfel încât practicile să nu se răspândească de la sine
2. Când nu este practic pentru proiectele noastre să dividem echipe
3. Când avem îndeajuns coachi interni sau putem apela la ajutor din afară.

Un ultim lucru care trebuie luat în considerare atunci când facem tranziția la Agile/Scrum este cât de repede să adoptăm așa-zisele „practici tehnice”, care vin din Extreme Programming, o altă abordare de dezvoltare Agile: design simplu și emergent, testare automată, programare în pereche, ș.a. Unii pledează pentru a adopta cât mai repede aceste practici, iar alții pentru a amâna, dând astfel timp echipei să aleagă ce este potrivit pentru mediul ei.

Ca motive pentru a adopta practicile imediat sunt:

1. Sunt posibile îmbunătățiri foarte rapide
2. Dacă echipa nu încearcă devreme practici noi, atunci ar putea să nu le încerce niciodată
3. Ar putea rezolva cele mai presante probleme ale proiectului.

Motive pentru a amâna folosirea practicilor tehnice ar fi rezistența față de acestea și faptul că echipa ar putea să fie deja prea ocupată pentru a avea loc pentru ceva nou, în plus.
Eu unul sunt ferm de partea ideii de a începe imediat cu practicile tehnice, deoarece experiența îmi spune că deprinderile bune prind greu și se uită repede, în favoarea vechilor obiceiuri. Și cu această declarație, fac trecerea la a vă împărtăși câte ceva din experiența mea în transformări Agile/Scrum.

Am întâlnit în practica mea Agile două tipare de adopție: o combinație între tiparele „Începe mic” și „Pe ascuns” pe care aș numi-o „La firul ierbii” sau „Începe mic, în jurisdicția ta, de capul tău” și tiparul „Totul pe o carte”.
Nu întotdeauna avem de-a face cu situația în care în organizație există un demers oficial, inițiat și condus de către managementul de top, de a trece la Agile. De multe ori, inițiativa de a încerca Agile aparține unui manager de proiect sau unei echipe anume, un răspuns inovator (și de multe ori disperat!) la problemele din teren.
În această situație ne-am aflat eu și echipa mea în anii 2007 – 2008. Problemele cu care ne confruntam în proiectul nostru, sacrificiile pe care le făcuseram pentru a-l duce la bun sfârșit au convins managementul de top că trebuie făcut ceva și să înceapă un proiect de process improvement. Un consultant extern ne-a introdus în lumea RUP și am început a ne formaliza procesele conform acestei metodologii. Nu era insă ceea ce ne trebuia și am continuat să căutăm.
Astfel, din căutare în căutare, din lectură în lectură, am ajuns singuri la Manifestul Agile și de acolo la Scrum. Ne-a surprins de la început cât de multe concluzii la care ajunseseram singuri, prin încercări și erori repetate, se regăseau în filosofia Agile. Ne-am angajat așadar, numai în echipa noastră și fără un mandat clar din partea conducerii, dar și fără împotrivirea ei, la implementarea Scrum. Călătorim pe acest drum și astăzi! Suntem acum la momentul în care diseminăm Scrum în restul organizației folosind toate cele trei tipare menționate în prima parte a articolului.
Ca să concluzionez, se poate iniția un proces de tranziție la Scrum la firul ierbii, dacă cei ce-l inițiază au destulă putere și dacă nu au sprijinul organizației, măcar sunt tolerați de aceasta.

Al doilea tipar pe care l-am întâlnit este „Totul pe o carte”, într-o organizație care a decis să adopte Scrum deoarece a fost achiziționată de alta, care-l folosește deja. Obiectivul fiind clar trasat și angajamentul managementului ferm, procesul a debutat cu un training introductiv de o zi. Apoi, echipa a început să folosească Scrum imediat după training, asistată de mine. Prezența unui Agile Coach pe de o parte dă încredere echipei, deoarece are de unde cere sfat, iar pe de altă parte obligă, ca față de un străin față de care nu trebuie să se facă de râs.
Uitându-mă în urmă, pot spune că mi-ar fi plăcut ca atunci când am ajuns la Agile să am parte de training și cu atât mai mult de ajutorul unui Agile Coach. În același timp însă, cred că implicarea personală a tuturor membrilor echipei, lectura asiduă și discuțiile animate sunt un ingredient esențial pentru o tranziție de succes la Agile/Scrum. Cred că trebuie să existe și un element de „la firul ierbii”, pe lângă efortul oficial al organizației.

În încheiere, dacă vă gândiți să demarați o tranziție la Scrum, ca organizație vă rog să țineți cont că în software contează oamenii mai mult decât procesele și instrumentele și nu există un glonț de argint, iar ca membri ai echipei vă încurajez să studiați singuri cât puteți de mult – citiți, discutați, încercați singuri, alăturați-vă comunității Agile locale!

Atribuire: Mike Cohn – ”Succeeding with Agile: Software Development Using Scrum”, Addison-Wesley 2009