Ridimensionamento di Agile in team di grandi dimensioni

Molte persone non usano le parole big e Agile nella stessa frase. Le grandi organizzazioni di software hanno ottenuto la reputazione di essere grandi e lente a cambiare. Tuttavia, questa modifica è in continua evoluzione. Molte organizzazioni di grandi dimensioni stanno effettuando la trasformazione in Agile. Stanno imparando a scalare i principi Agile con i nostri senza framework diffusi, ad esempio SAFe, LeSS o Nexus.

Uno di questi gruppi, l'Azure DevOps microsoft, crea i prodotti e i servizi forniti con il marchio Azure DevOps. Hanno 35 team di funzionalità che vengono rilasciati in produzione ogni tre settimane.

Ogni team all'Azure DevOps è proprietario di tutto, dall'inizio alla fine e oltre. Sono proprietari delle relazioni con i clienti. Gestiscono il proprio backlog del prodotto. Scrivono e archiviano il codice nel ramo di produzione. Ogni tre settimane, il ramo di produzione viene distribuito e la versione diventa pubblica. I team monitorano quindi l'integrità del sistema e correggino i problemi del sito live.

In base ai principi Agile, i team autonomi sono più produttivi. Un'organizzazione Agile vuole che i team si dia autonomia all'esecuzione quotidiana. Ma l'autonomia senza allineamento potrebbe causare il chaos. Decine di team che lavorano in modo indipendente non produrrebbe un prodotto unificato di alta qualità. L'allineamento offre ai team lo scopo. L'allineamento garantisce che i team soddisfino gli obiettivi aziendali. Senza allineamento, anche i team con le prestazioni migliori avrebbero esito negativo.

Per ridimensionare Agile, è necessario abilitare l'autonomia per il team garantendo al tempo stesso l'allineamento con l'organizzazione.

Per gestire il equilibrio tra allineamento e autonomia, i leader DevOps devono definire una tassonomia, definire un processo di pianificazione e usare le chat di funzionalità.

Definizione di una tassonomia

Una tassonomia chiaramente definita definisce la nomenclatura per un'organizzazione.

Un team Agile deve avere un backlog chiaramente definito per avere esito positivo. Anche l'organizzazione Agile più grande a cui appartiene. Se gli obiettivi dell'organizzazione non sono chiari, i team avranno difficoltà a raggiungere il successo.

Un'organizzazione Agile deve definire chiaramente i propri obiettivi e stabilire in che modo ogni team deve contribuire a tali obiettivi. A tale scopo, l'organizzazione deve definire una tassonomia.

Una tassonomia comune è epiche, funzionalità, storie e attività.

Tassonomia comune

Epiche

Le epiche dichiarano iniziative importanti per il successo dell'organizzazione. Le epiche possono richiedere diversi team e diversi sprint, ma non sono senza fine. Le epiche hanno un obiettivo chiaramente definito. Una volta ottenuta, l'epica viene chiusa. Il numero di epiche in corso deve essere gestibile per mantenere l'organizzazione concentrata. Le epiche sono suddivise in funzionalità.

Funzionalità

Le funzionalità definiscono le nuove funzionalità necessarie per realizzare l'obiettivo di un'epica. Le funzionalità sono l'unità di rilascio; rappresentano ciò che viene rilasciato al cliente. Le note sulla versione pubblicate possono essere compilate in base all'elenco delle funzionalità completate di recente. Le funzionalità possono richiedere più sprint per il completamento, ma devono essere ridimensionate per garantire un flusso coerente di valore per il cliente. Le funzionalità sono suddivise in storie.

Storie

Le storie definiscono il valore incrementale che il team deve offrire per creare una funzionalità. Il team suddivide la funzionalità in parti incrementali. Una singola storia completata potrebbe non fornire valore significativo al cliente. Tuttavia, una storia completa rappresenta un software di qualità della produzione. Le storie sono l'unità di lavoro del team. Il team definisce le storie necessarie per completare una funzionalità. Facoltativamente, le storie sono suddivise in attività.

Attività

Le attività definiscono il lavoro necessario per completare una storia.

Iniziative

Questa tassonomia non è adatta a tutti. Molte organizzazioni introducono un livello superiore alle epiche denominate iniziative.

Tassonomia comune con iniziative

I nomi di ogni livello possono essere personalizzati per l'organizzazione. Tuttavia, i nomi definiti in precedenza (epiche, funzionalità, storie) sono abbastanza vicini a essere standard del settore.

Linea di autonomia

Dopo aver impostato una tassonomia, definire la linea di autonomia. La linea di autonomia è il punto in cui il team è il proprietario chiaro e la gestione non interferisce.

Nell'esempio seguente è stata disegnata la linea di autonomia sotto le funzionalità. La gestione è proprietaria di epiche e funzionalità, che forniscono l'allineamento. I team sono proprietari di storie e attività e hanno autonomia sulla modalità di esecuzione.

Linea di autonomia

La gestione non estende la proprietà sotto la linea di autonomia. Ad esempio, la gestione non spiega al team come scomporre le storie, pianificare lo sprint o eseguire il proprio lavoro.

Il team, tuttavia, deve garantire che l'esecuzione sia allineata con gli obiettivi della gestione. Mentre un team è proprietario del backlog delle storie, deve allineare il backlog con le funzionalità assegnate.

Pianificazione

Per ridimensionare la pianificazione Agile, un team deve avere un piano per ogni livello della tassonomia. La pianificazione delle onde in sequenza è fondamentale. Il piano fornisce la direzione per un periodo di tempo fisso con calibrazione prevista a intervalli regolari. Ad esempio, è possibile calibrare un piano di 18 mesi ogni 6 mesi.

Ecco un esempio di metodi di pianificazione per ogni livello di tassonomia: epiche, funzionalità, storie, attività.

