Sviluppo guidato dalla missione

Con la crescita delle aziende, la scalabilità dello sviluppo dei prodotti Agile diventa più difficile. Secondo il 52% degli intervistati nel 13° Stato del Rapporto Agile, le differenze tra cultura organizzativa e valori Agile sono il principale svantaggio del loro lavoro.

I leader organizzativi sono in grado di sfruttare la cultura Agile per migliorare lo sviluppo del prodotto. Una solida cultura Agile implica l'autonomia del team nell'affrontare problemi complessi, il lavoro ravvicinato con i clienti e la visione e la strategia a lungo termine.

Questi valori astratti sono difficili da valutare e in cui impegnarsi. In un'organizzazione, l'implementazione di una strategia efficace per sfruttarli diventa un lavoro non banale. L'approccio Mission Driven Development (MDD) è passato dalle startup intermedie come alternativa per far crescere una tale cultura.

Sfide di ridimensionamento

Durante il ridimensionamento possono emergere diversi schemi di rallentamento. La motivazione del team può diminuire con progetti che hanno una fine poco chiara. I product manager possono sentirsi persi nelle riunioni operative e quindi perdere tempo per progettare percorsi di prodotto strategici. L'implementazione di nuove funzionalità e prodotti può rallentare man mano che i sistemi diventano sempre più complessi.

Queste barriere dovrebbero essere affrontate da una prospettiva culturale e pratica. Superarli implica la rinuncia al controllo, la crescita dell'autonomia del team, l'implementazione di una trasparenza radicale e la creazione di un quadro di sviluppo prodotto efficiente per ottenere risultati.

Sfide del ridimensionamento dei framework agili tradizionali

Quando si ridimensiona Agile, è necessario sincronizzare i livelli di gestione e team. Il livello dirigenziale è responsabile dello sviluppo della strategia aziendale, della creazione e della comunicazione della visione del prodotto, dell'esecuzione delle decisioni relative al personale e della promozione dello sviluppo del team. Il livello del team svolge le attività necessarie per tradurre in modo efficiente questa visione e strategia in prodotti e funzionalità di valore.

I framework Agile tradizionali (XP, Scrum e Kanban) sono ottimizzati per operare a livello di team, lasciando le relazioni di gestione principalmente irrisolte. Una nuova ondata di framework Agile scalati si è evoluta per colmare questa lacuna, ad esempio SAFe, LeSS, Scrum of Scrums, Nexus, DAD, ecc. Tuttavia, questi approcci richiedono molta pianificazione da implementare e sforzi per gestire e mantenere.

Un approccio leggero, il quadro di sviluppo guidato dalla missione fornisce linee guida sufficienti per implementare una struttura solida attorno allo sviluppo di scalabilità e allo sfruttamento dei valori Agile.

Elementi fondamentali dello sviluppo guidato dalla missione

Missioni

Il punto di partenza è Mission Discovery. Una missione aziendale richiede tempo e fatica e dovrebbe identificare un problema latente, uno spazio di soluzione e il risultato aziendale desiderato. Se definita con precisione, una missione guida la motivazione, favorisce la collaborazione e promuove la ricerca su spazi di progettazione più ampi.

Squadre

Gli attori responsabili del successo di ogni missione sono le squadre. In collaborazione con i product manager, piccoli team di 2-4 persone conducono le attività necessarie per fornire soluzioni che si adattino all'obiettivo della missione e ai limiti di tempo.

Ciclo di 6 settimane

Il timebox di 6 settimane consente a tutte le squadre di seguire la stessa sequenza temporale per la pianificazione di base, dando anche abbastanza tempo per fornire un risultato significativo.

Periodo tampone

Il framework MDD include comunemente un periodo di buffer di una o due settimane per integrazioni e implementazioni finali, formazione e sviluppo delle competenze, attività di innovazione e pianificazione del ciclo successivo, tra le altre cose.

L'importanza del ciclo di 6 settimane

