Scalabilità agile a team di grandi dimensioni

Le parole grandi e Agile non vengono spesso usate nella stessa frase. Le organizzazioni di grandi dimensioni hanno guadagnato la reputazione di rallentare il movimento. Tuttavia, questo sta cambiando. Molte organizzazioni software di grandi dimensioni stanno effettuando correttamente la trasformazione in Agile. Stanno imparando a ridimensionare i principi Agile con o senza framework diffusi, ad esempio SAFe, LeSS o Nexus.

Microsoft usa Agile per creare prodotti e servizi forniti con il marchio Azure DevOps. Questo gruppo ha 35 team di funzionalità che vengono rilasciati in produzione ogni tre settimane.

Ogni team all'interno di Azure DevOps è proprietario delle funzionalità dall'inizio alla fine e oltre. Sono proprietari di relazioni con i clienti. Gestiscono il proprio backlog del prodotto. Scrivono e controllano 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 risondono i problemi del sito live.

In base ai principi Agile, i team autonomi sono più produttivi. Un'organizzazione Agile vuole che i team abbiano il controllo sull'esecuzione quotidiana. Ma l'autonomia senza allineamento provocherebbe il caos. Decine di team che lavorano in modo indipendente non producono un prodotto unificato di alta qualità. L'allineamento offre ai team lo scopo e garantisce che soddisfino gli obiettivi dell'organizzazione. Senza allineamento, anche i team con prestazioni migliori non riuscirebbero.

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

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

Definire una tassonomia

Un team Agile e la più grande organizzazione Agile a cui appartiene, hanno bisogno di un backlog chiaramente definito per avere successo. I team avranno difficoltà a riuscire se gli obiettivi dell'organizzazione non sono chiari.

Per definire obiettivi chiari e dichiarare il modo in cui ogni team contribuisce a loro, l'organizzazione deve definire una tassonomia. Una tassonomia chiaramente definita crea la denominazione per un'organizzazione.

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

Epiche

Epics descrive le iniziative importanti per il successo dell'organizzazione. Le epiche possono portare a termine diverse squadre e diversi sprint, ma non sono senza fine. Le epiche hanno un obiettivo chiaramente definito. Una volta raggiunto, l'epica viene chiusa. Il numero di epiche in corso deve essere gestibile per mantenere l'organizzazione focalizzata. Le epiche sono suddivise in funzionalità.

Funzionalità

Le funzionalità definiscono 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. Il completamento delle funzionalità può richiedere più sprint, ma deve essere ridimensionato 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 fornire per creare una funzionalità. Il team suddivide la funzionalità in parti incrementali. Una singola storia completata potrebbe non fornire un valore significativo al cliente. Tuttavia, una storia completata rappresenta il software di qualità di produzione. Le storie sono l'unità di lavoro del team. Il team definisce le storie necessarie per completare una funzionalità. Facoltativamente, le storie si suddividono in attività.

Attività

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

Iniziative

Questa tassonomia non è un sistema unico. Molte organizzazioni introducono un livello superiore alle epiche chiamate iniziative.

I nomi di ogni livello possono essere personalizzati per l'organizzazione. Tuttavia, i nomi definiti in precedenza (epiche, caratteristiche, storie) sono ampiamente usati nel settore.

Linea di autonomia

Una volta impostata una tassonomia, l'organizzazione deve disegnare una linea di autonomia. La linea di autonomia è il punto in cui la proprietà del livello passa dalla gestione al team. La gestione non interferisce con i livelli di proprietà del team.

L'esempio seguente mostra la linea di autonomia disegnata di seguito. La gestione possiede epiche e caratteristiche, che forniscono l'allineamento. I team possiedono storie e attività e hanno autonomia su come vengono eseguiti.

In questo esempio, la gestione non indica al team come scomporre storie, pianificare sprint o eseguire il lavoro.

Il team, tuttavia, deve garantire che l'esecuzione sia allineata agli obiettivi della gestione. Anche se un team possiede il proprio backlog di storie, deve allinearsi al backlog con le funzionalità assegnate.

Pianificazione

Per ridimensionare la pianificazione Agile, un team deve avere un piano per ogni livello della tassonomia. Tuttavia, è importante eseguire l'iterazione e aggiornare il piano. Questo processo è detto pianificazione delle onde in sequenza.

Il piano fornisce la direzione per un periodo di tempo fisso con la calibrazione prevista a intervalli regolari. Ad esempio, un piano di 18 mesi può essere calibrato ogni sei mesi.

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

Visione

La visione viene espressa attraverso epiche e imposta la direzione a lungo termine dell'organizzazione. Le epiche definiscono ciò che l'organizzazione vuole completare nei prossimi 18 mesi. La gestione possiede il piano e la calibra ogni sei mesi.

