Mi s-a întâmplat de mai multe ori să văd că o singură persoană asumându-și cele două roluri: de Scrum Master și de dezvoltator. Motivul invocat de obicei este lipsa de buget sau lipsa de eficacitate. Ce va face un Scrum Master pentru o echipă de două persoane?
Pe lângă raționamentele evidente, precum subiectivitatea Scrum Master-ului în stimularea performanței echipei, cred că merită să precizăm că în întreaga literatură Scrum am găsit prea puține cazuri în care această formulă să fie un succes. Mai precis 3 cazuri, dar din păcate nu le am la îndemână ca să adaug referințele. Din experiența mea, n-am văzut niciun caz care să mă dea pe spate. Funcționa cât de cât și încuraja mediocritatea la locul de muncă. Să nu mai spun că acești Scrum Master-i, o importantă sursă de stimuli motivaționali, erau și persoanele care se plângeam cel mai mult…
Întrebarea cheie căreia prefer să-i răspundem înainte de a lua decizia cumulării celor două roluri este următoarea: În condițiile în care nu reușim să livrăm, atunci când există acea presiunea să se producă mai mult, ce va face Scrum Master-ul? Se va alătura echipei ca dezvoltator diminuându-și activitățile de Scrum Master sau va continua să-și joace rolul de Scrum Master continuând să aibă o abordare sistemică a chestiunilor de performanță.
Anul trecut când am fost în Vietnam am întâlnit o situație similară. Echipele erau deja formate, Scrum Master-ii erau niște tehnicieni excelenți, orice, numai Scrum Master-i nu erau. Adică le lipseau acele abilități soft despre care vorbeam în articolul Ce înseamnă să fii Scrum Master. Partea bună a fost că clientul și-a dat seama de greșelile făcute în pregătirea proiectelor și a înțeles de ce activitățile unui Scrum Master sunt atât de importante și benefice organizației mamut pe care o reprezenta.
Înainte să plece, CIO-ul, care nu era implicat la nivel operațional, și-a rafinat așteptările către echipe, și printre altele, a transmis următorul mesaj:
Înainte de productivitatea imediată, așteptarea noastră este ca Scrum Master-ii să-și îndeplinească atribuțiile de Scrum Master. Ulterior, doar dacă le rămâne timp, își schimbă cascheta cu cea de dezvoltator.
Scrum Master-ii selectați în acest moment – după criteriile date – nu sunt Scrum Master-i veritabili, ci tehnicieni excelenți. Ei nu vor juca eficient rolul de oglindă a echipei de dezvoltare astfel încât aceasta să se poată ameliora. Dar de unde să aduci mai mulți Scrum Master-i experimentați când nimeni, sau prea puțini, au exersat rolul exact așa cum a fost el conceput? Majoritatea Scrum Master-ilor sunt doar foști șefi de proiect sau tehnicieni buni cu o nouă caschetă. Le vom acorda răbdarea și sprijinul necesare Scrum Master-ilor actuali până când aceștia vor deveni excelenți.
N-aș vrea să spun că această combinație nu poate funcționa. Alții zic că se poate. Eu cred că mai sunt și alte opțiuni și prefer mai degrabă să am un Scrum Master pe mai multe echipe decât ca dezvoltator. Iar dacă ar fi să compar cu celelalte roluri, mi se pare cel puțin la fel de greu să fii un Scrum Master excelent. Știind cât de greu este de implementat un Scrum veritabil, că sunt puțini Scrum Masteri cu experiență, și că tranziția este lentă și descurajantă, un Scrum Master&Dezvoltator nu va contribui suficient la succesul echipei Scrum.
Scrum Master și apoi dezvoltator sau dezvoltator înaintea Scrum Master?
Dacă doriți să aflați mai multe despre mine, Cornel Fătulescu, sau proiectele în care sunt implicat, vă invit să mă descoperiți și ca Chief Platform Officer la Pentalog, să mă urmăriți pe Facebook, ca investitor la wanttolearn, să citiți unul dintre primele articole despre mine și să mă contactați urmând ghidul de pe pagina de contact.
Acest articol a fost citit de 2574 ori