Lo sviluppo del software moderno e agile può fare a meno dei progetti? Quali sono le disfunzioni del modo di pensare orientato ai progetti? Queste le slide del mio intervento ad Agile Venture Milano 2019

1. https://www.linkedin.com/in/dimitri-favre-088675/
@DimitriFavre
Dimitri Favre
#noprojects
Modern software development focuses on
Teams and Products
26 gennaio 2019

2. Inspirato al lavoro di Allan Kelly,
Shane Estie, Evan Leybourn e altri

3. Inspirato al lavoro di Allan Kelly,
Shane Estie, Evan Leybourn e altri
e alla mia esperienza personale

4. Siamo così abituati al concetto di
progetto che diamo per scontata la sua
presenza nella nostra vita

5. Cos’è un progetto?

6. Un progetto è un sforzo
temporaneo intrapreso al
fine di creare un prodotto,
servizio o risultato unico.
Source: What is Project Management, PMI - https://www.pmi.org/about/learn-about-pmi/what-is-project-management

7. «Software is eating the world»
Marc Andreessen, 2011
Why Software is eating the world http://www.wsj.com/articles/SB10001424053111903480904576512250915629460

8. Non stiamo semplicemente facendo
software.
Stiamo facendo prodotti software

9. prodotto: ciò che costituisce il risultato di
un processo naturale o di un’operazione
umana

10. La mentalità orientata al progetto (o
modello a progetto) è un fattore di
inibizione dell’agilità

11. Stiamo (ancora)
scoprendo modi migliori
di creare software
facendolo ed aiutando
altri a farlo
Agile Manifesto, 2001

13. Si è creato il
il ruolo di PRODUCT Owner

14. Ma avete mai sentito parlare di
Project Owner?

15. Si vendono progetti con la massima nonchalance.
Ma voi comprereste un progetto?

16. I want to stress is the importance of getting rid of software
projects as a notion. Instead we want to switch to
a product-oriented view of the world where instead of
projects that you spin up, run for a while and then stop;
you instead say,
"Let's focus on things that are much more long-lasting
and organize a product team around that.“
Martin Fowler, «The State of Agile», August 2018

17. Ho alcuni personalissimi problemi con
il modello a progetto (e qualche
suggerimento per mitigarli)

18. Non è il progetto per sé
E’ la mentalità orientata al progetto

19. Un progetto è un sforzo
temporaneo intrapreso al
fine di creare un prodotto,
servizio o risultato unico.
Source: What is Project Management, PMI - https://www.pmi.org/about/learn-about-pmi/what-is-project-management

20. Bruce Tuckman, 1965

21. Bruce Tuckman, 1965
Fine del progetto
Disfiamo il team
Creeremo un team nuovo di
zecca se e quando ci sarà un
progetto su cui farlo lavorare

22. E mentre si celebra il successo del
progetto, il valore del team viene distrutto
per effetto del suo smantellamento

23. Focus on teams

24. Un team che gestisce più prodotti è
molto meglio di tanti piccoli team
usa e getta creati e disfatti ad hoc in
funzione dei progetti

25. Gestite un team backlog
(attraverso un team Products Owner)

26. Non è una questione di felicità
E’ anche una questione economica
(e comunque i soldi non comprano la felicità)

27. I prodotti software sono per sempre
(più o meno) ed evolvono
continuamente

28. Perché diavolo dovremmo gestire una
cosa che vive a lungo e cambia
continuamente nel tempo con una cosa
effimera chiamata progetto?

29. Il progetto è temporaneo.
Di conseguenza ha un inizio

30. … e una fine
(beh, non proprio tutti)

31. Il super domandone:
Quando inizia un progetto?

32. Alla fine della fiera, il successo di un
progetto è tipicamente dettato dalla
soddisfazione dei soliti tre elementi:
- On time (schedule)
- On budget
- On scope
(Scusate i bullet point)

33. Dov’è il valore per il cliente?
E la qualità?

34. Il successo del progetto è valutato
sulle cose sbagliate
(ciò che si può misurare invece che ciò che produce valore)

35. L’obiettivo è quello di creare valore, per il
cliente, per l’organizzazione e per la società
nel suo complesso

36. Invece di chiedersi
“Quanto costa?”
chiediamoci
“Quanto vale?”

37. Cosa succede quando il
progetto finisce?

38. Generalmente abbiamo due possibilità:
- Il progetto viene esteso
- Passaggio di consegne
(Scusate i bullet point)

39. Estendere un progetto significa
elemosinare un extra budget
(e far partire un nuovo progetto)

