1.
Firenze 6.5.2010

2.
a war story
2

3.
 Fabio Armani
• CTO di Sequenza SpA
• CEO di OpenWare
• Direttore artistico dell‟etichetta
Different Lands
• Certified Scrum Pratictioner
3

4.
 Preludio → esposizione dei temi
 I Movimento → allegretto in forma di sonata
 II Movimento → adagio quasi un blues
 III Movimento → scherzo
 IV Movimento → allegro con fuoco
 Postludio → conclusione
4

5.
Esposizione dei temi

6.
 Motivazione
 Enterprise Agility
 Roadmap
o Il percorso verso l‟azienda Agile
6

7.
 Il processo di migrazione da un approccio di tipo waterfall
alle metodologie agili in azienda rappresenta una tematica
complessa che richiede coraggio, dedizione e capacità di
affrontare difficoltà ed errori.
 Questo talk vuole essere il racconto reale (da qui il sotto titolo:
“a war story”) della mia esperienza pluriennale in qualità di
CTO e di Senior Manager impegnato nel diffondere nel
contesto italiano le metodologie agili a livello Enterprise (in
particolare Agile Modeling, XP, Scrum e Lean
Development), coinvolgendo quindi tutti i livelli della
azienda, a partire dall‟organizzazione strutturale e strategica
fino ai dettagli operativi (tool open source di project
management e full life-cycle).
7

8.
 Certamente molti sono riusciti ad introdurre le metodologie
agili a livello di team.
 Questo, che è certamente il punto più facile da cui partire, ma
non è la sfida maggiore che un organizzazione di sviluppo
deve affrontare. E …
 certamente non rappresenta il traguardo in cui terminare il
processo d‟innovazione e trasformazione.
 Il vero obiettivo dovrebbe essere quello di creare …
8

9.
9

10.
 Un fatto certo è che l‟azienda ha la necessita di essere agile!
 Deve essere in grado di:
• rispondere a forze competitive esterne,
• avere una migliore comprensione del mercato,
• dei propri errori, affrontare i cambiamenti della tecnologia o
• qualunque altro elemento possa influire in modo positivo o negativo
sull‟azienda stessa.
 L‟agilità a livello dei team è necessaria ma non sufficiente;
 L‟Agilità Aziendale richiede quella dei team, ma questa è solo un
mezzo verso il fine che è appunto: l‟Enterprise Agility !
 Quest‟ultima consente ad una azienda di realizzare prodotti di qualità
e servizi ai propri clienti in modo più veloce rispetto ai propri
concorrenti.
10

11.
 Come raggiungere il grande obiettivo di portare l‟Agilità a
livello aziendale e vincere quetsa sfida estremamente
complessa?
 Cosa e chi è coinvolto?
 Cosa è richiesto per creare del vero valore per
l‟organizzazione?
 Ogni cosa deve concorrere a realizzare valore per l‟intera
organizzazione!
 Qual è il percorso da compiere?
11

12.
Azienda non Agile Azienda Agile
Cambiamenti
Scontro Rollout Cambiamenti
Progetti pilota Accettazione organizzativi Formalizzazione
culturale aziendale globali
locali
12

13.
Allegretto » in forma di sonata

14.
 Azienda non-Agile
 Progetti pilota
o Metodologia adottata Scrum & AUP
 Accettazione
14

15.
Azienda non Agile
 Struttura organizzativa basata su silos
 Scarsa cultura aziendale
 Cowboy programming
 Assenza di una vera metodologia
 Processo di sviluppo non ben definito e comunque
basato sul Waterfall
15

16.
Azienda non Agile
 Una tipica struttura organizzativa basata su silos.
• In cui si aveva una separazione di mansioni, ruoli e responsabilità.
 Questo ha portato a:
• una scarsa condivisione
degli obiettivi;
• una netta separazione di ruoli
e professionalità;
• gravi difficoltà di comunicazione
• incapacità a gestire i cambiamenti
• mancanza di vera cooperazione
16

