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?