Slide presentate a Italian Agile Day(s) 2013 di Reggio Emilia: Lean anche io! No tu no! Sessione incentrata sulla condivisione dell'esperienza di transizione verso un modello Lean in progetti reali di consulenza per grandi aziende dove spesso molte delle pratiche e delle metodologie proposte in ambito agile sono difficilmente applicabili. L’obiettivo è mostrare i successi ottenuti (sia per il team di sviluppo che per gli utenti), condividere i nostri fallimenti, i problemi incontrati e le sfide aperte per offrire un punto di vista su come può essere affrontata la transizione ad un modello agile in contesto di relazione grande cliente-fornitore.

1. Lean anche io!
No tu no!
#IAD13
@andreascavolini
@SimoneVannicola

2. Agenda





Il contesto: grande cliente - fornitore
– il fornitore
– i grandi clienti
La storia delle nostre esperienze
– gli albori: la curiosità
– gli esperimenti con i primi clienti: l'entusiasmo
– i primi fallimenti: la delusione
– i primi successi: la speranza
Un caso cliente
Dove siamo oggi
I trade-off
– Progetti a pacchetto vs agilità
– Release Planning vs Gantt
– Story Point vs Man-Days
– Big Design Up Front vs Incremental Design
– Ritmo vs disponibilità degli utenti

3. Il contesto: grandi clienti - fornitore

4. Fornitore: ICONSULTING (1/2)
THE EXPERT MOOD
WHO
WE ARE
ICONSULTING IS AN INDEPENDENT CONSULTING
COMPANY SPECIALIZED IN DWH,BI & PM
Research in our DNA: Iconsulting was born from a spin-off of a
prestigious Research University Consortium group focused on Data
Warehouse & Business Intelligence with the mission of delivering
best in class BI & PM projects
Strong expertise on all the market leading technologies
25% of our time invested in R&D
Over 300 projects delivered to more than 100 customers
Professorship in prestigious Italian Universities and Business Schools
In-house Knowledge Factory School providing education services to
professionals who need to develop their skills
1
2
INNOVATIVE SPECIALIZED
3
VENDOR
INDEPENDENT
4
DEVELOPING
SKILLS

5. Fornitore: ICONSULTING (2/2)
R&D: OUR DNA
WE BRING INNOVATION TO YOU
WHAT
WE DO

6. Grandi clienti
MANUFACTURING
Our
CUSTOMERS
FASHION
CALZEDONIA
DIESEL
GEOX
IMAX
LOTTO
MILAR
FINANCIAL SERVICES
CREDIT SUISSE
DEXIA CREDIOP
EUROGROUP
FGA CAPITAL (GRUPPO FIAT)
INA ASSITALIA
UNIPOL BANCA
FOOD
BARILLA
BIRRA PERONI
ERIDANIA SADAM
GRANDI SALUMIFICI ITALIANI
MASSIMO ZANETTI BEVERAGE GROUP
MONTENEGRO
SALUMIFICIO FRATELLI BERETTA
SEGAFREDO
LARGE SCALE RETAIL
CONAD ADRIATICO
COOP ITALIA
LA RINASCENTE
SMA (SIMPLY MARKET)
VIP CATERING
MEDIA & PUBLISHING
ALFA WASSERMANN
AMPLIFON
ARISTON THERMO
CAMAR SMA
CANTIERI SANLORENZO
CASE NEW HOLLAND
DUCATI MOTOR HOLDING
FEDRIGONI
FONTANOT
G.D
GGP ITALY
CISA (Ingersoll-Rand)
GRUPPO COESIA
GRUPPO FABBRI
ICF - LA FAENZA
IGUZZINI
I.M.A. INDUSTRIA MACCHINE AUTOMATICHE
INTERTABA - PHILIP MORRIS
KME
KOMATSU UTILITY EUROPE
LOWARA
MAGNETI MARELLI
MALAVOLTA CORPORATE
MARAZZI
MARPOSS
NEGRI BOSSI
OTIS
OVA BARGELLINI
PHILIP MORRIS ITALIA
PM GROUP
POZZI GINORI
ROSETTI MARINO
SACMI
SECI
SONY EUROPA
TEUCO GUZZINI
UNO A ERRE
GRUPPO INDUSTRIALE L’ESPRESSO
FOX INTERNATIONAL CHANNEL
PANINI GROUP
SKY ITALIA
VODAFONE
ZANICHELLI EDITORE
GOVERNMENT & PUBLIC SECTOR
ARCEA
AGREA
ARPA
ARPAT
AVEPA
CESIA
COMUNE DI BOLOGNA
COMUNE DI REGGIO EMILIA
ERVET
INVITALIA
I.S.P.R.A. AMBIENTE
ISTITUTO NAZIONALE FISICA NUCLEARE
LEPIDA
MINISTERO DELL’INTERNO
MINISTERO DEL LAVORO E DELLE POLITICHE
SOCIALI
PROV. AUTONOMA DI BOLZANO
PROV. AUTONOMA DI TRENTO
PROVINCIA DI RIMINI
REGIONE EMILIA ROMAGNA
UNIVERSITA’ DI BOLOGNA
SERVICES
CRIF
DAY RISTOSERVICE
ENI
GRUPPO SOCIETA’ GAS RIMINI
MANUTENCOOP FACILITY MANAGEMENT
MOBY
RINA
SIENAMBIENTE
SISAL

