5 domande sulla trasformazione agile e il nostro approccio: AR si racconta

In Agile Reloaded abbiamo riflettuto su 5 domande fondamentali da porsi sulla trasformazione agile. Le risposte che troverete nell’articolo sono formulate a partire dalle esperienze vissute dai nostri Agile Coach con i clienti.

Ma siamo andati oltre e abbiamo deciso di raccontarci.
Ragionare sui quesiti ci ha spinto a condividere il nostro approccio alla trasformazione agile, quello che abbiamo visto funzionare e le cose che non sono andate bene. Siamo certi che i nostri amici, colleghi e competitor abbiano approcci altrettanto validi, ma è importante per noi capire le complessità per l’organizzazione legate alla trasformazione. Il confronto e la condivisione di esperienze e punti di vista ci aiuta reciprocamente ad approfondire ulteriormente pensieri sul tema e ad arricchirci di spunti e strumenti nuovi.

Nota: una versione dell’articolo più approfondita ed esaustiva sui temi trattati è presente nel blog di Mokabyte qui.

Ci sono interrogativi che aiutano ad analizzare il perché, gli obiettivi e il dove si vuole andare quando si intende estendere il mindset e le pratiche agili ai diversi reparti dell’organizzazione. Vediamoli insieme.

Perché si affronta una trasformazione agile aziendale?

A questa domanda riceviamo, nella maggior parte dei casi, risposte comuni e condivisibili. Eccone alcune:

• perché cambia il mondo che ci circonda e, quindi, cambiano le esigenze dell’organizzazione stessa;
• perché aumenta la complessità e nasce la necessità di trovare modi più semplici di fare le cose, magari introducendo la cultura sperimentale;
• perché non funzionano più i modelli di relazione precedenti;
• sarcasticamente, perché “va di moda”.

In Agile Reloaded condividiamo tutti questi punti, con un focus particolare sul tema della complessità, ma ci sentiamo di aggiungerne altri più naive. Spesso una trasformazione Agile si fa: 

• per avere un’organizzazione che sappia rispondere alle necessità di business e costruire soluzioni;
• perché rende attrattivi sul mercato, attirando nuovi clienti e nuovi talenti;
• perché spesso non si conosce il manifesto, i principi e i valori. Sono ignote le basi da cui poter fare una riflessione vera e profonda sul significato del mindset agile e della possibile applicazione nel proprio contesto organizzativo. Come spiegato nel punto precedente, affermare che si sta mettendo in atto una trasformazione è appealing nel mercato.

Le pratiche agili sono nate per soddisfare i bisogni. Quali?

Quando chiediamo ai clienti perché vogliono fare propri i principi agili – domanda che già da sola apre a una galassia di possibili conversazioni – e quali benefici si aspettano, otteniamo un elenco piuttosto tipico di risposte, che trovate nell’articolo completo su MokaByte.

A noi piace sinteticamente dire che le metodologie agili aiutano a ridurre il rischio di: 

• fare le cose sbagliate, cioè essere capaci di capire prima quali sono le cose sbagliate, in modo da non farle e focalizzare le energie su ciò che veramente serve all’organizzazione, portando sempre più valore nel lungo periodo;
• fare le cose male, grazie all’introduzione delle iterazioni brevi, del feedback continuo e dei team verticali capaci di seguire il processo end-to-end del prodotto;
• fare le cose troppo tardi: la customer centricity (focus sul cliente) riduce il time-to-market e gli sprechi, puntando sulla qualità delle tecnologie e delle persone coinvolte. 

Trasformare un’organizzazione significa creare un’organizzazione che apprende e che si adatta al contesto che cambia, implementando meccanismi che permettono di rispondere alle nuove esigenze e/o problematiche. Per un approfondimento sul tema “organizzazioni che apprendono”, vi consigliamo la lettura dell’articolo “Learning Organizations”.

Su cosa  potremmo agire concretamente per trasformare l’organizzazione?

Tra le tante immagini che ci vengono alla mente, troviamo interessanti queste affermazioni tratte dalle nostre esperienze:

• Introdurre una logica end-to-end forte: monitorare tutta la filiera di creazione del prodotto dall’ideazione fino al rilascio, tenendo sotto controllo il valore rilasciato ad ogni iterazione;
• Agire sul design organizzativo: favorire modelli che permettono la collaborazione tra i team; facilitare la nascita di team funzionali, in grado di rilasciare prodotti (o parti di tali) funzionanti in modo autonomo lungo tutta la filiera;
• Accorciare i cicli di lavorazione, rilasciare il prodotto in modo incrementale: aumentare la frequenza dei rilasci in produzione dando all’utente qualcosa di utilizzabile con successo e soddisfazione; spezzare un progetto molto lungo in parti più piccole in maniera iterativa e incrementale;
• Trasformare una sola area, anche come input per poi trasformare tutta l’organizzazione.

Come si fa una trasformazione Agile? L’approccio Agile Reloaded

Rispondere a questa domanda non è semplice e non c’è una risposta universale. Quello che segue è l’approccio di AR al coaching (e quindi alla trasformazione).

Fasi di approccio al coaching AR

Più che fasi che hanno un inizio e una fine definiti, quelli illustrati di seguito sono dei passaggi graduali della relazione tra cliente e coach: 