Sebbene il periodo di sei settimane possa sembrare molto per alcuni praticanti Agile, contiene diversi importanti vantaggi.

I team che lavorano in cicli brevi tendono a perdere il coinvolgimento per la visione del prodotto, poiché si sentono come se stessero spuntando una "lista della biancheria" di correzioni, bug e piccole funzionalità. Ciò minaccia l'autonomia dei team nell'esplorazione e nella scelta del modo migliore per fornire soluzioni.

Man mano che i cicli si allungano, l'accuratezza della stima del prodotto diminuisce. Di conseguenza, richiede pesanti sforzi di pianificazione da parte dei team di prodotto.

Sei settimane sono state definite i riccioli d'oro dei tempi dei prodotti, fornendo tempo sufficiente per fornire un prodotto realizzabile minimo attraverso un pensiero innovativo, una prototipazione rapida e una consegna continua.

Il ciclo di 6 settimane migliora ulteriormente il coinvolgimento della visione del team sfruttando l'autonomia. La microgestione non è necessaria fintanto che le missioni sono chiaramente indicate e i cicli sono abbastanza brevi da consentire ai team di concentrarsi solo sui risultati desiderati.

Infine, i product manager possono impegnarsi in attività di pianificazione ogni sei settimane, mantenendo una prevedibilità sufficiente per consentire ai team di seguire la rotta verso la missione. Di conseguenza, è possibile dedicare più tempo alle dimensioni strategiche ed esplorative dello sviluppo del prodotto.

Attuazione dello sviluppo guidato dalla missione

Prendiamo, ad esempio, una startup intermedia che ha un prodotto B2B che offre un'ottimizzazione dei prezzi di rete che aumenta le entrate dei clienti attraverso l'uso di applicazioni di intelligenza artificiale. L'azienda ha recentemente firmato un nuovo round di finanziamento, con l'obiettivo di consolidarsi come attore importante del settore e aumentare la quota di mercato del 300%.

In questo scenario, ci sono diverse sfide di sviluppo del prodotto:

• Come è possibile ottenere feedback dai clienti attuali e potenziali per convalidare l'ipotesi del valore in sospeso?
• Quali funzionalità dovrebbero essere create o rimosse dalla piattaforma per un'esperienza utente avvincente?
• Come può essere impostata la struttura di gestione per gestire il ridimensionamento e sfruttare i valori culturali per accelerare la crescita?

Alla fine, per evitare framework complessi, l'azienda decide di applicare il framework Mission Driven Development. In Mission Driven Development, i dettagli dell'"ultimo miglio" sono definiti da ogni organizzazione. Gli elementi principali da definire sono:

• Scoperta della missione
• Struttura della missione
• Assemblaggio della squadra
• Ispezione e adattamento
• Iterazione del buffer
• Pianificazione della capacità

Scoperta della missione

Il punto di partenza è Mission Discovery. Tim Herbig descrive la scoperta come il processo iterativo di riduzione dell'incertezza su un problema o un'idea per garantire che il prodotto giusto venga costruito per il pubblico giusto. Prima che qualsiasi missione venga impegnata in un ciclo di iterazione, dovrebbe essere convalidata nel modo più completo possibile.

Il processo di Mission Discovery è condotto da squadre appositamente assegnate. Il team di scoperta è guidato dal product manager ed è composto da ricercatori di prodotto, analisti aziendali e designer. Quando esistono più product manager, questi riferiscono al Chief Product Officer (CPO), che assicura una visione comune tra i prodotti, l'adattamento dei prodotti e la strategia globale dell'azienda e la consegna tempestiva.

Il punto di partenza consigliato per la scoperta della missione sono le sfide, i problemi o le opportunità. Partire da una sfida, ad esempio, aiuta il team a esplorare più spazi progettuali, ampliando finalmente le possibilità di soluzione.

La convalida della missione prevede diverse attività che aiutano l'azienda a comprendere meglio le esigenze del cliente:

