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
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
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
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
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
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
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
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
43. Cambiamenti
Formalizzazione
organizzativi
locali
A seguito del definirsi dei cambiamenti
organizzativi locali
Si procede ad una prima formalizzazione del
processo Agile
43
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
54. Formalizzazione
Le quattro variabili fondamentali da considerare nello
sviluppo di un progetto aziendale sono:
• Costo
• Tempo
Qualità
• Ambito (scope)
Ambito
• Qualità → variabile
56
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
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
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
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
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
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
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
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
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
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
116. 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
117. 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
118. 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
120. 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
122. 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
124. 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
125. 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
126. 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
127. eXtreme Programming Explained » Kent Beck
Planning eXtreme Programming » Kent Beck, Martin Fowler
eXtreme Programming Installed » Ron Jeffries, Ann Anderson, Chet Hendrickson
134
128. 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
129. 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