17.
Azienda non Agile
 Scarsa cultura aziendale
 Mancanza di condivisione di informazioni e nozioni
 La struttura organizzativa a silos ha favorito la poca
socializzazione e l‟individualismo
 Altri importanti aspetti da considerare:
• Mancanza di dati storici (metriche, stime …)
• Ripetizione di errori precedenti
• Assenza di un Knowledge Management System o di una Intranet
aziendale reale
17

18.
Azienda non Agile
 Cowboy programming è una forma di sviluppo
software priva di un effettivo metodo definito.
 I membri del team procedono in modo caotico con
nessuna o pochissima guida e senza alcuna
metodologia ne processo di sviluppo.
Wikipedia
18

19.
Azienda non Agile
 Non esisteva in azienda una vera metodologia.
 Lo sviluppo dei progetti era quindi demandato ad una serie
di Project Manager (di cui peraltro era poco definito ruolo e
profilo) e ad un „pool‟ di risorse condivise tra più progetti per
le quali valeva un processo basato sull‟allocazione „time
sharing‟
• Con evidenti problemi di context switching
• Mancanza di vero commitment ed ownership nei progetti
• Poca se non nulla attenzione alla qualità sia intrinseca che estrinseca
19

20.
Azienda non Agile
 Né il processo di sviluppo, né le diverse fasi erano ben
definite, anche se esistevano dei documenti redatti
essenzialmente per la qualità ISO 9000.
• Più formali che di sostanza;
• non ben conosciuti e mal percepiti praticamente da tutti;
• sicuramente lontani dalla quotidianità e dall‟operatività.
 Il processo si rifaceva grossolanamente a RUP, pesante
e gravato da una scarsa comprensione di una reale
metodologia iterativa ed incrementale → Waterfall
20

21.
Progetti
pilota
 Si decide di procedere con
un 1° progetto pilota per
verificare l‟efficacia e la
percezione della
metodologia Agile
• Effort: ~220 story points
• Elapsed: 4 months
• Team: 5 people
21

22.
Progetti
pilota
 Scrum → come metodologia di sviluppo, in termini di:
• Ceremonies (Sprint Planning, Daily Scrum, Sprint Demo, Retrospective)
• Roles (pigs: SM, PO & Team + chickens)
• Artifacts (Product Backlog, Sprint Backlog, Burn Down Charts)
 AgileUP → come wrapper utilizzato per gestire le diverse fasi
del progetto:
• Inception (1)
• Elaboration (2)
• Construction (4)
• Transition (1)
22

23.
Progetti
Accettazione
pilota
23

24.
Progetti
Accettazione
pilota
 Se il costo del cambiamento cresce lentamente nel
tempo si può agire in modo totalmente differente
rispetto a quanto si fa sotto l‟assunzione che tale
costo cresca esponenzialmente.
 Scrum ed alcune pratiche XP vengono provate con
successo da parte del team nel pilot.
 Soddisfazione e partecipazione attiva del cliente.
24

25.
Accettazione
 Notevole accettazione della metodologia da parte del
team coinvolto.
 Vengono condivisi:
• Obiettivi e Vision
• Valori (comunicazione, semplicità, rispetto …)
• Principi
• Pratiche (planning game, test driven development …)
 Riscontro estremamente positivo dei risultati ottenuti.
 Desiderio di diffondere l‟esperienza …
25

26.
Andante » quasi blues

27.
 Il problema
• Scontro culturale
 Altri ostacoli
27

28.
Scontro culturale
28

29.
Scontro
Accettazione
culturale
 Assenza di reale condivisione a livello aziendale
di:
• Obiettivi comuni
• Valori » ritenuti inutili
• Principi » praticamente antitetici ai precedenti
• Pratiche » poiché poco ortodosse
 Netta contrapposizione da parte del Management
più conservatore
29

30.
Scontro
culturale
 Difficoltà di condividere ed accettare l‟Agile …
 a causa di molti fattori:
• differenza culturale
• diffidenza reciproca
• sospetto verso l‟innovazione (cinismo)
• inadeguatezza a cambiare
• … lascio a voi altre possibili motivazioni
30

31.
Impedimenti al processo
31

32.
Scontro
culturale
 Ostacoli pricipali:
 Management
 Businessmen
 Contesto italiano
 Resistenza al cambiamento
32

33.
Scontro
culturale
 Presenza in azienda di un Management
• Con mentalità arretrata
• Legato a vecchi valori e principi
• Amante delle gerarchie
• Spesso autoritario
33

34.
Scontro
culturale
 Struttura commerciale
• Troppo interessata ad un guadagno immediato
• Poco attenta alla qualità
• Sovrapposizione di progetti
in contrapposizione
reciproca
34

35.
Scontro
culturale
35

36.
Scontro
culturale
 Mancanza di volontà e desiderio di parte
dell‟azienda di accettare la nuova metodologia.
 Resistenza al cambiamento
R=V/I
36

37.
Scherzo » progressive

38.
 Cambiamenti organizzativi locali
 Formalizzazione del processo
 Impegno aziendale » adozione dell‟ Agile in tutti i
progetti
 Lancio di un progetto di Rollout Aziendale
 Cambiamenti aziendali su larga scala
• Nascita del Modello Organizzativo Agile
38

39.
Cambiamenti
Scontro
organizzativi
culturale
locali
 Cambiamenti organizzativi locali
• Adozione di un processo di sviluppo iterativo ed incrementale
• Certificazione di alcuni Scrum Master e Product Owner
• Utilizzo di Scrum e di alcune pratiche XP
• Test Driven Development
• Continuous Integration
• 40 hours
• Pair programming, side by side programming
• Information radiators
39

40.
Cambiamenti
organizzativi
locali
 Allo scopo di avere una transizione verso una
azienda Agile che abbia realmente successo, ogni
rischio (sia reale che percepito) associato con
l‟introduzione dello sviluppo Agile necessità di
essere risolto rapidamente dal senior
management.
40

41.
Cambiamenti
organizzativi
locali
41

42.
Dalle premesse si evincono le strategie
42

43.
Cambiamenti
Formalizzazione
organizzativi
locali
 A seguito del definirsi dei cambiamenti
organizzativi locali
 Si procede ad una prima formalizzazione del
processo Agile
43

44.
Formalizzazione
44

45.
Formalizzazione
Value System
• People
• Collaboration
• Honesty
• Trust
Agile
Adaptive
Attitude
Ecosystem
• Thinking guided
• Thightly couples by principles and
self-organizing reflected in
Team to a Product behaviour
Owner
Simple
framework
• Self organisation
• Visibility
• Inspection
• Adaptation
45

46.
Formalizzazione
 Sistemi di valori
• Persone
• Collaborazione
• Onestà
• Fiducia
 Attitudine
 Un framework per gestire il cambiamento
 Ecosistema adattativo
46

47.
Formalizzazione
Comunicazione
Feedback Semplicità
Coraggio Rispetto
47

48.
Formalizzazione
 Si avrà successo nel momento in cui si adotterà uno
stile che celebrerà un set consistente di valori che
serviranno sia le necessità umane che quelle di tipo
commerciale:
• Comunicazione
• Semplicità
• Feedback
• Coraggio
• Rispetto
48

49.
Formalizzazione
Favour Over
Individual and interactions Processes and tools
Comprehensive
Working software
documentaition
Customer collaboration Contract negotiation
Responding to change Following a plan
50

50.
Formalizzazione
La nostra massima priorità è soddisfare il cliente,
•per mezzo di tempestivi e continui rilasci di software di valore
Siano benvenuti i cambiamenti nelle specifiche,
•anche a stadi avanzati dello sviluppo.
I processi agili sfruttano il cambiamento
•a favore del vantaggio competitivo del cliente.
Rilascia software funzionante frequentemente,
•da un paio di settimane a un paio di mesi,
•con preferenza per i periodi brevi.
Manager e sviluppatori devono lavorare insieme
•quotidianamente lungo il progetto.
Basa i progetti su individui motivati.
52