1. Conduzione di ricerche di mercato e analisi della concorrenza
2. Comprendere lo spazio problematico in cui è definita la missione
3. Progettazione di schizzi e prototipi in bassa fedeltà
4. Definire uno scopo chiaro per la missione
5. Raccolta del feedback e della convalida dei clienti

Queste attività aiutano la missione a essere una solida linea guida per la squadra di sviluppo e garantiscono la creazione di valore per gli utenti.

Di conseguenza, alcune missioni vengono convalidate per entrare nel Mission Backlog, che si evolve continuamente con attività di scoperta e raccolta di feedback.

Nell'esempio, prendiamo questa sfida: quali funzionalità dovrebbero essere create dalla piattaforma per produrre un'esperienza utente avvincente? Un solo team di scoperta, guidato dal product manager, sarebbe adeguato per affrontare questa sfida.

Supponiamo che attualmente la piattaforma dell'azienda di esempio prenda i dati grezzi del cliente e restituisca una rete di prezzi ottimizzata sui file di dati elaborati. Tuttavia, l'esperienza utente della piattaforma non è stata ottimizzata per un'esperienza accattivante. L'obiettivo a questo punto è determinare se il valore del cliente deriverà dal miglioramento dell'UX, dallo sviluppo di nuove funzionalità o dal miglioramento dei servizi della piattaforma.

Dopo una ricerca di mercato iniziale, la decisione è di sviluppare nuove funzionalità. Le caratteristiche candidate per la piattaforma sono:

• Repricing ultra veloce
• Interfaccia veloce e reattiva
• Regole di repricing intelligenti e avanzate
• Repricing e cronologia delle vendite

A scopo di scoperta, l'azienda decide di adottare un approccio di design sprint: un processo di cinque giorni per rispondere a domande aziendali critiche attraverso la progettazione, la prototipazione e il test delle idee con gli utenti. Il processo di rilevamento viene eseguito per ciascuna funzionalità candidata per vedere quale creerà più valore per i clienti attuali e potenziali. La caratteristica principale selezionata per lo sviluppo sono le regole di repricing intelligenti e avanzate.

Struttura della missione

Raggiungere una solida definizione di missione non è un compito banale. Deve rappresentare una chiara sfida aziendale e stabilire dei limiti per il suo risultato, dando anche spazio sufficiente alle squadre per arrivare a una soluzione innovativa ed efficiente. Una missione chiara e precisa:

• Afferma chiaramente una sfida aziendale, avendo identificato e delineato lo spazio problematico.
• Sintetizza tutte le informazioni e gli approfondimenti scoperti nelle fasi precedenti.
• Collegamenti a un risultato aziendale desiderato.
• È orientato ai risultati, indicando chiaramente il quadro del successo della missione.
• È realistico e realizzabile entro l'opportunità del ciclo di 6 settimane.
• È sufficientemente stretto per garantire la messa a fuoco e sufficientemente ampio per stare lontano dai dettagli.

Nell'esempio, dopo una settimana di scoperte, informazioni e feedback degli utenti sono stati raccolti e sintetizzati.

Utente target: analisti dei prezzi dei clienti.

Spazio problematico: gli utenti vogliono essere in grado di impostare e gestire regole intelligenti e avanzate per i prezzi in modo da poter regolare automaticamente i prezzi in determinate condizioni.

Le condizioni più preziose per le regole sono il prezzo della concorrenza, l'urgenza della spedizione, il totale dell'ordine, l'inventario disponibile e lo sconto per i clienti premium.

Approfondimenti: le regole devono essere applicate nelle priorità personalizzate ed essere modificabili, se necessario.

Gli analisti vorrebbero vedere facilmente quali regole si applicano in determinati momenti per un determinato prodotto.

Risultato aziendale desiderato: aumentare del 25% il coinvolgimento della piattaforma degli utenti, misurato dal tempo trascorso sulla piattaforma.

