Applicare Agile su larga scala per 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. Gli epici possono richiedere il contributo di diverse squadre e più sprint per essere portati a termine, ma hanno comunque una fine. Le epiche hanno un obiettivo chiaramente definito. Al completamento, l'epica viene chiusa. Il numero di epic in corso dovrebbe essere gestibile per mantenere l'organizzazione focalizzata. Gli epic sono suddivisi in funzionalità.

Funzionalità

Le funzioni definiscono nuove capacità necessarie per realizzare l'obiettivo di un epic. 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 software di qualità pronta per la produzione. Le storie sono l'unità di lavoro del team. Il team definisce le storie necessarie per completare una funzionalità. Le storie possono suddividersi facoltativamente in attività.

Tasks

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 direzione non interferisce con i livelli di cui è responsabile il team.

L'esempio seguente mostra la linea di autosufficienza tracciata sotto le caratteristiche. 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 allineare il proprio backlog alle funzionalità assegnate.

Planning

Per scalare 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 a onde continue.

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à.

Vision

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 generale. Poiché la visione è progettata per essere ambiziosa e molto può cambiare in quel periodo di tempo, aspettarsi di realizzare circa 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 direzione è responsabile del piano stagionale e presenta la visione e i piani stagionali in una riunione plenaria. Tutti i piani del team devono essere allineati al piano stagionale della gestione. Si prevede di realizzare circa 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 90% del piano di 3 sprint.

Il 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 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 dirigenza fornisce indicazioni usando i piani di visione e della stagione, quindi offre ai team l'autonomia di creare piani per un trimestre di sprint e per il singolo sprint.

Chat delle funzionalità: dove l'autonomia incontra l'allineamento

Una riunione sulle funzionalità è un incontro a bassa cerimonia in cui ogni team presenta il piano di 3 sprint alla dirigenza. 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 conversazioni sulle funzionalità si tengono in base alle esigenze, in genere ogni uno o tre sprint.

Una riunione di chat sulle 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 funzionalità che il team attiverà nei tre sprint successivi.

Debito

La diapositiva successiva descrive come il team gestisce il debito tecnico. Il debito è qualsiasi cosa che non soddisfa gli standard 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 sul progresso del team, ad esempio i problemi che il team non può risolvere o le dipendenze da altri team che richiedono un'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 riorganizzerà e programmerà una seconda chat sulle 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 direzione deve fornire piani chiari affinché i team possano allinearsi e fidarsi che i team eseguano. I team devono allineare i propri piani all'organizzazione ed eseguirli 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 costitutivi fondamentali sono una chiara definizione della proprietà 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. Scopri alcune di queste pratiche scalabili.

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.