In questo articolo presentiamo una serie di riflessioni relative ai contesti organizzativi e aziendali in cui si vogliano introdurre metodologie di tipo Agile. Gli ambienti di lavoro e il loro grado di stabilità e trasparenza possono influire pesantemente sul successo dell‘adozione di tali metodologie.

Introduzione

Per anni su queste pagine ci siamo occupati quasi esclusivamente di aspetti tecnologici e architetturali. Lo facciamo tuttora, a dire il vero, ma abbiamo ormai da tempo introdotto i temi legati all’organizzazione del lavoro e alle dinamiche di gruppo. In questo articolo vorrei riportare delle riflessioni in libertà sul tema degli “ambienti di lavoro” e della loro importanza nel successo o nell’insuccesso dei progetti software gestiti con metodologie agili. A dire il vero, sono argomenti di cui ci siamo occupati sia negli articoli della serie su Scrum [1] che in quelli sulle retrospettive [2] e che sono ampiamente trattati nel nostro libro “a puntate” intitolato “Guida galattica per agilisti” [3].

Le riflessioni che seguono sono però orientate a un tema specifico: il tipo di ambiente di lavoro, inteso come “ecosistema” e non solo come “luogo” in cui si trovano a operare i team agili, e il funzionamento o meno di certi sistemi di valutazione delle prestazioni dei singoli componenti della squadra.

Dalla Synchronicity alla Serendipity

Questo articolo nasce “per caso” e, in questo senso, è legato a due neologismi di origine inglese ormai entrati anche nel lessico italiano: “sincronicità” (synchronicity) e “serendipità” (serendipity). La sincronicità è un concetto introdotto nelle scienze filosofiche dallo psicologo Carl Gustav Jung: semplificando, indica l’esperienza per cui due o più eventi non legati tra loro da un nesso causale si verificano insieme in maniera significativa. La serendipità è invece quel fenomeno per cui si scopre qualcosa di interessante mentre… si stava cercando tutt’altro. Per inciso, i due termini sono anche il titolo di due album musicali rispettivamente dei Police (“Synchronicity”, 1983) e della PFM (“Serendipity”, 2000)… ma qui stiamo divagando.

Serendipidity e Synchronicity sono quello che ho sperimentato quando di recente, mi sono ritrovato ad affrontare una serie di riflessioni legate a queste tematiche: mi sono imbattuto in un post [4] di Ken Rubin in cui erano riportate delle considerazioni simili a quelle che stavo facendo con alcuni colleghi, anche se per certi versi il lavoro di Ken era meglio strutturato. La serendipità sta però nel fatto che questa ricerca mi ha portato ad imbattermi in un aspetto che non rientrava inizialmente in quanto stavo cercando: quello della valutazione delle prestazioni dei singoli.

Un ambiente “sicuro”

Uno degli aspetti che mi hanno colpito fin da subito è stato l’uso del termine safe a indicare un ambiente di lavoro “protetto”, termine che per certi versi  potremmo declinare con “stabile” (che non significa “statico”…).

In un quadro economico e aziendale perennemente in subbuglio oramai da tempo, le aziende che vogliano passare stabilmente e proficuamente a Scrum devono puntare a un ambiente di lavoro “stabile” e sicuro. L’agilità richiede sicurezza!

Questo non è scontato, perche‘ molte sono le ragioni che “precarizzano” l’ambiente di lavoro. E non stiamo parlando, almeno per la nostra realtà italiana, soprattutto di contratti a termine, body rental,  licenziamenti etc. ma di alcune “spie” che possono darci la misura del grado di stabilità e sicurezza di un ambiente di lavoro.

Abbiamo visto che Scrum non è solo una metodologia basata su un insieme di eventi (daily stand-up meeting, sprint, retrospettive etc.) e sull’uso di particolari strumenti (product backlog, sprint backlog burn down), ma si fonda su una serie di valori agili:

• concentrazione (focus),
• coraggio (courage)
• apertura (openness)
• impegno (commitment)
• rispetto (respect)

Quando vengono meno le condizioni che garantiscono la messa in atto di tali principi si inceppa l’intero processo. Negli ambienti in cui non c’è la trasparenza necessaria, il team e lo sviluppo si troveranno a performare in maniera peggiore e a non perseguire quel miglioramento continuo che è fonte di crescita per tutta l’organizzazione.

Il fatto che, giustamente, quando si parla di Scrum, ci si concentri anche e soprattutto sugli aspetti specifici di tale metodologia agile non significa che questi aspetti siano meno importanti.

Seguendo gli input di Rubin, vediamo qualche esempio per comprendere meglio questi concetti.

L’impossibilità di un “no”

Il caso tipico che tutti conosciamo: c’è un team che sta lavorando a uno sprint. Però arriva il manager di turno a chiedere se uno dei membri del team possa temporaneamente passare a lavorare su un altro progetto. Sappiamo che nei manuali questa cosa non esiste… ma sappiamo anche che in certe realtà aziendali è caso comune…

