Smetti di fare un tour dei tuoi ticket

La demo inizia tra sei minuti. Qualcuno sta cercando un account di test. Qualcun altro chiede quale ambiente ha l'ultima build. Chi presenta ha aperto Jira e filtrato per Done, che ora sembra essere l'agenda. Ci sono quattordici ticket, tre presentatori diversi e nessuna risposta ovvia alla domanda che uno stakeholder sta per fare: "Cosa possono fare ora i nostri utenti che non potevano fare prima?"

È così che un buon lavoro di engineering finisce in una demo scadente. Uno sviluppatore spiega un'implementazione complessa, clicca su una nuova schermata e passa la parola alla persona successiva. Tutti hanno lavorato sodo. Tutti sono educati. Alla fine, il pubblico sa che le cose sono state completate, ma potrebbe ancora dover capire perché una qualsiasi di esse sia importante.

Una preparazione migliore inizia prima di controllare la condivisione dello schermo. Significa collegare il lavoro completato a un problema che le persone riconoscono, mostrare cosa è cambiato e lasciare spazio per una risposta utile. Una prova più lunga dell'elenco dei ticket non ti porterà lì.

Inizia con il cambiamento che qualcuno può riconoscere

Il titolo di un ticket ha senso per le persone che hanno passato due settimane a discuterne. Gli stakeholder potrebbero non avere quel contesto. "Aggiungi endpoint di approvazione in blocco" dice loro cosa ha costruito il team. Non spiega la giornata di chi era difficile, quale parte è ora diversa o cosa rimane irrisolto.

Immagina un team che costruisce uno strumento di acquisto per i responsabili di reparto. La vecchia demo si apre con un numero di ticket, menziona il nuovo endpoint e mostra una casella di selezione. Chi presenta approva tre richieste. Funziona. "Domande?" è accolto dal tipo di silenzio che fa controllare alle persone se sono ancora in muto.

Lo stesso lavoro potrebbe essere introdotto diversamente: "Un responsabile che esamina un lotto di richieste di routine attualmente deve aprire e approvare ciascuna separatamente. Abbiamo aggiunto un modo per approvare insieme le richieste idonee. Mostrerò quel percorso, poi cosa succede quando una richiesta necessita di una revisione individuale. Vorremmo il vostro aiuto per verificare se le regole di idoneità si adattano a come lavorate effettivamente."

Ora i clic hanno uno scopo. Il pubblico può esaminare il comportamento rispetto a una situazione che comprende. Qualcuno potrebbe far notare che le richieste da un nuovo fornitore necessitano sempre di un controllo separato. Questa è una scoperta utile, anche se rende la demo meno ordinata.

Il team dovrebbe anche essere preciso riguardo alle sue prove. Mostrare un'azione in blocco funzionante stabilisce che la capacità esiste. Non stabilisce quanto tempo risparmieranno i responsabili, se la useranno o se le approvazioni miglioreranno. Queste sono cose da indagare dopo l'uso. "Ci aspettiamo che questo riduca i passaggi ripetitivi" è una spiegazione onesta dell'intento. "Abbiamo reso i responsabili più produttivi" necessita di prove che la sola demo non può fornire.

Il lavoro tecnico merita la stessa chiarezza

Questo approccio non dovrebbe trasformare una revisione in un concorso di bellezza per funzionalità visibili. Uno sprint speso per migliorare il ripristino, la sicurezza o la manutenibilità può avere un'importanza enorme. Nessuno deve inventare un nuovo pulsante per giustificarlo.

Per una modifica di ripristino, mostra lo scenario di fallimento, come il sistema ora risponde e cosa dimostra il test. Per un aggiornamento di dipendenza, spiega quale rischio affronta e come è stata verificata la compatibilità. Collega il lavoro di engineering alla conseguenza che intende cambiare, usando le prove disponibili ed essendo chiaro sui suoi limiti.

Preparati per una conversazione

Sappi chi sta ascoltando. Un pubblico aziendale potrebbe aver bisogno dell'impatto su un flusso di lavoro e della decisione che abilita. Un pubblico tecnico potrebbe dover esaminare scelte implementative e compromessi. Con entrambi nella stanza, inizia con il perché il cambiamento è importante, poi fornisci la profondità necessaria per esaminarlo.