51.
Formalizzazione
Il software funzionante
• è la misura primaria di progresso
I processi agili promuovono uno sviluppo sostenibile.
• Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere un ritmo costante
indefinitamente.
L'attenzione continua per l'eccellenza tecnica e il buon design
• esaltano l'agilità.
La semplicità
• l'arte di massimizzare l'ammontare di lavoro non svolto
• è essenziale.
Le migliori architetture, specifiche e design
• emergono da team auto-organizzati.
A intervalli regolari il team riflette su come diventare più efficace,
• dopodiché mette a punto e aggiusta il suo comportamento di conseguenza.
53

52.
Formalizzazione
 Motivati dal manifesto agile:
• Un disegno semplice e snello
• Test automatici
• Molta pratica nel modificare il disegno (design
emergente)
• Refactoring
• Clean Code
54

53.
 Agilità vuol dire …
55

54.
Formalizzazione
 Le quattro variabili fondamentali da considerare nello
sviluppo di un progetto aziendale sono:
• Costo
• Tempo
Qualità
• Ambito (scope)
Ambito
• Qualità → variabile
56

55.
Formalizzazione
 Waterfall
Ambito
Qualità
variabile
Tempo Costo
57

56.
Formalizzazione
 Agile
Qualità
Ambito
variabile
Tempo Costo
58

57.
Formalizzazione
 Le principali forze positive che hanno guidato il
cambiamento sono state:
• le persone (dalla base)
• il supporto della dirigenza tecnica
• la volontà di cambiamento condivisa
• L‟impegno e l‟operato sia del comitato ETC che del
Rollout Team
• La capacità di imparare dai nostri errori
59

58.
Rollout
Formalizzazione
aziendale
 Si decide di procedere con l‟adozione delle
metodologie agili e di Scrum su larga scala per
tutti i progetti.
 Si fa dunque partire il processo di Rollout
Aziendale che avverrà con le stesse modalità di un
progetto agile.
60

59.
Rollout
aziendale
 Si utilizza un processo iterativo ed incrementale
per la gestione del cambiamento
 Utilizzo di Scrum e di S2 (Scrum of Scrums) per
gestire il progetto di Rollout aziendale e il
coordinamento tra i diversi team
 Creazione di un Enterprise Transition Committee
(ETC)
 Creazione di un Rollout Team (RT)
61

60.
Rollout
aziendale
 Si procede a pianificare la transizione
utilizzando le seguenti regole:
• Definizione dello scopo
• della strategia
• dei pezzi (story card)
• dei giocatori (Sviluppo e Commerciale)
• delle mosse
62

61.
Cambiamenti
Rollout
Organizzativi
aziendale
globali
 Il risultato del Rollout aziendale è l‟attuazione di una serie di
cambiamenti Organizzativi globali
 Il modello organizzativo Agile si distingue dal precedente per
una serie di importanti fattori:
• Generalizing Specialist
• Holistic Team (cross functional)
• Condivisione a tutti i livelli di
 obiettivi,
 valori
 e principi
• Responsabilità e Leadership globali
• Sinergia tra i diversi team
67

62.
Cambiamenti
Organizzativi
globali
 Separare le responsabilità commerciali da quelle tecniche.
 Chiave fondamentale della strategia è quella di tenere i
tecnici focalizzati su problemi tecnici e i commerciali su
quelli commerciali.
 Nessuna delle due parti dovrebbe essere in grado di
decidere unilateralmente.
68

63.
Cambiamenti
Organizzativi
globali
 I commerciali (POs) decidono:
• scopi e tempi di realizzazione delle release
• priorità relative delle funzionalità proposte
• scopo esatto delle funzionalità
 Rispetto a queste scelte i tecnici (SMs & Teams)