La visione viene presentata in una riunione a tutte le mani. Poiché la visione è progettata per essere ambiziosa e molto può cambiare in quel periodo di tempo, aspettarsi di realizzare circa il 60% della visione.

Stagione

Una stagione è descritta attraverso caratteristiche e imposta la strategia per i prossimi sei mesi. Le funzionalità determinano ciò che l'organizzazione vuole accendere per i propri clienti. La gestione possiede il piano stagionale e presenta la visione e i piani stagionali in una riunione a tutte le mani. Tutti i piani del team devono essere allineati al piano stagionale della gestione. Aspettatevi di realizzare circa l'80% del piano stagionale.

Piano di 3 sprint

Il piano di 3 sprint definisce le storie e le funzionalità che il team terminerà nei tre sprint successivi. Il team possiede il piano e lo calibra 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 eseguire circa il 90% del piano di 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 ottenere la massima trasparenza. Il piano include ciò che il team ha ottenuto nello sprint precedente e il relativo obiettivo per lo sprint successivo. Si prevede di eseguire circa il 95% del piano sprint.

Linea di autonomia

In questo esempio, la linea di autonomia viene tracciata per mostrare dove i team hanno un'autonomia di pianificazione.

Come indicato in precedenza, la gestione non estende la proprietà al di sotto della linea di autonomia. La gestione fornisce indicazioni sull'uso dei piani di visione e stagione e quindi offre ai team l'autonomia di creare piani di 3 sprint e sprint.

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

Una chat di funzionalità è una riunione a bassa cerimonia in cui ogni team presenta il piano di 3 sprint per la gestione. Questa riunione garantisce che i piani del team siano allineati agli obiettivi dell'organizzazione. Aiuta anche la gestione a rimanere informati su ciò che sta facendo il team. Mentre il piano di 3 sprint è calibrato ogni sprint, le chat di funzionalità vengono mantenute in base alle esigenze, in genere ogni sprint uno-a-tre.

Una riunione di chat di funzionalità alloca 15 minuti a ogni team. Con 12 team di funzionalità, queste riunioni possono essere pianificate per durare circa tre ore. Ogni team prepara un mazzo di 3 diapositive, con le diapositive seguenti:

Funzionalità

La prima diapositiva delinea le caratteristiche che il team si accenderà nei tre sprint successivi.

Debito

La diapositiva successiva descrive come il team gestisce il debito tecnico. Il debito è tutto ciò che non soddisfa i bar di qualità della gestione. Il direttore dell'ingegneria imposta le barre di qualità, che sono uguali per tutti i team (allineamento). Le barre di qualità di esempio includono il numero di bug per ogni tecnico, la percentuale di unit test superati e gli obiettivi di prestazioni.

Problemi e dipendenze

I problemi e le dipendenze elencati nella diapositiva finale includono qualsiasi elemento che influisca sullo stato del team, ad esempio i problemi che il team non può risolvere o dipendenze da altri team che richiedono l'escalation.

Ogni team presenta le diapositive direttamente alla gestione. Il team presenta il modo in cui il piano di 3 sprint è allineato al piano stagionale di 6 mesi. La leadership pone domande chiare e suggerisce cambiamenti nella direzione. Possono anche richiedere riunioni di completamento per risolvere i problemi più profondi.

Se il piano di un team non riesce ad allinearsi alle aspettative della gestione, la gestione potrebbe richiedere un nuovo piano. In questo raro evento, il team ri-pianifica e pianifica una seconda chat di funzionalità per esaminarla.

Trust: la colla che mantiene l'allineamento e l'autonomia insieme

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

• La gestione deve fidarsi dei team per fare la cosa giusta. Se la gestione non si fida dei team, non darà autonomia ai team.

• Un team guadagna fiducia fornendo costantemente codice di alta qualità. Se i team non sono affidabili, la gestione non darà loro autonomia.

La gestione deve fornire piani chiari per consentire ai team di allinearsi e quindi fidarsi dei team da eseguire. I team devono allineare i propri piani all'organizzazione ed essere eseguiti in modo affidabile.

Man mano che le organizzazioni guardano alla scalabilità di scenari Agile a più grandi, la chiave consiste nel fornire autonomia ai team garantendo al tempo stesso l'allineamento con gli obiettivi dell'organizzazione. I blocchi predefiniti critici sono chiaramente definiti e una cultura di fiducia. Una volta che un'organizzazione ha questa base, troveranno che Agile può essere ridimensionato in modo ottimale.

Passaggi successivi

Ci sono molti modi per un team di qualsiasi dimensione per iniziare a vedere i vantaggi oggi. Vedere alcune di queste procedure che vengono ridimensionate.

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

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