Tutti siamo probabilmente d’accordo che spesso è difficile trovare una definizione diretta ed immediata di Agilità... ed è giusto così!
Ogni realtà è Agile a suo modo, e anche l’adozione di un framework o di una metodologia specifica è da intendersi come un riferimento da cui trarre ispirazione, applicandolo il più possibile nel suo insieme per poi “rompere le regole” e trovare la propria declinazione di agilità.
Ma nell’Agile si annida un virus potenzialmente letale che cerca di farsi strada man mano che si procede nel cambiamento e bussa alla porta ogni volta che si incontra un intoppo o un problema: si tratta del lassismo.
Stiamo parlando dell’atteggiamento che porta ad una mancanza di serietà e disciplina nelle proprie azioni, sfociando quasi sempre in un menefreghismo ed in una rassegnazione generica che porta a considerare ogni sforzo inutile poiché “tanto nulla cambia”.
Tenere alta l’asticella dell’entusiasmo durante una fase di cambiamento è uno dei compiti più ardui per chi si occupa di supportare il cambiamento stesso, al di la del ruolo specifico. Creare la necessaria empatia e portare a bordo tutti gli attori indispensabili per partire nel modo giusto può essere più o meno facile, partendo da un’azione di lift-off che consente di allineare tutti sugli obiettivi e sulle motivazioni che spingono ad intraprendere il nuovo percorso (ne abbiamo parlato qui: l’ossimoro implicito dell’ortodossia innaturale nel cambiamento stagnante).
Se in questo percorso ci allontaniamo da un approccio empirico, non caratterizzando la nostra azione in chiave inspect-and-adapt, rischiamo di divergere rispetto alla realtà, chiudendoci nella nostra iron tower e provocando un lassismo generale: in pratica le persone “tollerano il cambiamento” perché imposto e spinto da qualcuno giornalmente, ma non vedono l’ora di tornare a dedicarsi alle cose che, a loro avviso, sono importanti. La regressione è praticamente dietro l’angolo.
Alcuni esempi concreti riguardano l’adozione di uno specifico framework. Si pensi ad esempio a Scrum, che, seppur un ottimo punto di partenza in moltissimi casi, potrebbe non essere idoneo a supportare alcuni contesto specifico: se non si ha un Product Backlog in quanto tale, e i work item sono comunicato durante l’iterazione o a ridosso dell’inizio di essa, non è forse meglio operare in modo diverso? Ha ancora senso stimare in tal caso a livello team? Possiamo utilizzare il tempo relativo per trovare una forma diversa di condivisione delle informazioni o per realizzare “cose”? Riflessioni, non suggerimenti... ma di stiame si può morire :-)
Se le diverse azioni restano un mero esercizio stilistico, le Persone cominceranno a farsi scivolare addosso quanto si sta provando ad applicare con fatica, andando a vanificare gli investimenti relativi, ma, soprattutto, perdendo un’occasione per rinvigorire la propria organizzazione e rispondere alle nuove sfide.
Il messaggio è quindi eloquente: concentrarsi sempre e comunque su quanto porta realmente Valore nell’azione di cambiamento, abbandonando stereotipi e i “verbi”, senza chiaramente dimenticare di far tesoro della propria esperienza unita ad un forte background relativo.
Stay tuned J
