“Rispondere al cambiamento più che seguire un piano” Organizziamo il nostro processo di lavoro in sprint o iterazioni, facciamo retrospettive, abbiamo il nostro Product Owner, stand up meeting e user stories, unit test e continuous integration .... però continuiamo a preparare il nostro bel backlog all’inizio del progetto quando abbiamo solo tante ipotesi e lo seguiamo passo passo come fosse una “ricetta”. Qui vediamo cosa significa fare un piano adattivo che ci permetta realmente di rispondere al cambiamento.

1. Adaptive Planning
Responding to change over following a plan
Lorenzo Massacci

2. History of Agile

3. In Europa sprecati 142
miliardi di € in progetti
IT fallimentari perché gli
obiettivi di business e
strategici sono diventati
obsoleti durante il
delivery.
http://news.bbc.co.uk/2/hi/8397854.stm
https://www.independent.co.uk/life-style/health-and-families/
health-news/nhs-pulls-the-plug-on-its-11bn-it-system-23309
06.html

4. Ci basiamo su supposizioni
➔ non condivise
➔ non esaminate
➔ non provate
➔ trattate come certezze

5. Misuriamo quanto siamo occupati
o se stiamo ottenendo l’effetto che
volevamo?
“Siamo in ritardo dobbiamo
aggiungere sviluppatori al team!”
Il nostro focus dov’è?

6. "Adding human resources to
a late software project
makes it later"
Brooks's law
(https://en.wikipedia.org/wiki/Brooks%27s_law)

7. Features Growth
≠
Value Growth

8. Best
product
owner
skill
SAY
NO!

11. Spesso i nostri
backlog non
sono altro che
RICETTE

13. Lo scopo di una mappa stradale non è dare informazioni
dettagliate sulle città, ma rendere esplicite le connessioni tra esse
ed aiutarci ad identificare le strade alternative che abbiamo per
andare da un punto A ad un punto B.
Ci forniscono un contesto specifico per prendere
decisioni ed evidenziare l’incertezza che può
essere affrontata con esperimenti.
Roadmap

14. “No plan survives contact
with the enemy.”
German Field Marshal, Helmuth von Moltke

15. I problemi del mondo reale sono
più complessi di quanto pensiamo
perché hanno una dimensione
umana e una dimensione
territoriale (contesto) e
probabilmente cambieranno con il
mutare delle circostanze
Peter Palchinsky
Russian Engineer early 20th century
Il mondo reale

16. Adaptive Planning
vs
Predictive Planning

17. Qual è la vision? Perché
stiamo facendo questo
progetto? Cosa vogliamo
ottenere?
Deliver business goal
not just feature
Obiettivo chiaro e
condiviso

18. Chi può influenzare in
qualche modo il
risultato del nostro
lavoro?
Potere e Interesse
Dimensione Umana

19. Come deve cambiare il
sistema ed il
comportamento dei nostri
utenti per centrare il nostro
obiettivo?
Sono ipotesi da
verificare!
Dimensione “Territoriale”

20. Quali azioni o feature
possono generare il
cambiamento desiderato?
Hanno uno scopo
preciso!
Deliverables

22. We believe that [impact] by
doing [deliverable] will lead
to [goal].
ANCORA MEGLIO

23. Siamo sicuri che
l’ipotesi è corretta?
Troviamo il modo di
validare l’ipotesi!

24. Evolutionary
Design
➔ build quality in (self-testing code)
➔ continuous integration
➔ refactoring
➔ simple design
★ Continuous Delivery
https://www.testingexcellence.com/testing-in-devops/

25. “Se raggiungiamo il risultato con
una soluzione completamente
differente da quella pianificata,
abbiamo avuto successo?”
Metriche

26. Product
governance
meeting
(ritual)

27. Variation: tratta il backlog come
opzioni
Survivability: fai esperimenti
dove il fallimento è superabile
Selection: cerca feedback ed
impara dagli errori
Adaptive planning

28. Grazie!
—
Lorenzo Massacci
Digital Project Enabler
@lorenzomassacci lorenzo.massacci@flowing.it