contribuiscono:
• stimando i tempi di realizzazione
• valutando le conseguenze tecnologiche
• adottando un processo di sviluppo che ben si adatti alle proprie
personalità
• scegliendo pratiche e sequenza di sviluppo
69

64.
Quality Assurance
Quality
Mercury Team Jupiter Team Halley Romanian Team 1
Program 1
Project 1 Project 3
Task 1 Task N
Project 2 Project N
Proxy Proxy
Life-Cycle Management
CRM Test
Systems - DBA
70

65.
Azienda Agile
Cambiamenti
Organizzativi
globali
  Il sistema solare
I team prendono il nome dei pianeti
• Mercury
• Venus
• Earth
• Mars
• Jupiter
• Saturn
• Uranus
• Neptune
71

66.
Azienda Agile
 Modello organizzativo » Team
 Modello di conoscenza » Pratiche
 Modello di competenza » Aree
72

67.
73

68.
Azienda Agile
 Mercury
 Neptune
 Focus sulle seguenti aree:
• Quality Assurance,
• DBA,
• Lifecycle,
• Learning
 Sincronizzano i propri Sprint con quelli degli altri
team
 Partecipano a S2
74

69.
75

70.
Azienda Agile
 Venus
 Earth
 Mars
 Jupiter
 Saturn
76

71.
77

72.
78

73.
Azienda Agile
 Ceres
 Pluto
 Halley
 Vengono gestiti mediante i Proxy PO
79

74.
Team Jupiter @ Scrummorra
80

75.
 I team lavorano collettivamente nel proprio open space
suddiviso nelle seguenti aree:
 Il Laboratorio (set di tavoli affiancati per favorire le pratiche
XP di pair programming, osmotic communication …)
 Il Pensatoio (vicino alle lavagne)
 Integrazione e Test (es: Venera 7, Vygr)
 Comunicazione (attrezzata con Skipe, video camera …)
 Realizzano nuove funzionalità in modalità Test Driven
Development e Agile Modeling
 Sono cross-functional e si auto organizzano
81

76.
82

77.
83

78.
84

79.
 Alcuni giorni della settimana all‟ora di pranzo effettuiamo delle
round table per confrontarci e discutere assieme su differenti
tematiche …
• Retrospettive sulle metodologie adottate » Scrum, Lean
• Meccanismi di interscambio e cooperazione tra i team
• Principi metodologici
• Domain Driven Design (DDD)
• Agile Modeling
• UML
• Design Patterns …
 Inoltre una volta la settimana si effettuano gli incontri
dell‟Enterprise Rollout Team che ha il compito di gestire la
transizione operativa dell‟azienda verso Scrum e di rimuovere gli
impediments emersi duranti gli Scrum of Scrums
85

80.
Allegro con fuoco » electronic

81.
 Parziale crisi e soluzioni adottate
 Cambiamenti aziendali su larga scala
• Nascita del Modello Organizzativo Agile
 Oltre l‟ Agile
87

82.
Azienda Agile
 Improvviso cambiamento dall‟esterno:
• Nuovo assetto societario
• Cambio della classe dirigente
• Interruzione del processo di rollout aziendale
 Necessità della condivisione di filosofia, valori,
principi e pratiche con nuovi attori
88

83.
Azienda Agile
 Come il blues delle origini evolve in una carica evolutiva
e progressive così si trasforma l‟Azienda Agile.
 La metodologia si evolve a partire da Scrum verso
Scrum#
 Integrazione tra Agile ed istanze di processo:
• Qualità
• Processi aziendali distribuiti
• Altri ruoli
89

84.
90

85.
91

86.
92

87.
 Il diagramma rappresenta il flusso dalla concettualizzazione
verso il cliente, tramite la gestione del product portfolio
(inclusa la definizione dei progetti su cui lavorare), i team di
sviluppo e nuovamente verso i clienti per l‟utilizzo finale del
software sviluppato.
 Necessari per il successo:
• Allineamento con la visione di
business
• Un management altamente
focalizzato
• Pratiche tecniche di alta qualità
93

88.
 Un unica taglia non soddisfa tutti. Un‟opportuna miscela di „best pratice‟ e
di processi direttivi è richiesta per affrontare le diverse problematiche
che le diverse aree aziendali devono affrontare .
 L‟azienda è composta da:
• Product Management
• Product Portfolio
• Customer Base
• Teams
 L‟attenzione a soltanto una, o ad una porzione di queste componenti porta
a sub-ottimizzazione e risultati non-ottimali. Lean-Thinking ha dimostrato
di essere il veicolo necessario per migliorare la qualità, diminuire il „time
to market‟ contemporaneamente abbassando i costi.
 Lean assume una visione Aziendale ed ha largamente dimostrato di poter
fornire un contesto per il pensiero Agile che ha certamente migliorato la
produttività dei team.
94

89.
Kanban
Lean Emergent
Scrum
Design
Agile
XP
95

90.
 Ritengo che quando cerchiamo di capire come realizzare la
transizione allo scopo di essere più efficaci, abbiamo
bisogno di comprendere dove siamo, dove vogliamo andare
e quali abilità abbiamo che ci consentono di compiere il
percorso da dove siamo verso dove vogliamo andare.
 Questo significa che dobbiamo guardare a:
 Quali sono le forze presenti al momento attuale nella nostra
organizzazione? Queste includono:
• Dominio(i) applicativi
• Impedimenti della nostra organizzazione
• I livello corrente delle nostre abilità
 In quali attitudini crede la nostra organizzazione?
96

91.
 Forze presenti nell‟Organizzazione attuale
• Application domain(s)
• Impedimenti dell‟Organizzazione attuale
 Come i team lavorano assieme
 Come è gestito il product portfolio aziendale
• Il livello attuale degli skill
 Attitudini portate dalla metodologia Software
• Ambito del processo (team, enterprise wide)
• Attitudine verso il management
• Focalizzarsi sui sistemi o sulle persone
 In sostanza le organizzazioni dovrebbero accertare
divario Conoscere » Fare e come questo si relazioni
con il lavoro dei team e con i processi che portano
valore per il cliente
97

92.
Principi di Lean Management
98

93.
 L‟utilizzazione ottimale porta ad una produttività sub-
ottimale
 “There is no free lunch”
 Il ritardo ha sempre un costo !
99

94.
 Avete un “inventario” di progetti
 Grandi giacenze sono negative:
• Costano molto
• Nascondono molti problemi
• Sono intrinsecamente lente
100

95.
Ruolo e responsabilità
101

96.
Azienda Agile
 Nascita del ruolo di Project Management Office
(Lean-Agile PMO)
 Integrazione del processo Agile con CMMI:
• Definizione di standard aziendali
• Modifica dei processi e delle procedure di qualità ISO 9000
• Identificazione di metriche
• Estrazione e disamina dei risultati (feedback)
102

97.
Azienda Agile
 Il Product Management Office (PMO) è in rapida
evoluzione in molte realtà project-based.
 Tale evoluzione si sostanzia in:
• una estensione dell'area di intervento del PMO, vale a dire un
allargamento del suo raggio d'azione all'interno
dell'organizzazione dell'azienda;
• una crescita dell'influenza esercitata dal PMO sui risultati aziendali
(fatturato, margine di contribuzione, fidelizzazione dei clienti,
sviluppo di nuovi prodotti, posizionamento competitivo).
103

98.
 Tracciare il flusso dei progetti
 Gestire l‟inserimento (On-Ramp)
 Terminare i progetti malati
 Spezzare grandi progetti in altri più piccoli
104

99.
 Evitare troppi progetti
simultanei
 Esercitare la leadership:
dando priorità ai progetti e
focalizzando i propri team
 Ritardare gli impegni,
ritardare i consumi
 Effettuare consegne