1. All’inizio dell’ingaggio, affianchiamo il cliente nell’individuare le attività da fare e stabilire la strategia partendo così dalle basi; 
2. Nel corso dell’apprendimento del mindset e pratiche agili, i diversi gruppi di lavoro e le altre figure coinvolte cominciano a sperimentare e agiscono in prima persona;
3. Gradualmente, le persone interne all’organizzazione iniziano ad avere un ruolo attivo e i nostri coach passano ad essere osservatori e facilitatori;
4. A tendere, l’agile coach può uscire di scena e il cliente inizia a usare gli strumenti e le competenze per affrontare in autonomia le sfide e le problematiche del mercato.

La best practice Agile Reloaded

L’Agile Manifesto è universale e uguale per tutti, ma il modo di adottarne i principi e i valori cambia da organizzazione a organizzazione. Il nostro obiettivo è lavorare insieme per trovare l’applicazione giusta al contesto di riferimento.
Così, negli anni, abbiamo pensato, sperimentato e implementato quella che possiamo definire una best practice, rappresentata nella seguente tabella.

Quando si affronta una trasformazione, le figure coinvolte nell’intera organizzazione hanno ruoli e obiettivi differenti. Lavoriamo, così, su tre livelli e con tre diversi interlocutori: 

• Airplane view – top management: con queste figure concordiamo un piano di trasformazione e la roadmap di trasformazione;
• Helicopter view – middle management, project manager, product owners, product manager: aspetti più operativi e, in particolare, di servizi e prodotti da rilasciare;
• Ground view – team operativi: a partire da un assessment sulla loro operatività per capire le necessità, lavoriamo insieme per supportare la loro autonomia attraverso la formazione e il coaching.

La trasformazione… Iterativa e incrementale

Quando lavoriamo sulla roadmap, utilizziamo strumenti ispirati al framework Scrum. Per esempio, creiamo un backlog della trasformazione, concordando sulle attività insieme ai nostri interlocutori e implementandolo a ogni sprint della durata di due o quattro mesi.
Ogni attività deve avere una definition of ready e una definition of done. Il Backlog based transformation viene costruito collaborando con le persone che ci hanno chiamato a partire dall’analisi delle necessità del loro contesto.

Cosa può bloccare o aiutare una trasformazione agile?

Nella nostra esperienza, abbiamo potuto osservare che la mancanza di alcuni requisiti o la presenza di impedimenti possono bloccare la trasformazione agile, più che una errata impostazione o la carenza di strumenti e conoscenze.

Ecco alcuni fattori bloccanti: 

• Mancanza di leadership: mancanza di una guida a supporto dei gruppi auto-organizzati;
• Top management e/o middle management non coinvolti: è importante partire con una definita e condivisa vision della trasformazione, coinvolgendo anche gli stakeholders e i relativi bisogni;
• Bassa qualità e poco coinvolgimento dei fornitori: la mancanza di competenze (es ruoli e pratiche di Scrum) e di esperienza pregressa possono trasformare lo sviluppo di un prodotto con pratiche ispirate ai principi agili in qualcosa di simile al vecchio Waterfall mascherato di agile;
• Pratiche di Agile washing: applicazione di facciata degli strumenti e delle pratiche agili senza averne compreso il significato o senza che queste rappresentino un reale cambio di approccio.

Di seguito, invece, un semplice elenco dei fattori che abilitano la trasformazione agile:

• La cultura della trasparenza: condivisione degli obiettivi organizzativi e dei risultati attesi della trasformazione; essere chiari su quello che ci aspettiamo dalle persone, sulle competenze e carriere, su cosa ci aspettiamo che diventi dopo la trasformazione e quali sono gli impatti sulle persone;
• La cultura della qualità dei fornitori, disposti a sperimentare insieme, imparare e migliorare in una logica di reale partnership;
• Creare un contesto in cui formazione, tempo per imparare, e sperimentare siano riconosciuti e supportati;
• Management coinvolto e convinto: il supporto del management è quindi essenziale non tanto per “comandare” come portare avanti la trasformazione ma piuttosto per la creazione di un contesto in cui si trovi spazio per proporre soluzioni e sperimentare;
• Leadership forte e presente: Il ruolo del capo-condottiero (“io so come si fa”) si viene a sostituire con quello del leader (o meglio della leadership diffusa) che abilita la collaborazione e creazione delle persone.

Avere il tempo per farla

Concludiamo l’articolo con un’ultima riflessione dall’apparenza banale ma che porta con sé aspetti importanti: per fare una trasformazione agile serve il tempo.

Serve tempo per lavorare: Per cambiare l’organizzazione serve tempo dedicato, di qualità, focalizzato, tolto ad altre cose.

Serve tempo per capire i principi agili: la semplicità dei principi del Manifesto Agile nasconde una profondità non banale. E’ necessario provare a mettere in pratica, capire quello che si sta facendo, comprenderne il significato, assimilare e far proprio il senso.

Serve tempo per capire se stessi: “Agile non ti porta all’eccellenza, ma mette in luce il tuo livello di inefficienza”. E’ questa una delle frasi più importanti di tutta la filosofia agile. Le metodologie agili sono specchi che vi faranno vedere la vostra organizzazione con occhi differenti. Quello che vedrete non è detto che riuscirete a comprenderlo immediatamente.

Serve tempo per farvi capire da chi vi sta aiutando nella trasformazione: i partner, fornitori, un team di agile coach, di consulenti, di formatori, hanno bisogno di lavorare con voi per osservare, per capire, per assimilare il vostro modo di lavorare e la vostra cultura. Dovrete scoprire insieme la soluzione giusta per voi.