Se hai solo dieci minuti, decidi quale valore aziendale il pubblico ha più bisogno di comprendere. Nell'esempio degli acquisti, ciò potrebbe significare mostrare il percorso di approvazione in blocco e verificare le regole di eccezione, piuttosto che fare un tour di ogni ticket completato. Scegli ciò che aiuta le persone a prendere una decisione utile. Mantieni in vista lo Sprint Goal, incluso dove il risultato è insufficiente; una demo più breve non dovrebbe nascondere un risultato scomodo.

Per ogni elemento, il team dovrebbe essere in grado di spiegare il problema, il comportamento modificato e le prove dietro le sue affermazioni. Poi chiedi quale risposta sarebbe utile. Stai verificando un'ipotesi su un flusso di lavoro? Scegliendo tra due passaggi successivi? Testando se una limitazione è accettabile? Una domanda specifica dà alle persone un modo per entrare nella discussione che "Qualche feedback?" raramente offre.

La preparazione pratica è ancora importante. Conferma cosa soddisfa la Definition of Done, cosa è distribuito dove e cosa può effettivamente essere dimostrato. Configura dati rappresentativi e verifica il percorso che prevedi di mostrare. Lascia tempo alle persone per interrompere. In Scrum, la dimostrazione è solo parte della Sprint Review, dove il team e gli stakeholder ispezionano il risultato e capiscono cosa fare dopo. Dovrebbe supportare quella collaborazione, non consumare l'intero evento.

Dove Flow aiuta

Le note demo di Simyl Flow possono essere calibrate per un pubblico aziendale, tecnico o misto. Oltre a suggerire elementi completati degni di demo, le sue note collegano il lavoro al valore aziendale e forniscono punti di discussione, domande anticipate degli stakeholder e risposte suggerite. Il team ha un punto di partenza per spiegare perché un cambiamento è importante e prepararsi per la conversazione che potrebbe suscitare. Nell'esempio degli acquisti, ciò potrebbe significare prepararsi per domande sulle eccezioni, con risposte verificate rispetto al comportamento effettivo.

Quando l'agenda si restringe, le note includono anche un breve "Se il tempo è limitato, enfatizza:", che riunisce i punti di valore aziendale dagli elementi del presentatore. Il team decide ancora l'ordine e le priorità, verifica cosa è pronto per essere dimostrato e verifica le affermazioni. Flow aiuta a mantenere la spiegazione focalizzata; il team rimane responsabile di ciò che dice.

Il tempo di preparazione si accumula nel team. Come esempio illustrativo, se Flow fa risparmiare a quattro sviluppatori quindici minuti ciascuno prima di una demo, ciò restituisce un'ora-team. A un costo caricato ipotizzato di US$75 all'ora, sono US$75 di capacità, più del prezzo mensile Growth di US$49 per team. Una demo può coprire il mese su queste ipotesi, e la preparazione della demo è solo una delle cerimonie che Flow supporta. Questo è tempo disponibile per altro lavoro, non un risparmio garantito o denaro rimosso dal libro paga. Saltare la preparazione ha anche un costo: lascia tutti nella riunione a districare ciò che avrebbe dovuto essere spiegato in anticipo.

La conversazione ha anche bisogno di un posto dove andare dopo. Flow può trasformare il feedback della demo in card retrospettive e azioni, aiutando il team a portare l'apprendimento nel suo lavoro di miglioramento. Il feedback del prodotto dovrebbe anche informare le decisioni rilevanti del Product Backlog. Una richiesta per una regola fornitore mancante e un problema ricorrente con gli ambienti demo necessitano di follow-up diversi, anche quando entrambi provengono dalla stessa revisione. Concordate chi porterà avanti ogni follow-up e quando il team verificherà cosa è successo.

Prima della prossima demo, guarda il primo elemento che prevedi di mostrare. Qualcuno al di fuori del team può capire chi aiuta, cosa è cambiato e cosa devi ancora imparare? In caso contrario, continua a preparare la spiegazione, non ad aggiungere più ticket. Dai alle persone abbastanza da mettere in discussione, non solo abbastanza da applaudire. Poi usa ciò che senti per decidere cosa succede dopo.