Assemblea della squadra

Il processo di formazione del team viene svolto ad hoc per ogni ciclo di sviluppo. L'autonomia del team ei principi di auto-organizzazione rimangono centrali. L'assemblaggio del team è guidato da un mix di fattori, che vanno dalla complessità della missione, alle capacità di sviluppatori e designer, agli interessi e alla chimica della squadra.

Il processo di formazione della squadra è facilitato dagli allenatori Agile. Prima di qualsiasi decisione, a ogni persona viene chiesto che tipo di lavoro vorrebbe fare nelle prossime sei settimane. Quindi, sulla base dell'esperienza, delle conoscenze e delle abilità, le squadre vengono create assicurandosi che abbiano le conoscenze e le abilità necessarie per affrontare con successo la missione.

Gli allenatori agili lavorano con diverse squadre lungo il ciclo di sviluppo, aiutandoli a sollevare impedimenti e dipendenze. Quando esistono diversi allenatori Agile, questi fanno capo al capo dell'Agile, che è responsabile dell'assemblaggio della squadra, del miglioramento continuo e della consegna dei prodotti Agile.

La dimensione consigliata della squadra è di 2-4 persone: di solito, un designer e uno o due sviluppatori, a seconda della complessità della missione. Si ritiene che un ingegnere QA assista una o più squadre nel raggiungimento degli standard di qualità desiderati.

Le squadre sono spesso miste dopo ogni ciclo, quindi tutti possono collaborare con persone diverse, diffondere conoscenze e lavorare su diverse dimensioni del prodotto, anche se una squadra ad alte prestazioni può lavorare insieme per alcuni cicli.

La squadra in particolare nell'esempio dovrebbe prendere in considerazione le persone con capacità di progettazione dell'interfaccia utente, elaborazione dati e visualizzazione dei dati.

Ispezione e adattamento all'interno del ciclo

La trasparenza, l'ispezione e l'adattamento dovrebbero essere incoraggiati continuamente dagli allenatori Agile attraverso pratiche Agile standard.

Si tengono brevi riunioni settimanali per organizzare il lavoro e facilitare l'innalzamento di impedimenti e dipendenze. Il grooming viene effettuato, se necessario, per garantire che le squadre comprendano appieno la missione e le storie degli utenti. Alla fine di ogni settimana vengono condotte brevi retrospettive per identificare e implementare modifiche e miglioramenti.

Le pratiche di consegna continua dovrebbero essere mantenute durante tutto il ciclo. L'obiettivo della missione potrebbe essere raggiunto prima, poiché il timebox del ciclo di 6 settimane è un approccio basato sulla cadenza per stabilire regole di base e allo stesso tempo aiutare a raggiungere la prevedibilità della squadra.

Una buona pratica per migliorare la trasparenza è una demo alla fine della quarta settimana, basata su un traguardo concordato tra squadre e product manager. L'obiettivo di queste demo è di adattare, ridurre o aumentare la portata secondo necessità.

Per la missione di esempio, è stato concordato un piano di rilascio tra la squadra e il product manager in quattro diversi rilasci:

1. Versione 1:
   • Nuova interfaccia utente della funzionalità delle regole
   • Regole sui prezzi dei concorrenti
2. Versione 2:
   • Regola di urgenza della spedizione
   • Regola totale dell'ordine
   • Priorità delle regole
3. Versione 3:
   • Regola dell'inventario disponibile
   • Regola dell'applicazione di visualizzazione
4. Versione 4:
   • Sconto per i clienti premium

La versione 3 è concordata come demo per la quarta settimana. Poiché i rilasci sono stati eseguiti durante tutto il ciclo di sviluppo, il risultato aziendale desiderato (in questo caso, il coinvolgimento degli utenti) dovrebbe essere monitorato dal momento in cui inizia il ciclo di sviluppo. Graficamente, i progressi sarebbero attesi come segue:

Periodo tampone