Idealmente, il fortunato prescelto dovrebbe dire: “Grazie per l’invito a lavorare su un progetto così importante… ma la mia risposta è ‘no’. Al momento sono impegnato su questo sprint programmato, oltretutto in una squadra alla quale non devo sottrarre il mio contributo, perche‘ potrei mettere in pericolo la riuscita dell’intero sprint. La cosa giusta da fare in casi come questo, quindi, è rispondere alla richiesta ma sempre evidenziando le conseguenze di una tale decisione “intrusiva”, a fronte di una pianificazione del “turn-over”. Quel che succede nella realtà, invece è che dica “Sì, arrivo subito”, senza alcuna valutazione oggettiva da condividere al manager (“OK, se si sposta questa persona dal team, probabilmente gli impatti sulle tempistiche e sulle performance del team saranno evidenti”), al quale semplicemente non si può dire di no. Un ambiente come questo, pone seriamente a rischio l’adozione e il funzionamento di metodologie agili. Poi ci sono anche i casi eccezionali, ed è un altro discorso. Ma un ambiente in cui non si possano dire dei no, ovviamente su base motivata come in questo caso, è un ambiente “a rischio”.

La verità tenuta nascosta

Ci sono situazioni in cui i team sono portati a mantenere uno stato di riservatezza nei confronti di una qualche persona che partecipa alle attività del team. È questo un fenomeno che si verifica per esempio durante la retrospettiva quando il gruppo non si trova in totale rilassatezza nei confronti di un collega che per esempio incarna un ruolo importante all’interno dell’organizzazione, come per esempio il PO: nonostante sia uno del Team Scrum, spesso il PO ricopre anche un ruolo all’interno dell’organizzazione (un manager, un PM). Tale ruolo potrebbe bloccare lo spirito di condivisione e di comunicazione: la gente non si sente libera di parlare e fare considerazioni.

Se questo tipo di libertà manca… non si tratta di un ambiente favorevole per Scrum e le metodologie agili.

Al bando i clienti!

Si lavora per loro, in definitiva: ma molte aziende non si sentono a loro agio nel coinvolgere i clienti nei processi in maniera trasparente. Eppure, e lo sappiamo, uno dei principali fattori utili per arrivare con successo alla fine del progetto sta proprio nella continua interazione tra cliente/utente che richiede un determinato prodotto e chi lo sviluppa. I clienti e gli utenti del sistema vanno mantenuti all’interno del circolo virtuoso di verifiche e feedback che permette precoci modifiche, adattamenti, aggiustamenti nel corso del processo.

Se, per qualche ragione, noe‘� riceve qualcosa che non risponde alle sue aspettative.

Attenzione alla competitività tra colleghi

Uno degli aspetti onnipresenti in numerose organizzazioni è la competitività tra colleghi. Attenzione, non stiamo parlando della giusta aspirazione a fare bene, ma di quel meccanismo autodistruttivo per cui “mors tua, vita mea”. Se ho delle informazioni, me le tengo perche‘ mi faranno fare bella figura con il “capo”, a discapito dei miei colleghi. Se qualcuno è messo in cattiva luce… meglio, perche‘ almeno i problemi non toccheranno a me. È quel tipo di ambiente lavorativo che viene a volte sagacemente raccontato da serie televisive o film. È di certo un ambiente in cui non ci si sente sicuri.

In Agile, invece, si vince insieme, come team, e si migliora tutti grazie alla conoscenza collaborativa. Il che non è una scusa per fare i “fannulloni”, ma anzi è proprio il contrario: i vari componenti dei team si motivano a fare meglio, con un procedimento di condivisione del know–how, di responsabilizzazione di ciascun componente del team che deve assumersi l’onere di dare il meglio, di sostegno verso chi, per qualsivoglia ragione da indagare e risolvere, stia momentaneamente  performando peggio.

Il fallimento del sistema delle classifiche degli impiegati

Qui arriva la “scoperta” che in un qualche modo ha attirato la mia attenzione e che, sebbene molto lontana dalla realtà italiana perche‘ tipicamente statunitense, offre ottimi spunti di riflessione sui rischi di una competitività mal riposta e tendenzialmente autodistruttiva. In molte grandi aziende americane, infatti, vige un sistema detto stacked ranking, una sorta di classifica degli impiegati volta, almeno nelle intenzioni, a spingere tutti a dare il meglio.

Lo stacked ranking

Nato negli anni Ottanta negli USA, questo sistema è stato adottato in molti ambiti industriali, specialmente nelle grandi aziende di tipo enterprise. In breve esso consiste nel classificare obbligatoriamente i lavoratori in tre o quattro grandi fasce, a seconda delle loro performance. Uno dei sistemi più utilizzati è quello del 20/70/10 per anni adottato, ad esempio, dalla General Electric [5]. Vengono valutati gli impiegati e suddivisi in tre fasce: i “migliori” nel 20% in cima alla classifica, i “nella media”, nel 70% e il restante 10% è considerato il gruppo di coloro che “sta performando male”. Dopo un certo numero di volte (che può variare) in cui si rientra nel gruppetto di coda, si viene licenziati.

