Vorrei proporre alcuni "esercizi" per portare tutti "a bordo" del progetto.
Le attività hanno diversi scopi:
- allineare tutti
- fargli capire che è necessaria una visione di insieme per avere successo, mentre lavorare separati (a "compartimenti stagni", a "silos") funziona meno bene
- fargli capire che, per lo stesso motivo, non conviene ottimizzare localmente perché alla fine conta il risultato finale: possiamo fare benissimo tecnicamente per produrre una funzionalità inutile, non usata, che non risolve la necessità dell'utente
- fargli capire che "sono tutti sulla stessa barca" ("we're in it together")
- fargli capire che all'inizio di un progetto è importante esplicitare le aspettative di tutti, soprattutto degli stakeholders, perché un team non può essere autonomo e "empowered" se non ha chiari gli obbiettivi e le aspettative di chi ha avviato il progetto o di chi paga.
- il principio è poi sempre: un team autonomo è un team che ha obbiettivi chiari e massima libertà su come raggiungerli
per questo è importante descrivere obbiettivi e vincoli del progetto (tradeoff, rischi, etc)
- "get the right people in the room and ask them the right question"
- "Teams face thousands of decisions and trade-offs every day. And without the right context or big-picture understanding, it’s impossible for them to make the right trade-offs in an informed or balanced way."
-
Come misuriamo il successo di questa iniziativa?
-
Come facciamo a capire che siamo lì, che ce l'abbiam fatta?
-
Come evitiamo lo "squirrel-driven product management" (anything is a good idea, chasing different goals all the time)?
-
Ma cosa significa "valore"? => Underpants Gnomes
-
Come facciamo a capire che ci siamo muovendo nella direzione giusta man mano che iniziamo a mettere in DONE gli item del nostro backlog?
Progress & Success == How many story points we deliver?
Non misuriamo il successo in base agli item che mettiamo in DONE, ma in base a quanto ci siamo avvicinando all'obbiettivo.
Tracking activities vs measuring value delivered, outcomes.
Story points, at the end of the day, measure how much time we have spent building sw!
Requirements collected in Jira :-O
Tra il 50% e il 66% degli item nel tuo backlog sono cattive idee.
We need a plan like the one a TomTom (or Google Maps) gives you, a "turn-by-turn navigation": many different alternatives to reach your destination, and the ability to replan (at a small cost) the path to your destination whenever something unexpected happens (which is really the case in the most sw projects)
This is a quick reminder about why we are here, who our customers are, and why we decided to do this project in the first place
Secondo te, perché stiamo facendo questo progetto? Qual'è il motivo principale per cui si è deciso di intraprendere questa iniziativa? => scrivilo su un post-it Poi validiamo quanto scritto con il "customer"
- per avere maggiore chiarezza sui perché del progetto
- per aiutare tutti a pensare al punto di vista dell'utente finale
For [target customer] (Explains who the project is for or who would benefit from its usage)
who [statement of need or opportunity] (Expands on the problem or need the customer has to solve)
the [project name] (Gives life to our project by giving it a name)
is a [product category] (Explains what this service or product actually is or does)
that [key benefit, compelling reason to buy]. (Explains why our customer would want to buy this product in the first place)
Unlike [primary competitive alternative] (Covers why we wouldn’t already use what’s out there)
our project [statement of primary differentiation]. (Differentiate and explains how our service is different or better than the competing alternatives)
Quali sono le funzionalità di alto livello che vorresti vedere nel tuo sw? IN: funzionalità di alto livello (es sistema di reportistica) o obbiettivi generali (es scalabilità come amazon) OUT: cose sulle quali non vogliamo concentrarci ora, o che sono semplicemente al di là dello scopo del progetto.
UNRESOLVED: le cose su cui dobbiamo ancora prendere una decisione
Chi fa parte del team "core"? Chi fa parte della "comunità del progetto"? Facciamo un brainstorming su tutte le persone con le quali dovremo interagire prima che il progetto vada in produzione.
Brainstorming: Quali sono i rischi del progetto? Elenchiamoli! Una volta nominati tutti i rischi, dividiamoli in due gruppi: quelli che vale la pena affrontare e quelli che possiamo trascurare.
Ordiniamo
- qualità (High quality, low defects)
- scope (Feature completeness)
- budget (Stay within budget)
- tempo (Deliver project on time)
Ci sono altri "intangibles" da elencare?
Quanto è grosso il progetto più o meno? Possiamo descrivere una possibile timeline? Abbiamo una deadline?
chi può prendere l'ultima decisione in caso di incertezza?