Adottare una cultura Agile

Se c'è una lezione da imparare dall'ultimo decennio di "trasformazioni Agile", è che non esiste una soluzione adatta a tutte le dimensioni per adottare o implementare un approccio Agile . Ogni organizzazione ha esigenze, vincoli e requisiti diversi. Ciecamente seguendo una prescrizione non porterà al successo.

Il movimento Agile consiste nel trovare continuamente modi per migliorare la pratica di creazione di software. Non si tratta di un perfetto standup quotidiano o retrospettivo. Invece, si tratta di creare una cultura in cui la cosa giusta accade più spesso di non. Le attività come standup e retrospettive hanno il loro posto, ma non cambieranno la cultura di un'organizzazione.

Questo articolo descrive in dettaglio gli elementi fondamentali che ogni organizzazione deve creare una mentalità e una cultura Agile. Le raccomandazioni non dovrebbero essere seguite ciecamente. Ogni organizzazione deve applicare ciò che ha senso in un determinato ambiente.

Pianificazione e ritmo

Non c'è una lunghezza di sprint perfetta. I team hanno avuto successo con lunghezze di sprint che vanno da una a quattro settimane. Ciò che conta di più è la coerenza.

Selezionare una lunghezza sprint che funzioni per le impostazioni cultura, il prodotto e il desiderio di fornire aggiornamenti dell'organizzazione. Ad esempio, la divisione Developer Tools di Microsoft (circa 6.000 persone) funziona in sprint di tre settimane. Il team di leadership non ha scelto questa lunghezza dello sprint; ha ricevuto feedback diretto dai team di progettazione. L'intera divisione opera su questo programma sprint di tre settimane. Gli sprint sono diventati l'heartbeat dell'organizzazione. Ora ogni squadra marcia al ritmo dello stesso tamburo.

È importante scegliere una lunghezza sprint e attenersi a esso. Se sono presenti più team Agile, tutti devono usare la stessa lunghezza dello sprint. Se il feedback determina una modifica, sarà receptive. Sarà chiaro quando il termine giusto è in vigore.

Cultura della spedizione

Peter Provost, Principal Group Program Manager presso Microsoft, ha detto che "Non è possibile ingannare la spedizione". La semplicità e la verità di tale affermazione sono un elemento fondamentale della cultura Agile. Ciò che Peter significa che la spedizione del software ti insegnerà le cose che non puoi e non capirai a meno che non stai effettivamente spedindo il tuo software.

La natura umana è ritardare o evitare di fare cose fino a quando non è assolutamente necessario. Questo non potrebbe essere più vero quando si tratta di sviluppo di software. I bug di Teams puntano alla fine del ciclo, non pensano alla configurazione o all'aggiornamento fino a quando non vengono forzati e in genere evitano elementi come la localizzazione e l'accessibilità laddove possibile. Quando emerge questo modello, i team creano un debito tecnico che dovrà essere pagato in un secondo momento. La spedizione richiede il pagamento di tutto il debito. Non puoi ingannare la spedizione. Per stabilire una cultura Agile, iniziare provando a spedire il prodotto alla fine di ogni sprint. Non sarà facile in un primo momento, ma quando un team lo tenta, scopre rapidamente tutte le cose che dovrebbero accadere, ma non lo sono.

Team integri

Non c'è una ricetta per il team Agile perfetto. Tuttavia, alcune caratteristiche chiave rendono il successo molto più facile da raggiungere.

Co-individuare i team ogni volta che possibile

Un team può trovare successo con le persone distribuite in aree geografiche diverse? Sì, ma è più difficile. Quando le persone si trovano nella stessa stanza e si trovano nella stessa stanza, le conversazioni giuste tendono a verificarsi. È comunque possibile avere successo con i team che si trovano in tutto il mondo e fusi orari diversi. Ma la stessa squadra non avrebbe un vantaggio senza tutti questi ostacoli?

Mantenere intatti i team per un periodo di tempo ragionevole

Consentire ai team di padroneggiare l'arte della creazione di software insieme. Quando i team sono strapazzati, qualsiasi chimica sviluppata viene interrotta. A volte è opportuno riorganizzare, ma i team sono in genere più produttivi quando hanno tempo per imparare a lavorare insieme. Come linea guida, provare a mantenere intatti i team per almeno 12 mesi.

Bilanciare il carico del lavoro, non le persone

A volte i team si trovano indietro e hanno bisogno di aiuto. Una tattica comune per risolvere questo problema consiste nel dare una persona da una squadra a un'altra. Tuttavia, questo può essere controproducente. Una soluzione migliore consiste nel bilanciare il carico del lavoro in un altro team, anziché bilanciare il carico tra di loro. Tirare una persona da un team per aiutare un altro a interrompere entrambe le squadre e può frustrare la persona spostata, anche se temporanea. Tutto ciò influisce sulla produttività del team e, più probabilmente, influisce negativamente sulla possibilità di tornare in base alla pianificazione.

Il lavoro di bilanciamento del carico invece delle persone consente a un team già stabilito di eseguire e aiutare. Diventa una conversazione sulle priorità, non una conversazione sulle persone.

Consentire ai team di possedere aree di funzionalità, non livelli di architettura

Cercare di creare team verticali che possiedono aree di funzionalità. Questi team sono responsabili di tutte le attività necessarie per aggiungere funzionalità all'area, dal database alle modifiche dell'interfaccia utente. Il team ha la possibilità di offrire e possedere un'esperienza end-to-end.

Quando i team orizzontali possiedono livelli di architettura, nessun singolo team è responsabile dell'esperienza end-to-end. L'aggiunta di una funzionalità richiede il coordinamento di più team e richiede un livello superiore di gestione delle dipendenze. Per risolvere i bug è necessario che più team esaminino se sono proprietari del codice necessario per correggere il bug. I bug vengono ignorati quando i team determinano che non è il bug e lo assegnano a un altro team.

I team delle funzionalità non presentano questi problemi. La proprietà e la responsabilità sono chiare. Potrebbe esserci un posto per alcuni team basati sull'architettura. Tuttavia, i team incentrati verticalmente sono più efficaci.

Passaggi successivi

Quando i team intraprendono la propria trasformazione Agile, tenere presenti questi principi fondamentali. Tenere presente che non esiste una singola ricetta che funzionerà per ogni organizzazione. Le trasformazioni Agile sono un percorso. Apportare modifiche e imparare da esse. Nel corso del tempo l'organizzazione svilupperà la cultura Agile necessaria.

Microsoft è una delle più grandi aziende Agile al mondo. Altre informazioni su come Microsoft ha adottato una cultura Agile per la pianificazione di DevOps.

Informazioni su come Azure DevOps consente ai team di adottare e ridimensionare una cultura Agile.