Prendere una o due settimane come periodo di buffer è una pratica replicata attraverso implementazioni di sviluppo guidato dalla missione, nonché attraverso altri approcci di scalabilità come SAFe.

In SAFe, in ogni ciclo di sviluppo viene eseguita un'iterazione di innovazione e pianificazione. Serve come commutatore di contesto, consentendo processi e attività di esplorazione e innovazione solitamente esclusi da altri framework incentrati sulla consegna. Esempi di attività implementate in questa settimana tampone:

• Integrazione finale della soluzione . Quando si esegue la distribuzione verso la fine del ciclo di 6 settimane, è probabile che l'integrazione, la verifica, la documentazione e la convalida rimangano in sospeso. Il tempo dedicato aiuta a garantire un'integrazione efficace e regolare di nuove soluzioni nei prodotti esistenti.
• Pianificazione della missione e definizione delle priorità . Le missioni vengono perfezionate, classificate in piccoli o grandi lotti e assegnate la priorità per il prossimo ciclo di sviluppo. Quando si assegnano le priorità alle missioni, alcune aziende implementano giornate di presentazione durante le quali le principali missioni vengono presentate all'azienda e quindi, in modo collaborativo, si impegnano per il prossimo ciclo di sviluppo.
• Hackathon . Gli hackathon hanno guadagnato una popolarità crescente tra le startup e le aziende grazie alla loro capacità di promuovere l'innovazione, creare comunità e costruire nuove conoscenze e abilità in modo divertente. I risultati vengono presentati ad altri e diventano candidati per il Mission Backlog.
• Sviluppo di prototipi sperimentali o progetti collaterali . È pratica comune dare a ingegneri e progettisti il ​​tempo di lavorare su qualunque cosa decidano, purché mostrino il lavoro svolto alla fine del tempo di buffer.
• Lavoro di ingegneria . Di solito viene svolto un lavoro puramente ingegneristico come lo sviluppo dell'infrastruttura, l'automazione dei test, la riduzione del debito tecnico e le migrazioni dei sistemi.
• Sviluppo di nuove abilità e conoscenze . Il rapido ritmo dell'evoluzione della conoscenza costringe gli sviluppatori a rimanere aggiornati sulle tendenze globali. Il tempo di buffer è adatto per tenere formazione in loco, comunità di pratica e workshop tecnologici, tra gli altri.

I periodi tampone dovrebbero basarsi su lacune di conoscenza identificate, obiettivi di innovazione e bisogni per il ciclo successivo. Ad esempio, un periodo di buffer di una settimana potrebbe essere simile a questo:

Pianificazione della capacità

Quando si decide l'impegno della missione per il prossimo ciclo di sviluppo, una pratica comune, secondo il co-fondatore di Basecamp Jason Fried, è identificare prima i lotti piccoli o grandi. I lotti grandi si riferiscono a caratteristiche o funzionalità di prodotti di grandi dimensioni, mentre i lotti piccoli si riferiscono a iterazioni o attività più piccole. Nell'esempio fornito, la missione selezionata per una nuova funzionalità potrebbe essere considerata un grande batch.

La raccomandazione qui è semplice: avere sempre un mix di lotti piccoli e grandi. I piccoli lotti sono missioni che si stima richiedano 3-4 settimane e i grandi lotti potrebbero richiedere sei settimane o più.

Se una squadra di piccoli lotti ha portato a termine la sua missione entro la settimana 3 o 4, la demo concordata è l'opportunità per valutare se la squadra deve continuare a lavorare per migliorare la soluzione implementata, aiutare un'altra squadra, intraprendere una nuova missione in piccoli lotti o iniziare lavoro non pianificato.

Una buona miscela di lotti grandi e piccoli impedisce alle persone di lavorare al 100% della capacità, consentendo loro così di manovrare e adattarsi in caso di lavoro non pianificato. I team di grandi lotti ottengono la massima concentrazione durante il ciclo, mentre i team di piccoli lotti possono occuparsi di attività ad hoc che derivano da lavori imprevisti.

