Ridimensionamento di Agile in team di grandi dimensioni

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

In Microsoft, un'organizzazione di questo tipo usa Agile per creare prodotti e servizi forniti con il marchio Azure DevOps. Questo gruppo ha 35 team di funzionalità che vengono rilasciati nella produzione ogni tre settimane.

Ogni team all'interno di Azure DevOps possiede funzionalità dall'inizio alla fine e oltre. Sono proprietari delle 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 l'equilibrio delicato tra allineamento e autonomia, i leader DevOps devono definire una tassonomia, definire un processo di pianificazione e usare chat di funzionalità.

Definire una tassonomia

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

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 è epica, caratteristiche, storie e attività.

Diagramma di una tassonomia comune illustrata come piramide.

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 è chiusa. Il numero di epiche in corso deve essere gestibile per mantenere l'organizzazione incentrata. 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 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.

Diagramma di una tassonomia comune con le iniziative aggiunte in alto.

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.

Nell'esempio seguente viene illustrata la linea di autonomia disegnata di seguito. La gestione possiede epiche e funzionalità, che forniscono l'allineamento. I team possiedono storie e attività e hanno autonomia rispetto alla modalità di esecuzione.

Diagramma della linea di autonomia tra caratteristiche e storie.

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. Mentre un team possiede il backlog delle storie, deve allineare il backlog alle funzionalità assegnate.

Pianificazione

Per ridimensionare la pianificazione Agile, un team deve avere un piano per ogni livello della tassonomia. Tuttavia, è importante scorrere e aggiornare il piano. Questo processo è detto pianificazione dell'onda mobile.

Il piano fornisce una 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à.

Diagramma degli intervalli di pianificazione per ogni livello.

Visione

La visione viene espressa tramite epiche e imposta la direzione a lungo termine dell'organizzazione. Epics definisce 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 un incontro a mano. 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 viene 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 di tutte le mani. Tutti i piani del team devono allinearsi al piano stagionale della gestione. Aspettatevi di realizzare 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 tre sprint successivi. Il team possiede il piano e lo calibra ogni sprint. Ogni team presenta il 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 sprint a 3.

Piano sprint

Il piano sprint definisce le storie e le funzionalità che il team terminerà nello sprint successivo. Il team possiede il piano sprint e lo invia tramite posta elettronica all'intera organizzazione per ottenere la massima trasparenza. Il piano include ciò che il team ha realizzato nel passato sprint e il loro focus per lo sprint successivo. Si prevede di ottenere circa il 95% del piano sprint.

Linea di autonomia

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

Diagramma di una visione diversa della linea di autonomia.

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

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

Una chat di funzionalità è una riunione a bassa cerimonia in cui ogni team presenta il proprio 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 sprint 3 è 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 a 3 diapositive, con le diapositive seguenti:

Funzionalità

La prima diapositiva descrive 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 della progettazione 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 ingegnere, la percentuale di unit test superati e gli obiettivi delle prestazioni.

Problemi e dipendenze

I problemi e le dipendenze elencate nella diapositiva finale includono qualsiasi elemento che influisce sullo stato di avanzamento del team, ad esempio i problemi che il team non riesce a risolvere o alle dipendenze di altri team che richiedono l'escalation.

Ogni team presenta le diapositive direttamente alla gestione. Il team presenta come il piano di 3 sprint si allinea 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 può richiedere un nuovo piano. In questo raro evento, il team rivaluta e pianifica una seconda chat di funzionalità per esaminarla.

Trust: l'associazione che contiene l'allineamento e l'autonomia insieme

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

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

  • Un team guadagna fiducia offrendo in modo coerente codice di alta qualità. Se i team non sono affidabili, la gestione non le darà l'autonomia.

La gestione deve fornire piani chiari per i team in modo da allinearsi e quindi considerare attendibile i team da eseguire. Teams deve allineare i propri piani all'organizzazione ed eseguire in modo affidabile.

Poiché le organizzazioni cercano di ridimensionare Agile in scenari più grandi, la chiave consiste nel dare autonomia ai team, assicurandosi che siano allineati agli obiettivi dell'organizzazione. I blocchi predefiniti critici sono chiaramente definiti proprietari e una cultura di fiducia. Una volta che un'organizzazione ha questa base, troverà che Agile può ridimensionare molto bene.

Passaggi successivi

Esistono molti modi per un team di qualsiasi dimensione per iniziare a vedere i vantaggi oggi. Vedere alcune di queste procedure che ridimensionano.

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

Microsoft è una delle più grandi aziende Agile del mondo. Altre informazioni sulla pianificazione di DevOps di Microsoft.