https://www.linkedin.com/in/dimitri-favre-088675/
@DimitriFavre
Dimitri Favre
#noprojectsLo sviluppo software moderno è centrato
su team e prodotti
Are You Agile Enough?19-20 Dicembre 2018
Inspirato al lavoro di Allan Kelly, Shane Estie, Evan Leybourn e altri
Images and illustrations from «Spongebob Squarepants», © Viacom
Inspirato al lavoro di Allan Kelly, Shane Estie, Evan Leybourn e altri
e alla mia esperienza personale
Images and illustrations from «Spongebob Squarepants», © Viacom
Alcuni passi indietro
Stiamo (ancora) scoprendo modi migliori
di creare software facendolo ed aiutondo
altri a farlo
Agile Manifesto, 2001
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
Non è il progettoE’ il modello a progetto
Siamo così abituati almodello a progetto che non riusciamo
a vedere i problemi che questo modello si porta dietro
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
La mia personalissima lista dei cinque problemi
principali del modello a progetto
E qualche suggerimento su come evitare questi problemi
The power of teams
Bruce Tuckman, 1965
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
E mentre si celebra il successo del progetto, il
valore del team viene distrutto per effetto del
suo smantellamento
Un team che gestisce più prodotti è molto meglio di tanti piccoli team usa e getta creati e disfatti ad hoc in funzione
dei progetti
Gestite un team backlog(attraverso un team Products Owner)
Non è una questione di felicitàE’ solo una questione di soldi
(e comunque i soldi non comprano la felicità)
I prodotti sono per sempre (più o
meno) ed evolvono continuamente
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
In altre parole
Il progetto ha un inizio
… e una fine(beh, non proprio tutti)
Alla fine della fiera, il successo di un progetto è tipicamente ed esclusivamente
associato ai soliti tre elementi:
- On time (schedule)- On budget- On scope
Dov’è il valore per il cliente?E la qualità?
Il successo del progetto è valutatosulle cose sbagliate
(ciò che si può misurare invece che ciò che produce valore)
L’obiettivo è quello di creare valore, per il cliente, per l’organizzazione e per la società
nel suo complesso
Invece di chiedersi“Quanto costa?”
chiediamoci“Quanto vale?”
Cosa succede quando il progetto finisce?
Generalmente abbiamo due possibilità:
- Il progetto viene esteso- Passaggio di consegne
Estendere un progetto significa elemosinare un
extra budget
Ecco il budget
Perché diavolo dovremmo gestire una cosa che vive a lungo e cambia
continuamente nel tempo con una cosa effimera chiamata progetto?
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)
Per dire…
Non abbiate paura di avere team e persone non allocate
Non lo saranno
Passaggio di consegne ad un team di support
(AMS)
L’AMS è la casa di riposo dei
prodotti software
Dove risiedono fino a quando non sono ufficialmente morti
dismessi
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
I conflitti di interessi tra chi sviluppa e chi gestisce il supporto
Squadre di serie AVS
Squadre di serie B
L’handover è uno spreco
E per dirla tutta:Non c’è miglior posto per fare la
manutenzione di un prodotto software se non il team che l’ha realizzato
Il modello a progetto rafforza la visiondell’IT come centro di costo e favorisce
la creazione di silos aziendali
I silos organizzativi rappresentano uno
dei principali ostacoli all’agilità
I progetti (anche quelli agili) sono in effetti costruiti intorno a silos
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
I silos aziendali combatto per ottenere budget sulla base del costo (e dell’ottimizzazione dei costi)
I team vengono creati, divisi, cambiati, ricombinati o anche terminati in
funzione dei progetti che giustifichino il loro lavoro
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
Questo comportamento è
comune negli outsourcer che
lavorano su commessa
Probabilmente non sarete in grado di abbattere i silo organizzativi, ma potete fare qualcosa per mitigarne gli effetti
nel software che implementerete
Siate lean
Siate lean adottando un pensiero sistemico e lavorando
sull’ottimizzazione globale
Siate lean nella gestione del portfolio delle iniziative
(potreste prendere spunto da quella che probabilmente è la miglior parte di SAFe)
I progetti sono basati su un ambito
predefinito
(con una lunga e dettagliata lista di
requisiti)
Il modello a progetto avvelena tutta la delivery anche se la
fabbrica software è agile
Agile e Progetto nella stessa frase sono un ossimoro
Ooops
Previsioni e budget sono generalmente definiti sulla lista di requisiti che poi diventeranno
le fondamenta del progetto
Ecco il budget(di nuovo)
Il che porta a contratti blindati
sui requisiti
Nessun vero suggerimento, ma pensateci due volte prima di usare progetto e agile nella stessa frase
;)
Finanziare la capacityanziché lo scope
Gestite le vostre iniziative come esperimenti
I contratti agili sono spesso e volentieri basati sulla capacity e sul valore
(varianti sul tema Time & Material)
#noproject world
Un mondo senza progetti
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
Oggigiorno tutto è continuo
Continuous Improvement
Continuous Integration
Continuous Delivery
Continuous Release
Ma non si è mai sentito parlare diContinuous Project
Lo sviluppo agile di software dovrebbe abbandonare il concetto di progetto e
la sua eredità (e il suo gergo)
Concentrate i vostri sforzi sull’evoluzione del portfolio di
soluzioni e prodotti
… portate il lavoro verso i team (esistenti), gestendo le priorità
… e scalate se e quando necessario
Validate e prioritizzatecontinuamente
le iniziative in modo damassimizzare il valore
Attraverso un ciclo di feedback breve
In altre parole,sperimentate continuamente
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
#noprojects manifesto
Experiments over instead of Projects
Quando un progetto fallisce è un fallimento
Quando un esperimento fallisce è un momento di apprendimento
Oh no, sono un Project Manager
C’è ancora spazio per i progetti
In alcuni casi il modello a progetti è ancora la
scelta migliore
Per tutto il restoci sono
Prodotti, Teams and #noprojects
References
Project Myopia: Why projects damage software #NoProjects
Allan Kelly, 2018
Continuous Digital: An agile alternative to projects for digital business
Allan Kelly, 2018
#noprojects: A Culture of Continuous Value
Evan Leybourn, Shane Estie, 2018
https://www.linkedin.com/in/dimitri-favre-088675/
@DimitriFavre
Dimitri Favre
Grazie
Domande?