Anche la combinazione di lotti piccoli e grandi riduce il rischio. Avere solo grandi lotti può aumentare la probabilità di un impatto negativo sull'esperienza dell'utente. Se diverse nuove funzionalità vengono rilasciate l'una vicino all'altra, dovrebbero essere accompagnate da una buona gestione delle modifiche. Inoltre, in caso di lavoro non pianificato, ci sarà una minore capacità disponibile. Infine, se diverse squadre di grandi lotti falliscono, l'iterazione potrebbe essere percepita come improduttiva e quindi demoralizzare le squadre.

Rischi dello sviluppo guidato dalla missione

Ci sono molti vantaggi nell'implementazione dello sviluppo guidato dalla missione, ma come qualsiasi quadro prescrittivo, presenta diversi rischi intrinseci che devono essere considerati.

Ambito di missione

Le missioni dovrebbero essere realistiche, mirando a un buon adattamento tra complessità della sfida e abilità della squadra; in caso contrario, l'impatto sui risultati dello sviluppo può essere significativo.

Una missione eccessivamente ambiziosa potrebbe suscitare frustrazione e ansia, con un impatto negativo sulle prestazioni della squadra. D'altra parte, una missione poco entusiasta potrebbe causare demotivazione e noia della squadra. Pertanto, una mentalità di prodotto minimo vitale dovrebbe rimanere costante all'interno del quadro.

Il perché di una missione

Missioni aziendali solide dovrebbero avere una definizione completa dello spazio problematico e della sua relazione con la visione aziendale. Se questa relazione non è chiara, si possono perdere preziose informazioni a causa della mancanza di comprensione di come la risoluzione dei problemi influisca sugli obiettivi aziendali.

Trappola a cascata

Cadere in un modello a cascata durante le sei settimane è una tendenza naturale per le squadre. Ci sono due fattori principali per questo. In primo luogo, la pressione per il dispiegamento è più forte verso la fine del ciclo. In secondo luogo, le squadre vogliono sfruttare quanto più possibile l'ambito di una missione, con conseguente urgenza di schierarsi alla fine del ciclo di sviluppo. Pertanto, le pratiche di erogazione continua dovrebbero essere incoraggiate per ottenere rilasci Agile durante tutto il ciclo ed evitare rischi legati alla cascata.

Operazione del prodotto

Le attività operative del prodotto come la gestione dell'infrastruttura, dei servizi o il monitoraggio dei componenti devono essere mantenute al di fuori dell'ambito delle squadre, poiché potrebbero influire sulla velocità. Fare affidamento su standard e pratiche di sviluppo come la progettazione atomica riduce gli sforzi di sviluppo e di conseguenza accelera il ridimensionamento. Un'altra pratica comune in questo quadro è un team operativo centrale che gestisce l'infrastruttura, oltre a gestire le operazioni e il monitoraggio dei prodotti.

Ciclo di 6 settimane come quadro miope

Alcuni scenari non saranno adeguati per il framework. Ciò diventa particolarmente vero quando si tratta di sistemi grandi e complessi che possono avere un enorme impatto sull'esperienza del cliente, come progetti di ricerca e sviluppo o migrazione di sistemi critici.

Un'opzione leggera per il ridimensionamento agile

Ridimensionare Agile per tenere il passo con lo sviluppo del prodotto e la crescita dell'azienda è una sfida latente per i professionisti Agile. Come approccio Agile sviluppato di recente, il framework Mission Driven Development ha guadagnato popolarità tra le aziende per la sua facilità d'uso e implementazione. Il framework MDD mette in moto un processo di innovazione del prodotto end-to-end e trasversale, dalla scoperta alla consegna, che colma le lacune presenti nelle tradizionali strutture Agile. Lo sviluppo guidato dalla missione ha il potenziale per essere il nuovo Scrum per le aziende in crescita.