Agile lean conference 2016

1. Agile e Lean Management
Da dove veniamo e dove stiamo andando…
Simone Onofri - simone@agileleanconference.org
Claudia Spagnuolo - claudia@agileleanconference.org

2. Cosa intendiamo per Lean?
“Lean” è un termine che descrive un modo di
pensare per aumentare l’efficienza ed
eliminare gli sprechi.
1500-1900
Studi che partono da
Venezia per migliorare il
flusso produttivo.
1900-1990
Applicato al mondo
manifatturiero dove
viene standardizzato
e studiato.
1990-2005
Diventa a far parte dei
«Must» della
produzione.
2006
Viene codificato nello
sviluppo software
«Implementing Lean
Software
Development» di Mary
e Tom Poppendieck.
2011
Viene codificato nello
sviluppo software
«Lean Startup» di Mary
e Eric Ries

3. Quali sono i principi Lean?
Manifatturiero
• Eliminare gli sprechi
• Definire il Valore dal punto
di vista del cliente
• Far fluire tutte le attività
• Realizzare un'attività solo
quando il processo a valle
lo richiede
• Perseguire la perfezione
tramite continui
miglioramenti (Kaizen)
Software
• Eliminare gli sprechi
• Integrare la qualità
• Creare conoscenza
• Rinviare l’impegno
• Rilasciare velocemente
• Rispettare le persone
• Ottimizzare

4. Cosa intendiamo per Agile?
“Agile” è un termine “ombrello” che descrive
solo un modo di lavorare collaborativo…
la filosofia Agile è stata declinata in molti modi.
DSDM AgilePF™
AgilePM™ Scrum
SAFe™ XP
Crystal
AUP
RAD
DAD

5. Livelli di gestione:
framework e metodologie a confronto
CC-BY-NC-ND Simone Onofri e Claudia Spagnuolo
Gestione del
Team e del
Prodotto
Gestione e
Direzione del
Progetto
Gestione del
Programma
Gestione del
Portafoglio
Scrum
Guide
Tecniche
Specialistiche
e Delivery
XP Lean*
DSDM®
AgilePF®
DSDM®
AgilePgM®
DAD
DSDM®
AgilePM®
SAFe™
PRINCE2®
MSP®
M_o_P®

6. Sfatiamo un falso mito:
Agile = Scrum?
Agile != Scrum

7. Il (famoso?) manifesto Agile
Gli individui e le interazioni più che i processi e gli strumenti
Il software funzionante più che la documentazione esaustiva
La collaborazione col cliente più che la negoziazione dei contratti
Rispondere al cambiamento più che seguire un piano
Ovvero, fermo restando il valore delle voci a destra,
consideriamo più importanti le voci a sinistra.
— Agile Manifesto, 2001

8. “Agile nasce della necessità di
un’alternativa ai processi ‘pesanti’
di sviluppo software,
basati su documentazione
e pianificazione massiva,
con lo scopo di scoprire
modi migliori di creare software”
— Agile Manifesto, 2001
Sfatiamo un falso mito:
con Agile non si fa documentazione? 1/2

9. “Abbracciamo la
documentazione,
ma non centinaia di pagine
che nessuno gestisce
e in ‘tomi’ difficilmente utilizzabili”
Sfatiamo un falso mito:
con Agile non si fa documentazione? 2/2
— Agile Manifesto, 2001

10. Sfatiamo un falso mito:
con Agile non serve la pianificazione?
“Facciamo la pianificazione,
ma ne riconosciamo i limiti
in un ambiente turbolento.”
— Agile Manifesto, 2001

11. Sfatiamo un falso mito:
con Agile non servono i Project Manager?
“Il project manager è morto,
viva il project manager!”
— Agile Lean Conference, 2016

12. Agile Team & PM: un esempio
- DSDM © - Reproduced under permission -
Negli organigrammi degli
approcci agili di tipo “full” il
Project Manager trova
posto nella head del
progetto, come per
esempio nell’AgilePF®.
Il Business Analyst funge
da ufficiale di collegamento
tra il business e il team di
sviluppo.

13. Ci sono approcci in cui il PM è superfluo?
In molti framework non è previsto
il ruolo/figura del PM…
ma ne sono previste
le responsabilità… quindi?
Spesso le sue responsabilità
sono semplicemente state redistribuite in modo
diverso tra due o più figure.

14. Conviene sempre essere Agili?
E se in alcuni casi fosse meglio
un approccio tradizionale?
Sfatiamo un falso mito:
conviene essere Agile? 1/2

15. Dipende!
Bisogna valutare caso per
caso. Ma come capirlo?
Sfatiamo un falso mito:
conviene sempre essere Agile? 2/2

16. - Il management è d’accordo ad utilizzare un approccio agile? (Chaos
report)
- Sarà possibile per chi sviluppa la soluzione comunicare velocemente
con il Business e/o con gli utenti finali per tutta la durata del progetto?
(Chaos report)
- Ci sono vincoli tecnici, contrattuali o altro che impedisca di suddividere
la soluzione in sotto-prodotti?
- I requisiti di alto livello sono stati definiti all’inizio del progetto ma è noto
a tutti che probabilmente saranno modificati successivamente durante
lo sviluppo dei dettagli?
- Le strategie per una continua comunicazione e il metodo di lavoro
collaborativo prescelto sono sufficienti a supportare in modo chiaro lo
sviluppo iterativo della soluzione?
Che domande porsi?

17. Il PAQ, Project Approach Questionnaire del
DSDM® , è una lista di affermazioni, per
ciascuna delle quali andrebbe definito un
livello “intesa” (da 1 a 5), che aiuta ad
individuare i rischi legati alla selezione di un
modello Agile.
Una check list già pronta: PAQ

18. Grazie
The trademarks LEGO® SERIOUS PLAY® and
SERIOUS PLAY® by LEGO Group.
DSDM® is a trademark registered by DSDM®
Consortium
For photo/images credits please refer to the
specific slide.
Other material on this presentation is distributed
under Creative Common license v3 BY-ND-NC by
Simone Onofri. Please contact the author for
specific needs.