7. Le nostre prime esperienze…

8. Come tutto ebbe inizio…
Cliente Caffè
Cliente
Media
Ilias inizia a
parlare di
metodologie
Agili
Partenza
di Ilias
ID
Funzionalità
0801
0502
1005
0600
1015
0124
Snow Flake indicatori Coffee Shop
Calcolo del numero di coffee shop
Universo in Business Object XI
Controllo errori cambio valuta
Dashboard Coffee Shop
Documentazione: VAR - Trader
Stato Stima Release
100%
100%
100%
100%
70%
20%
1Release1
1Release1
2Release2
1Release2
16Release2
3Release2

9. Caso cliente

10. Il contesto Progettuale
 Key User: Controllo di gestione e Amministrazione
 3 diverse sorgenti informative: sistemi gestionali
 Doppia anima del progetto:
 Nostro Progetto: Motore di calcolo, reporting, budgeting, simulazioni
 Progetto Parallelo: Contabilizzazione e gestione fatture
 Forti aspettative dal Top Management

11. Il giorno prima del kick-off
Verifichiamo il
gantt?
Ehm… il gantt?
Ecco il Release Plan
Sì il piano…
Release
1
Ma questo non è
un gantt!
Ma è la
stessa
cosa!
Releas
e1
Ehm… aspetta…
Allora?
Release
2
Releas
e2
Releas
e3
Releas
e4
Releas
e5
Release
3
Release
4
Release
5
Ok… ci
lavoriamo!

12. Il kick-off: gantt-ification
Release
1
Release
2
Release
3
Ottobre
Release
4
Release
5
Dicembre
Release
6
Release
7
Release
8
Febbraio
Release
9
Release
10
Aprile
Giugno
Il nostro piano
Budget e Rolling
Chiusure Amm
Reporting CdG e Amm
Simulazione
Recupero Storico
1°Rilascio Esercizio
Budget
Rilascio
finale
Parallelo
Business Blue Print
Il progetto parallelo
Approvazione BBP
Titoli e Contratti
Verifica Fatture e Workflow
Ammortamenti Fissi e Variabili
Chiusure e Reportistica
Recupero Storico
UAT e
Integration Test

13. Proponiamo al cliente continui rilasci incrementali

14. La prima release…

15. La seconda release…

16. La sprint demo mostra i risultati e rende felice il cliente

17. Il cliente era contento…
…ma eravamo esausti!