Intervalli di pianificazione

Visione

La visione viene espressa tramite epiche e imposta la direzione a lungo termine dell'organizzazione. La gestione è proprietaria del piano e lo calibra ogni 6 mesi. Le epiche definiscono ciò che l'organizzazione vuole completare nei prossimi 18 mesi. La visione viene presentata in una riunione a mani tutte le mani. Poiché la visione è stata concepita per essere ambiziosa e può cambiare molto per un'organizzazione Agile in questo periodo di tempo, prevedere di realizzare circa il 60% della visione.

Stagione

Una stagione viene descritta tramite funzionalità e definisce la strategia per i 6 mesi successivi. Le funzionalità determinano ciò che l'organizzazione vuole far luce per i clienti. La gestione è proprietaria del piano stagionale e presenta la visione e i piani stagionali in una riunione a mani proprie. Tutti i piani del team devono essere allineati al piano stagionale della gestione. Si prevede di raggiungere circa l'80% del piano stagionale.

Piano a 3 sprint

Il piano a 3 sprint definisce le storie e le funzionalità che il team terminerà nei 3 sprint successivi. Il team è proprietario del piano e lo calibra a ogni sprint. Ogni team presenta il proprio piano di gestione tramite la chat delle funzionalità (vedere di seguito). Il piano specifica il modo in cui l'esecuzione del team è allineata al piano stagionale di 6 mesi. Si prevede di raggiungere circa il 90% del piano a 3 sprint.

Piano sprint

Il piano sprint definisce le storie e le funzionalità che il team terminerà nello sprint successivo. Il team è proprietario del piano sprint e lo invia tramite posta elettronica all'intera organizzazione per la massima trasparenza. Il piano include le attività completate dal team nello sprint passato e l'attenzione per lo sprint successivo. Si prevede di raggiungere circa il 95% del piano sprint.

Linea di autonomia

La linea di autonomia viene disegnata per mostrare dove i team hanno l'autonomia di pianificazione. Il processo di pianificazione precedente traccia la linea di autonomia come segue:

Un'altra visione della linea di autonomia

Come indicato in precedenza, la gestione non estende la proprietà al di sotto della linea di autonomia. Forniscono indicazioni che usano la visione e i piani stagionali e offrono ai team l'autonomia per creare piani a 3 sprint e sprint.

Chat con funzionalità: dove l'autonomia soddisfa l'allineamento

Una chat di funzionalità è una riunione a bassa premiazione in cui ogni team presenta il proprio piano in 3 sprint alla gestione. Questa riunione garantisce che i piani del team siano allineati con gli obiettivi dell'organizzazione. Consente inoltre alla gestione di rimanere informati sulle attività del team. Mentre il piano a 3 sprint viene calibrato ogni sprint, le chat delle funzionalità vengono mantenute in base alle esigenze, in genere ogni 1-3 sprint.

Una riunione di chat con funzionalità alloca 15 minuti a ogni team. Con dodici team di funzionalità, queste riunioni possono essere pianificate in circa tre ore. Ogni team prepara una presentazione a 3 diapositive con le diapositive seguenti:

Funzionalità

Le funzionalità che il team si accenderà nei prossimi 3 sprint.

Debito

Modalità di gestione del debito tecnico da parte del team. Il debito è qualsiasi cosa che non soddisfi le barre di qualità della gestione. Il direttore della progettazione imposta le barre di qualità, che sono le stesse per tutti i team (allineamento). Le barre di qualità di esempio # includono bug/tecnico, % unit test superati e obiettivi di prestazioni.

Problemi/dipendenze

Tutto ciò che influisce sullo stato di avanzamento del team. Problemi che il team non può risolvere o le dipendenze da altri team che necessitano di escalation. Ogni team presenta le diapositive direttamente alla gestione. Il team presenta l'allineamento del piano a 3 sprint al piano stagionale di 6 mesi. La leadership pone domande chiari e suggerisce cambiamenti nella direzione. Possono anche richiedere riunioni di follow-up per risolvere problemi più approfonditi.

Se il piano di un team non si allinea alle aspettative del management, il management può richiedere un nuovo piano. In questo raro evento, il team ripeta il piano e pianifica una seconda chat di funzionalità per esaminarla.

Attendibilità: il glue che tiene insieme l'allineamento e l'autonomia

Quando si pratica Agile su larga scala, la fiducia è una strada bidirezionale:

La gestione deve considerare attendibili i team per fare la cosa giusta. Se la gestione non considera attendibili i team, non offrirà ai team l'autonomia.

Un team si affida costantemente alla distribuzione di codice di alta qualità. Se i team non sono attendibili, la gestione non offrirà loro autonomia.

La gestione deve fornire piani chiari per consentire ai team di allinearsi ai team e di considerarne attendibile l'esecuzione. I team devono allineare i propri piani all'organizzazione ed eseguirne l'esecuzione in modo attendibile.

Poiché le organizzazioni vogliono ridimensionare Agile in scenari più grandi, la chiave è offrire ai team l'autonomia assicurandosi al tempo stesso che siano allineati agli obiettivi dell'organizzazione. I blocchi predefiniti critici sono chiaramente definiti come proprietà e impostazioni cultura di attendibilità. Una volta che un'organizzazione ha posto queste basi, scoprirà che Agile può essere ridimensionato molto bene.

Passaggi successivi

Un team di qualsiasi dimensione può iniziare a visualizzare i vantaggi in molti modi. Vedere alcune di queste procedure che ridimensionano.

Informazioni sulle funzionalità Azure DevOps per la gestione del portfolio e la visibilità tra i team.

Microsoft è una delle più grandi aziende Agile del mondo. Altre informazioni su come Microsoft ridimensiona la pianificazione devOps.