Știm cu toții ca în zilele noastre una dintre cele mai folosite metode sau moduri de lucru pentru a gestiona echipe de proiect este Agile. Agile se poate implementa cu succes folosind Scrum, Kanban sau altele. Toată lumea face Agile, toată lumea cunoaște principiile Agile și toată lumea îl implementează. Prin natura jobului am trecut prin multe proiecte, de la cele mai mici până la cele mai mari, de la cele mai ușoare până la unele dintre cele mai grele proiecte. De-a lungul timpului am citit foarte multe despre Scrum, despre cum se implementează și despre principiile lui, best practices, etc. . În toate aceste situații am găsit foarte puține informații despre cum se poate optimiza Scrum lucrând în echipe distribuite, localizate în diferite zone de pe glob, lucrând la același proiect și încercând să aplice aceste principii ce fac din Scrum una dintre cele mai populare metodologii.
Dacă vorbim de succes, față de anii precedenți se observă un trend ascendent asupra ratei de succes a proiectelor ce folosesc Agile, dar nu numai în cazul proiectelor ce folosesc Agile se observa acest trend. Mai jos, aveți o statistica a ultimilor doi ani:
Proiecte ce folosesc Agile (2012 vs. 2013):
Proiecte ce folosesc V-model (2012 vs. 2013):
Proiecte ce folosesc Waterfall (2012 vs. 2013):
Legenda
Sursa: http://www.planittesting.co.nz/resource/industry-stats-project-outcomes-based-on-primary-methodologies-2013/
Majoritatea echipelor de proiect în care am lucrat erau distribuite. Am întâlnit situația când clientul era localizat în USA și întreaga echipă de dezvoltare era localizată în România, dar am întâlnit și cazuri mai complexe când echipa de dezvoltare era localizată în România dar și în USA, la client. Cred că este una dintre situațiile cel mai greu de gestionat. În continuare, voi prezenta avantajele și dezavantajele unei echipe distribuite. Haideți să aruncam o privire obiectivă asupra avantajelor ce le oferă o echipă distribuită. În primul rând, diferența de fus orar nu trebuie privită ca un impediment( lucru care de obicei se întâmpla) ci trebuie privită ca un avantaj. De ce? Pentru simplul motiv că atunci când una dintre părțile echipei nu este disponibilă, cealaltă echipă este la muncă, poate să rezolve uneletask-uri, eventualele probleme apărute în sistemul din producție și așa mai departe. Dacă aruncam o privire de ansamblu asupra acestei situații observăm că într-adevăr diferența de fus orar este un avantaj pentru ca asigură pe o perioadă foarte mare dintr-o zi prezența suportului. Dacă se lucrează la un proiect care deja se află în producție acest avantaj devine poate și mai important.
De obicei pe mai toate proiectele se lucrează cu Scrum sau mai nou cu Kanban. Până aici toate bune și frumoase. Dar v-ați întrebat vreodată cât de bine cunoaște clientul metodologia Scrum? Este un aspect foarte important ce va avea un impact major în dezvoltarea ulterioară a proiectului cu repercusiuni destul de ample. În primul rând unii din clienții cu care lucram nu cunosc foarte bine ce înseamnă Scrum, care sunt principiile de bază și cum anume se aplică. Ba mai mult, dacă lucrăm cu o organizație destul de mare, acolo vom observa că sunt alte roluri și responsabilități. Sigur v-ați lovit de clienții aceia care au manageri de proiect sau care au așa- numiții Line Managers. Întrebarea e cum se mulează aceste roluri în Scrum?
Este foarte important în momentul în care se creează o echipă nouă și se începe munca la un proiect să se definitiveze încă de la început toate rolurile la toți indivizii implicați în proiect. Mai mult, recomandarea mea este să se definitiveze și o scurta listă de responsabilități pentru fiecare din aceste roluri. Aceste responsabilități vor face puțină lumină și vor nivela unele conexiuni în cadrul echipei astfel încât fiecare dintre oamenii implicați pe proiect vor ști ce au de făcut. Am stabilit că e foarte important să se definitiveze rolurile și responsabilitățile pe proiect, dar ce facem când ne lovim de unii clienți reticenți, care sunt foarte greu de convins asupra acestor aspecte? Răspunsul la aceasta întrebare se reduce la un singur lucru: ÎNCREDERE.
În acest punct foarte important, când se creează echipa e foarte important ca managerul de proiect, cel ce se ocupă de întreaga echipă de dezvoltare să-și intre în rol. Vorbeam de roluri, nu? Dar care e rolul principal al unui manager de proiect în această etapă? Formarea echipei, adoptarea unui proces comun pentru toată lumea și mai ales creșterea încrederii.
E foarte dificil să creștem încrederea într-un timp scurt, dar nu e imposibil.
Recomandarea mea pentru a facilita acest lucru, este de a avea o întrevedere directă, față în față cu clientul și de a discuta toate aceste aspecte.
Am întâlnit de-a lungul timpului diferite forme prin care o echipă funcționa și aici mă refer strict la rolurile și mai ales responsabilitățile fiecărui membru din echipă. Nu uitați, vorbim aici de echipe distribuite iar în cadrul acestor echipe veți fi surprinși să vedeți că fiecare înțelege în felul său rolul pe care îl are în echipă și mai ales responsabilitățile sale. E foarte important ca într-o echipă distribuită aceste roluri și responsabilități să fie clar stabilite încă de la început. Știm foarte bine care sunt principalii jucători într-o echipă ce adoptă Scrum-ul. Dar oare aceasta situație este una ideală tot timpul? Vă spun eu, în majoritatea cazurilor am văzut oameni implicați în dezvoltarea unui produs care pur și simplu nu se regăsesc în actorii aceia cu care suntem toți obișnuiți din Scrum. Un exemplu concret: un client vine și vă spune că el are la dispoziție un Business Analyst care va dori să lucreze cu echipa în toate etapele de dezvoltare ale produsului. Instinctiv, noi ca manageri poate am ieși la rampă și am încerca să analizăm dacă această poziție de BA se încadrează undeva sau dacă putem să găsim soluții pentru a optimiza Scrum-ul. Ba mai mult, am observat cazuri în care apăreau și anumite conflicte pentru că nu-i așa, în Scrum nu avem nici un BA. Cum se poate rezolva această situație cât mai eficient pentru toată lumea ? De obicei, propunerile mele merg în direcția în care acel BA ar trebui oarecum să se transforme într-un Product Owner, iar dacă avem un Product Owner de ce să nu lucreze împreună cu el?
Revenim puțin asupra rolurilor și responsabilităților. De cele mai multe ori, în echipele distribuite, și mai ales acolo unde sunt indivizi implicați în tot procesul de development , pot apărea anumite conflicte atât de la client cât și de la dezvoltator. E oarecum firesc ca unii clienți să încerce să pună în anumite poziții cheie oameni de la ei, oameni care vor dori să dețină controlul la ce se implementează, oameni care vor dori să controleze procesul de dezvoltare. Bineînțeles, din nou apar conflicte. Nu e un lucru rău ca unii clienți să dorească să participe efectiv la dezvoltarea produsului lor, dar trebuie să încercam să abordam aceste probleme directe cu ei și să-i determinăm să înțeleagă că noi în calitate de parteneri ai lor avem mai multă experiență în dezvoltarea unui produs.
Pentru a evita aceste situații neplăcute e foarte important să se precizeze care sunt rolurile și responsabilitățile tuturor oamenilor implicați în acest proces. Cine e responsabil cu adăugarea de noi task-uri în backlog? Cine trebuie să faciliteze comunicarea în cadrul echipei? Cine este responsabil pentru a conduce discuțiile tehnice? etc.
Odată stabilite aceste roluri și responsabilități sunt șanse foarte mari ca lucrurile să meargă foarte bine în cadrul echipei și implicit veți avea un client fericit.
Mulți dintre voi poate vă întrebați câteodată cum putem să comunicăm mai eficient în cadrul echipei și nu numai. Comunicarea joacă unul dintre cele mai importante roluri într-o echipă distribuită. Dacă într-o echipă care se află localizată în același loc, comunicarea vine de la sine, aici în cadrul unei echipe distribuite nu mai e așa ușor și trebuie să fim atenți cum putem rupe acele bariere care se vor ridica vrând-nevrând de-a lungul dezvoltării unui produs.
Dar dacă membrii echipei încep să comunice exagerat de mult, folosind orice oportunitate pentru a comunica orice legat de proiect, nu mai suntem eficienți. O comunicare eficientă implică o comunicare și o abordare cât mai directă prin care încercăm să rezolvăm orice situație apărută într-un timp cât mai scurt. Aceasta este o comunicare eficientă.
Sunt sigur că v-ați întâlnit cu situații în care ați simțit pe pielea voastră sau ați auzit de la alții, cum că "pierdem prea mult timpul în conferințe și meeting-uri cu clientul". În momentul în care auziți așa ceva, să știți că cel mai probabil aveți o problemă de comunicare. De ce să nu selectam 1-2 membri din echipă care să participe în asemenea ședințe prin rotație? Am eficientizat un pic? Eu zic că da. Sau de ce să nu avem în fiecare sprint, un om din echipă responsabil cu un asemenea task, acela de a lămuri unele din requirement-uri. Situațiile pot continua. Ideea este că putem fi eficienți doar prin mici ajustări.
Mai mult, înaintea unui release major sau a unui deadline important încercați să adunați toată echipa într-un singur loc. Ce poate fi mai eficient decât să ai toată echipa în același loc să poată comunica față în față? De multe ori e destul de greu să facem acest lucru, mai ales când vorbim de echipe mari. Știm foarte bine că mai sunt și anumite constrângeri de bugete. Acolo unde este posibil vă recomand din toată inima să încercați să adunați echipa într-un singur loc.
Dacă nu este posibil să adunăm întreaga echipă într-o singură locație, încercați în toate conferințele ce le aveți online cu restul membrilor să vă porniți camerele web. Uneori ajută foarte mult să-ți vezi interlocutorul, să observi mimica și expresia fetei persoanei cu care vorbești. Prin acest lucru discuțiile devin mai amicale, mai deschise și cu siguranță o să observați ca devin și mai eficiente.
Sursa: http://www.agilemodeling.com/essays/communication.htm
Vreau să mai fac o sugestie: încurajați toată lumea din echipă să abordeze direct o persoană care o poate ajuta. Facilitați comunicarea directă: ai o problemă de rezolvat și știi sigur că te poate ajuta cineva de la client, sau cineva din altă locație, atunci apelează direct la el. Mai mult, încurajați folosirea comunicării directe dacă e posibil, adică telefon, skype sau orice alt mijloc de apelare directă. E-mail-ul să vina ca ultima soluție. Veți fi surprinși de rezultatele ce pot apărea vizavi de comunicare folosind această abordare.
"Active listening", "information radiators" și negociere- toate aceste lucruri duc la o comunicare eficientă. Dacă înțelegem puțin aceste concepte vom putea să gestionăm mai ușor situații oarecum mai tensionate, sau cel puțin vom reuși să aducem mai multă vizibilitate asupra unui status cerut de un manager sau de client.
Information radiators reprezintă în mod normal orice ecran sau tabelă care e vizibilă tot timpul acolo unde lucrează echipa. În mod normal, dacă echipa ar fi într-un singur loc un information radiator poate fi un board din birou vizibil pentru toată lumea. Cum arată acest board când lucrăm în echipe distribuite? Acest board se transpune în mediul online și este dat de mai multe tipuri de rapoarte care sunt generate automat de acel instrument folosit de echipă pentru a măsura progresul, de exemplu JIRA. În acest caz, information radiators pot fi: burn down chart, burn up chart, cumulative flow diagram, velocity chart. Aceste tipuri de grafice îi oferă echipei, indiferent unde se află ea, posibilitatea de a vedea progresul unui sprint, de exemplu. Mai mult, știți foarte bine întrebările de genul "cum stăm cu sprintul asta?" sau "suntem on track cu sprintul?". Răspunsul la aceste întrebări îl poate obține oricine, dacă se va uita la unul din aceste rapoarte, care sunt sugestiv reprezentate grafic.
Exemplu de Burn down chart:
Exemplu de Burn up chart:
Menționam mai sus de "Active listening". În echipele distribuite acest concept joacă un rol consistent. În mod normal când ascultăm pe cineva o facem în mod pasiv. În metodologia Agile, acest mod activ de asculta (Active listening) se referă la faptul că toată lumea este implicată într-o discuție în mod activ, adică toată lumea trebuie să furnizeze întrebări și răspunsuri respectând niște reguli.
Vorbim aici de trei nivele când vine vorba de Active listening:
În ceea ce privește negocierea, sunt foarte multe lucruri interesante despre negociere, dintre care cel mai important lucru este că întotdeauna negocierea trebuie să se bazeze pe respect, înțelegere față de interlocutor și pe argumente valide care să stârnească atenția celui cu care discutați pe un anumit topic.
Esențial este ca în calitate de manageri să vă integrați în echipă pentru a nu fi priviți doar ca niște șefi. În acest fel veți contribui mai mult la o comunicare deschisă și mai ales eficientă.
Așadar, acest subiect este unul foarte vast și necesită poate multe dezbateri. În acest articol am punctat doar câteva dintre problemele reale cu care poate mulți din voi se confruntă atunci când lucrați în echipe distribuite. Ultimii ani ne-au dovedit că din ce în ce mai multe companii optează pentru echipe cu membri plasați în diferite colțuri ale lumii, din diferite considerente. Acest lucru reprezintă o provocare atât pentru manageri cât și pentru echipa în sine. Felul în care reușesc oamenii să interacționeze, să depășească anumite piedici și mai ales să aducă valoare în cadrul unei echipe de dezvoltare face din întreaga echipă un model de lucru . Proiectele și metodologiile evoluează, lumea ce ne înconjoară este într-o continuă mișcare, influențând mecanismele ce fac dintr-o simplă echipă o echipă de succes.