18. Alla prima retrospettiva decidiamo di rialzarci
Cosa è andato bene?
Cosa è andato male?
Cosa abbiamo imparato?
Cosa possiamo fare meglio?

19. Capiamo che occorre fare ordine

20. Creiamo uno Sprint Backlog
EDGN
Perc Attività
completata
1
4
100%
-
2
0,5
1,5
100%
-
Calcolo Ammortamento Run
9
2
7
100%
-
Calcolo Cash Cost
7
2
4
100%
-
Maschera titolo: Inserire la lookup su Investiment
Obligation
1
1
100%
-
Maschera verifica ammortamento in valuta
2
100%
-
SF: reporting; Chiusura Amm
6
Specifiche di Interfaccia HYP<->SAP
2
Produzione estrazione contabilizzazioni SAP
1
1
100%
Automatizzazione estrazione Hyp->SAP
2
2
0%
2
Inserire Il Trim nel'XLST del client
1
1
0%
1
1,5
1
0%
1,5
Funzionalità
Stima (g)
SIVA
Maschera Inserimento Titoli
5
Maschera Curve Run 24 mese
Rilascio in collaudo dei nuovi sviluppi e bugfix
GAGA
2
2
Giornate
mancanti
4
60%
2,4
2
50%
1
0,5
-

21. Sapevamo cosa fare ma non se ce l’avremmo fatta
…e finiviamo sempre con l’acqua alla gola

22. Quindi introduciamo il Burndown Chart
Burndown Chart
Rappresentazione grafica del lavoro rimasto rispetto al tempo. Nell’asse X è rappresentato il
tempo, nell’asse Y il lavoro (giornate/uomo).
Si aggiorna automaticamente in funzione delle percentuali di avanzamento aggiornate
quotidianamente nello sprint backlog.
45
40
35
30
25
Eff
20
Est
15
10
5
21-dic
20-dic
19-dic
18-dic
17-dic
16-dic
15-dic
14-dic
13-dic
12-dic
11-dic
10-dic
09-dic
08-dic
07-dic
06-dic
05-dic
04-dic
03-dic
02-dic
01-dic
30-nov
29-nov
28-nov
27-nov
26-nov
25-nov
24-nov
23-nov
0

23. Alla fine il nostro processo era così
Sprint incrementali della durata di circa tre settimane ciascuno.
Sprint BackLog
Calcolo Ammortamento Run
Maschera Input Rendicontazione
Rilascio
SAL settimanale
23-nov
Sprint Planning
Meeting
Calcolo Passaggi Run Stimati
Excel con Ammortamento Run
UAT
21-dic
Verificare Ammortamento Lineare
su Hiatus fuori dal range di validità
50
40
30
20
SAL settimanale 10
0
14-dic
Import dati IBMS
07-dic
Logica Actual/Actual Revised
30-nov
Cash Cost Minumum Garantee
Burndown chart
Retrospettiva
Approvazione utente
specifica funzionale
iterazione n+1
Sviluppo
Analisi funzionalità iterazione n+1
Week 0 - Inizio
Iterazione n
Week 1
Week 2
Week 3 – Fine
iterazione n

24. Sprint 6
10
5
0
45
40
35
30
25
20
Eff
15
Est
25-gen
0
23-gen
5
20
Est
21-gen
10
19-gen
15
Eff
17-gen
20
15-gen
25
13-gen
30
11-gen
35
09-gen
40
40
07-gen
45
05-gen
Sprint 3
03-gen
21-dic
19-dic
17-dic
15-dic
13-dic
11-dic
09-dic
07-dic
05-dic
03-dic
01-dic
29-nov
27-nov
25-nov
23-nov
Burndown Chart di tre diversi Sprint
Sprint 4
35
30
25
15
Eff
10
Est
5
0

25. BE-LEAN

26. BE-LEAN Framework

27. Metodologia
Pianificazione
 Piano dei deliverables
 Misurazione delle velocità
 Piccole e frequenti