40. I prodotti vivi hanno tipicamente una lunga lista di
bisogni che aspettano di essere risolti (e nuovi
bisogni arrivano in continuazione durante la vita del
prodotto)

41. Per dire…
Non abbiate paura di avere team e
persone non allocate
Non lo saranno

42. L’AMS è la casa di riposo dei prodotti
software

43. Dove risiedono fino a quando non
sono dichiarati ufficialmente morti
dismessi

44. La manutenzione
dovrebbe essere
uno stato transitorio
in attesa del
prossimo step
evolutivo
Source: By Dzonatas - Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=4376189

45. I conflitti di interessi tra chi sviluppa e
chi gestisce il supporto

46. Squadre di serie A
VS
Squadre di serie B

47. L’handover è uno spreco

48. E per dirla tutta:
Non c’è miglior posto per fare la
manutenzione di un prodotto software
se non il team che l’ha realizzato

49. In un mondo in cui l’IT è un centro di
costo, i progetti (anche quelli agili)
vengono costruiti intorno ai silos
aziendali

50. L’ottimizzazione locale prevale sul
pensiero sistemico
La conseguenza è che anziché produrre
valore per il cliente, si finisce per creare
sistemi ridondanti e di complessità
crescente

51. I silos aziendali combattono per
ottenere budget sulla base del costo (e
dell’ottimizzazione dei costi)

52. The Black Friday
syndrome

53. Probabilmente non sarete in grado di
abbattere i silo organizzativi, ma potete
fare qualcosa per mitigarne gli effetti
nel software che implementerete

54. Siate lean

55. Siate lean adottando un pensiero
sistemico e lavorando
sull’ottimizzazione globale

56. Siate lean nella gestione del portfolio
delle iniziative
(potreste prendere spunto da quella che
probabilmente è la miglior parte di SAFe)

57. Agile e Progetto nella stessa
frase sono un ossimoro

58. Ooops

59. Previsioni e budget sono
generalmente definiti sulla lista di
requisiti che poi diventeranno le
fondamenta del progetto

60. Il che porta a contratti blindati sui
requisiti

61. #noproject world
Un mondo senza progetti

62. La perfezione non si ottiene quando
non c'è più nulla da aggiungere, bensì
quando non c'è più nulla da togliere
Antoine de Saint-Exupéry

63. Oggigiorno tutto è continuo

64. Continuous Improvement

65. Continuous Integration

66. Continuous Delivery

67. Continuous Release

68. Continuous Learning

69. Ma non si è mai sentito parlare di
Continuous Project

70. Lo sviluppo agile di software dovrebbe
abbandonare il concetto di progetto e
la sua eredità (e il suo gergo)

71. Concentrate i vostri sforzi
sull’evoluzione del portfolio di
soluzioni e prodotti

72. … portate il lavoro verso i team
(stabili) e gestite le priorità

73. … e scalate se e quando necessario

74. Validate e prioritizzate
continuamente
le iniziative in modo da
massimizzare il valore

75. Finanziate la capacity
anziché lo scope

76. Gestite le iniziative come esperimenti

77. Attraverso un ciclo di feedback breve

78. In altre parole,
sperimentate continuamente

79. Quando un progetto non raggiunge gli
obiettivi è un fallimento

80. Quando un esperimento fallisce è un
momento di apprendimento

81. Non importa quanto sia bella la vostra
teoria, né quanto siate in gamba. Se la
vostra teoria non è confermata da un
esperimento, è sbagliata.
Questa è la scienza
Richard Feynman, Cornell University Lecture, 1964

82. #noprojects manifesto
Experiments over instead of Projects

83. WARNING
#noprojects è dire no ai progetti

84. C’è spazio per i progetti nell’IT
(e a volte anche per il software)

85. In alcuni casi il modello a progetti è
ancora la scelta migliore

86. Per tutto il resto
ci sono
Prodotti, Teams and #noprojects

87. References

88. Project Myopia: Why projects damage software #NoProjects
Allan Kelly, 2018

89. Continuous Digital: An agile alternative to projects for
digital business
Allan Kelly, 2018

90. #noprojects: A Culture of Continuous Value
Evan Leybourn, Shane Estie, 2018

91. Company-Wide Agility with Beyond Budgeting, Open Space
& Sociocracy
Jutta Eckstein, 2018

92. Agendashift
Outcome-oriented change and continuous transformation
Mike Burrows, 2018

93. https://www.linkedin.com/in/dimitri-favre-088675/
@DimitriFavre
Dimitri Favre
Grazie

94. Domande?