Attenzione, per quanto possa apparire crudele, questo sistema nasce in un periodo in cui in effetti certe grandi aziende erano diventati dei “carrozzoni” in cui c’era gente che faceva bene poco… e lo faceva pure male. L’idea era quella di liberarsi (grazie alle leggi USA sul lavoro che lo consentivano) di quei lavoratori “fannulloni” che non si impegnavano e non di davano da fare per migliorare le loro performance.

I limiti della classifica

Questo sistema di stacked ranking portò in breve a massicci licenziamenti in molte aziende. Probabilmente, agli inizi, furono proprio i “fannulloni” a essere mandati via. Ma il sistema continuò a essere adottato e mantenuto per anni, in numerose aziende, con una serie di conseguenze deleterie:

• competitività “negativa”: conta non essere nel 10% di coda e quindi, ai fini di questa classifica, performare meglio o far performare peggio qualcun altro non fa differenza;
• criteri di classificazione aleatori: spesso essere in buona luce con il manager che stila la classifica può diventare più importante dell’effettiva performance che si sta producendo; più che quel che si fa in effetti, può essere importante come ci si mette in evidenza;
• erosione della base: se immaginiamo che il sistema tagli il gruppo di coda dei “peggiori”, dopo qualche taglio avrò però concluso l’espulsione dei veri “fannulloni” e mi ritroverò a dover espellere chi lavora peggio in relazione agli altri, ma magari, in termini assoluti, non sta affatto facendo cattivi risultati.

Questo sistema è andato avanti in molte aziende per molto tempo. Alcune lo hanno adottato negli anni Novanta, alcune ancora lo seguono. Altre, dopo venti anni, hanno preso coscienza dei rischi insiti in tale sistema: “pugnalate alle spalle”, favoritismi, demotivazione del personale, peggioramento del grado di competenza dei lavoratori. Tra i primi ad abbandonarlo, proprio GE che l’aveva abbracciato entusiasticamente nel 1981 e che, dopo averlo sperimentato nelle varie salse, l’ha abolito a metà degli anni Duemila. Per Microsoft, ad esempio, questo tipo di classifica ha voluto dire ritrovarsi con sviluppatori di prodotti più interessati a mettere in cattiva luce i loro concorrenti interni che non a creare prodotti più innovativi e performanti…

È solo un esempio, ma…

Ho voluto riportare questo esempio per suffragare con dei casi negativi la bontà dell’approccio agile che è l’antitesi dello stacked ranking. Più che un sistema di “punizioni”, a motivare il personale è il sistema di “ricompense”. Sentirsi parte motivata di un processo, avere nei propri colleghi un team in grado di sostenersi a vicenda, condividere valori e obiettivi sono leve potenti che possono portare nel giro di tempi ragionevolmente sostenibili a grosse performance per un’azienda.

Conclusione

Un ambiente “sicuro”, stabile è quello in cui il processo governato da un approccio agile si trova meglio a prosperare. E, viceversa, l’adozione di metodologie agili può in parte contribuire a quei cambiamenti in senso collaborativo in grado di convincere, con i risultati che ne conseguono, anche i manager inizialmente scettici: questa seconda possibilità è, onestamente, più difficile.

Di fatto, però, il punto di forza delle metodologie agili, e di Scrum in particolare, è la trasparenza. Le metodologie agili puntano anzitutto a vedere le cose per come sono. La lavagna Kanban, se fatta bene, non è altro che una “fotografia” di quello che si sta facendo; ed è un diffusore di informazione che parla a tutti coloro che lo vogliano ascoltare.

Paradossalmente, questa trasparenza è anche il punto “debole” dell’Agilità, poiche‘ essa smaschera resistenze, evidenzia “centri di potere” all’interno delle organizzazioni, mette tutti di fronte alle proprie responsabilità. La difficoltà nell’adozione corretta di Scrum, o quant’altro agile, non sta mai nella sua ormai assodata efficacia reale, ma nelle resistenze da parte di coloro che, sulla mancanza di trasparenza, possono continuare a prosperare.

Riferimenti

[1] Giovanni Puliti, “Guida galattica per scrummers. VII parte: I ruoli in Scrum”, MokaByte 193, marzo 2014

https://www.mokabyte.it/cms/article.run?permalink=mb193_GuidaScrummers-7

[2] Pierluigi Pugliese, “Guida alla retrospettiva. I parte: La retrospettiva come strumento per il miglioramento continuo”, MokaByte 194, aprile 2014

https://www.mokabyte.it/cms/article.run?permalink=mb194_Retrospective-1

[3] Guida galattica per agilisti

http://www.guidagalatticaperagilisti.com/

[4] Ken Rubin, “How Safe is Your Agile Environment?”

http://goo.gl/pg25it

[5] Peter Cohan, “Why Stack Ranking Worked Better at GE Than Microsoft”

http://goo.gl/pkYBc