release (mensili)
 Coinvolgimento del cliente
Design
 Simple Design
Sviluppo
 Definire gli standard
 DONE Definition
Organizzazione
 Scrum Team (self organizing)
 Sit Together
Testing
Controllo
 critica periodica, revisione
della metodologia
 Miglioramento continuo
 Test Driven Development

28. Pratiche
Pianificazione
 User stories (funzionalità)
 Backlog
 Planning poker
Design
 Spike Solutions
 Set-Based Design
Sviluppo
Organizzazione




Stand-up meeting
Sprint demo
Utilizzo della carta nei dettagli
Wall-based Taskboard
 Tecnica del pomodoro
 Pair programming
 Refactoring
Testing
Controllo
 Burn-down chart
 Retrospective
 Unit Test First

29. Le chiavi di successo
 Persone e interazioni:
 Qualità
rapporti vis-a-vis
 Funzionalità (no attività)
come cuore dei progetti
 Motivazione
delle persone
 Semplificazione,
auto-organizzazione,
ritmo nella gestione
 Flessibilità
 Riduzione dell’uso della
tecnologia nei dettagli
 Risk Management
 Frequenti release,
feedback continuo
 Miglioramento
 Coinvolgimento del cliente
continuo

30. Dove siamo oggi?
Cliente
Media
Arriva PierG: un boost
alla diffusione delle
metodologie agili in
azienda
Altri Clienti…
Crescita e diffusione in
azienda. Sviluppo di
strumenti di gestione e
controllo dei progetti
che agevolino un
approccio agile.
Ci accorgiamo che abbiam
lavorato tantissimo sul
processo (Scrum style) e
sulla cultura (Lean style) ma
troppo poco
sull’automatizzazione (XP
style)
Tanti tavoli di ricerca e
innovazione avviati:
• Automatizzazione
degli sviluppi
• Automatizzazione del
deploy
• Suite di testing

31. I Trade-off

32. Intro
 Causa problemi logistici con la sala, non ci è stato possibile condividere alcuni concetti
durante la sessione.
 Condividiamo nelle slide che seguono alcune parti più discorsive in modo da condividere
comunque in maniera rapida e semplice alcuni concetti.
 Se siete interessati ad approfondimenti contattateci:
 Twitter:
 @andreascavolini
 @SimoneVannicola
 Oppure ci trovate su LinkedIn

33. Progetti a pacchetto Vs Agilità
 Progetto a pacchetto: budget predefinito su un perimetro non modificabile
 In un modello waterfall la «sotenibilità» del progetto deriva da una chiara definizione dei
requisiti e del perimetro progettuale
 Nella realtà, nel corso del progetto, scope e requisiti cambiano anche significativamente.
 Molto spesso ci troviamo di fronte a proposte «agiliste» che spingono per riportare alla
ribalta i progetti «time and material». Tale proposta non è accettata dalla maggior parte
delle grandi aziende.
 La nostra esperienza ci porta a dire che è più semplice lavorare su progetti a pacchetto con
una metodologia agile che waterfall! E quindi why not?
 Occorre solo avere l’accortezza di definire alcune regole del gioco con i clienti come:
 Si deve sensibilizzare il cliente sul fatto che un UAT chiude il ciclo di sviluppo delle
funzionalità validate. Occorre mostrare flessibilità sì, ma soprattutto sul futuro e non
infiniti ricicli su quanto già realizzato.
 È importante tenere fermo lo scope della sprint in corso e posticipare gli sviluppi delle
richieste spot dell’utente nelle sprint successive, in quanto distraggono il team, creano
stress e generano bug.

34. Release Planning vs Gantt
 I vantaggi di utilizzare un gantt per il controllo del progetto sono:
̵ Intuitiva visione dell’insieme
̵ Se la sequenza e il piano vengono rispettati è “facile” individuare ritardi e ripianificare il
piano “slittandolo”
 I limiti di utilizzare un gantt sono:
̵ Il piano è una rappresentazione rigida della realtà e non è possibile seguirlo passo passo.
̵ Ogni task tenderà ad essere iniziato all’ultimo (aumento dei rischi) e ad essere finito alla
data prestabilita perfino quando si è in anticipo (aumento dei costi).
̵ Si utilizza una struttura per attività (Work Breakdown Structure) che non rispecchia il
valore per il cliente di ogni funzionalità (Feature Breakdown Structure)
̵ Molto spesso le dipendenze individuate non sono reali! Occorre cercare di rompere tutte
le dipendenze ogni volta che è possibile!
 Approccio Lean:
̵ Utilizza un gantt di alto livello allo scopo di definire delle milestones interne ed essere
comunicativi con il cliente.
̵ Gestisci il progetto utilizzando un backlog e strumenti come burndown chart

35. Story Point vs Man-Days
 Multiple team membership! Team formati con risorse non completamente dedicate su un
singolo progetto.
 Non riusciamo ad avere una misura oggettiva della velocità ossia degli Story Point rilasciabili in
ogni singola iterazione
 Stima di ciascuna funzionalità per Man Days
 Si effettua una stima della velocità e delle giornate «nette» che il team può dedicare al progetto.
 Planning Poker e valutazione della stima in funzione della complessità di ogni singola funzionalità
e non in base a «io quanto ci metterei»
 Molti feedback derivanti dalle metriche che riusciamo a derivare tramite Timesheet integrato:
Release
Gg
Gg
%
Budget Stima Compl.
Stima
Gg a
Finire
Gg Utili
Budget
Valore
Efficienza
Rilasciato
Release1
64
64
100%
84
0
6.400
6.400
-2000
Release2
58
50
100%
56
0
5.800
5.800
200
Release3
74
73
100%
72
0
7.400
7.400
200
Release4
79
64
100%
74
0
7.900
7.900
500
Release5
59
46
74%
48
12
5.900
4.361
-439

36. Big Design Up Front vs Incremental Design
 In generale nei progetti complessi per grandi clienti viene richiesto di definire un design a priori
 Nel nostro caso lavoriamo anche su architetture applicative a cascata fortemente
interdipendenti
 La tentazione è di effettuare un Big Design Up Front (BDUF)
 Lavorando su architetture a flusso siamo comunque costretti dare un design della macro
soluzione. Tale attività viene fatta anche con una macro-analisi effettuata con gli utenti con lo
scopo di coprire il livello giusto di design o Just Enough Design Up Front (JEDUF)
 Man mano che il progetto procede viene effettuata l’analisi dell’iterazione successiva e viene
incrementalmente evoluto il design della soluzione.

37. Ritmo Vs disponibilità degli utenti
 In un contesto ideale l’utente è parte del team e fornisce i requirement «just in time»
 In contesti meno ideali il Product Owner sopperisce a eventuali assenze degli utenti
 In contesti paradossali il Demand scrive un documento e lo passa al team.
 In ogni caso, release frequenti necessitano frequenti incontri con gli utenti per l’analisi delle
funzionalità da realizzare e gli User Acceptance Test (UAT) sulle funzionalità rilasciate.
 Nelle grandi aziende la disponibilità degli utenti è un fattore critico.
 Nella nostra esperienza il miglior metodo è stato bilanciare il just in time con un anticipo
delle specifiche in modo di avere un cuscinetto di funzionalità già analizzate (almeno
sufficiente alla successiva release o superiore prima di periodi che vedono gli utenti
impegnati in altre attività).
 Per quanto riguarda i rilasci in produzione, il team deve cercare di lavorare mantenendo
iterazioni a ritmo costante senza necessariamente rilasciare in produzione ogni release.
Quando gli utenti tornano disponibili si svolge UAT sulle funzionalità di più iterazioni e si
rilascia in esercizio.

38. Essere agili non è il fine ma il mezzo per il miglioramento continuo