continuamente in piccoli
gruppi rispetto ad effettuare
rilasci infrequenti con
„infornate‟ enormi
105

100.
 Team multipli ognuno dei quali focalizzato su un
singolo progetto
 Dedicati a piattaforme o linee di business
 Il Platform owner guida la priorità dei prossimi progetti
 Risultati:
• Supportare linee multiple di business simultaneamente
• Sforzo focalizzato sui risultati » veloci consegne per progetti
individuali
• Una chiara responsabilità
106

101.
 Silos tradizionali
Product
PM BA Designer Developer Tester
Owner
107

102.
 Core
Project Team BA
Designer SM/PM
Developer
Core Project DBA
Team
Developer Tester
Product
Owner
108

103.
 Core Project Team » cross functional
• Business Analyst (BA)
• Scrum Master (o Project Manager)
• DBA
• Tester
• Developer
• Product Owner
• Designer (Front End )
 Olistico
109

104.
 Extended
Project Team Release
Manager
Capacity
Architect
Planner
BA
Designer SM/PM Peripheral
Project Teams
Risk Assessor Developer
Core Team DBA Prod
Developer Tester
Product
Owner
Tech Ops Security
Integrated
Platform-based
Team Business
Sponsor
110

105.
 Core Project Team
 Peripheral Project Teams
• Realease Manager
• Capacity Planner
• Security
• Production
• Business Sponsor
• Technical Operationals
• Risk Assessor
• Architect
111

106.
“… una grande organizzazione
per poter essere efficace deve
agire come se fosse un gruppo di
piccole organizzazioni collegate.”
Divide et impera costruendo una
federazione di team agili:
 Realizzare l‟ “intero” nelle “parti”
 Porre un limite alla grandezza ( es. 7
+/- 2 persone)
 Per consentire la crescita, spezzare
nuovi Agile team integrati (Olistici)
una volta che il loro limite di
grandezza è stato raggiunto
 Coordinare ad alto livello mediante il
Lean-Agile PMO
112

107.
113

108.
 Incoraggiare il dialogo faccia-a-faccia attraverso i diversi
livelli
 Sovrapposizione del management mediante “linking pins”
 PMO agisce come un Agile project team
114

109.
Azienda Agile
 Utilizzare Agile project delivery
• Integrated platform-based teams
• Effettuale piccoli rilasci il più frequentemente possibile
 Applicare il Lean Thinking per ottimizzare l’intero
portfolio di progetto
• Ottimizzare per la produttività (throughput)
• Ridurre l‟inventario di progetto/WIP
• Gestire i vincoli (constraints)
 I Lean-Agile PMO possono avere un grande impatto
sulle performance del portfolio di progetti
• PMO gestisce il delivery del portfolio di progetti
• PMO agisce come un agile project team
115

110.
 L‟obiettivo :
Veloce flusso di produzione di Obiettivi Chiave che abbiano Valore
ed Alta Qualità.
KEY CHALLENGES THE AGILE GAME’S SOLUTIONS
Shared vision in large teams Individuals cannot win, only Teams
Objective definition and validation of value Customers/Product Owners define “Value”
End users validate “Value”
Team energy & accountability Teams are measured together
116

111.
Azienda Agile
 Molti team Agili si focalizzano sul proprio lavoro e si
coordinano solo successivamente.
 L‟organizzazione di Enterprise Teams deve essere
creata considerando il piano generale » incluso come
essi lavoreranno assieme.
117

112.
Azienda Agile
 Utilizzo di Atlassian JIRA e di vari plugin come
GreenHopper ed altri, per gestire in modo integrato:
• Progetti di sviluppo
• Progetti cross funzionali
• Progetti aziendali
• CRM
• Gestione economica
• Anagrafica dei clienti
118

113.
Azienda Agile
 Integrazione del sistema Atlassian JIRA con:
• IDE → Eclipse, IntelliJ Idea
• CASE di modellazione UML → Sparxsystem Enterprise Architect
• Continuous Integratiuon → Atlassian Bamboo
• Enterprise Wiki → Atlassian Confluence
• Agile UI Modeling → Balsamic Mockups
119

114.
Guardando oltre l‟Agile
120

115.
 Toyota Production System (TPS) » primo grande esempio di
Lean
Practices
Lean.
 Alle basi del TPS vi è l‟assoluta eliminazione dello spreco
(Muda), supportata dai seguenti due pilastri:
• Just-in-Time
TPS
• Autonomation, o automazione con un tocco umano
Continuous
Quality
Learning and
Management
Improvement
122

116.
 Il Lean thinking va visto non tanto come una collezione
di pratiche ma piuttosto come la combinazione di tre
fondamentali body of knowledge:
• Science
• Management
• Knowledge stewardship
123

117.
Flow, Cadence, Pull
Option Theory
Theory of Constraints
Lean Science
A3s, Kaizens Leaderhip
Continuous Education
Improvement Visual Controls
5 Whys
Lean
Lean
Knowledge
Management
Stewardship
124

118.
Flow, Cadence, Pull
Option Theory
Theory of Constraints
Lean Science
125

119.
 Just-in-Time
 Teoria dell‟utilizzazione
• Piccole code e batch size
• Limitare il WIP
• Little‟s law
• Cause di scarto
 Pull Management
 Opzioni reali
126

120.
Leaderhip
Education
Visual Controls
Lean
Management
127

121.
 Il Lean Management enfatizza la responsabilità che i
Manager devono avere per le performance dei loro
team.
 Non devono effettuare il micro-management
 I manager devono piuttosto divenire:
• leader
• allenatori
• educatori
 Più che “servant leader” dovrebbero essere percepiti
come parte del team, responsabili per fornire una
guida
128

122.
A3s, Kaizens
Continuous
Improvement
5 Whys
Lean
Knowledge
Stewardship
129

123.
 L‟amministrazione della conoscenza Lean include
l‟utilizzo appropriato di:
• A3s
• Kaizens
• After Action Reviews (AARs) e retrospettive
• Pratica dei Five Whys, la ricerca delle cause radice
• Il Value Stream mapping
 Deve essere inoltre chiaro che ottenere, mantenere e
diffondere la conoscenza è un fattore critico.
 Insegnare alle persone come imparare è anche questo
un fattore molto sostanziale.
130

124.
 Agile Software Development with Scrum - Ken Schwaber, Mike Beedle (Prentice Hall, 2001)
 Agile Project Management with Scrum - Ken Schwaber (Microsoft Press, 2004)
 Agile Retrospectives (Pragmatic, 2006)
131

125.
 Agile Project Management: Creating Innovative Products » Jim Highsmith
 Agile Software Development » Alistair Cockburn (Addison-Wesley, 2003)
 Agile Estimating and Planning » Mike Cohn (Addison-Wesley, 2003)
133

126.
 eXtreme Programming Explained » Kent Beck
 Planning eXtreme Programming » Kent Beck, Martin Fowler
 eXtreme Programming Installed » Ron Jeffries, Ann Anderson, Chet Hendrickson
134

127.
 Lean Software Development » Mary & Tom Poppendieck (Addison-Wesley, 2003)
 Implementing Lean Software Development » Mary & Tom Poppendieck (Addison-Wesley, 2005)
 Leading Lean Software Development » Mary & Tom Poppendieck (Addison-Wesley, 2008)
135

128.
 User Stories Applied: For Agile Software Development (Addison-Wesley Signature Series)
 Test Driven Development (The Addison-Wesley Signature Series)
 Refactoring to Patterns (Addison-Wesley Signature Series)
136

129.
Metodologie agili
137

130.
Altri amici …
138

131.
 AgileDevelopment
 AgileManifesto
 AgileAlliance
 AgileinAction
 ImplementingScrum
 ControlChaos
 AgileUP
 DSDM
 eXtremeProgramming
139

132.
42
140