lean agile development - a war story (better software 2010)

Download Lean Agile Development - a war story (Better Software  2010)

If you can't read please download the document

Upload: fabio-armani

Post on 08-May-2015

2.726 views

Category:

Technology


4 download

DESCRIPTION

Slide del talk in italiano relativo a "Lean Agile Development - a war story" presentato alla conferenza Better Software 2010.

TRANSCRIPT

  • 1.Firenze 6.5.2010

2. a war story 2 3. Fabio Armani CTO di Sequenza SpA CEO di OpenWare Direttore artistico delletichetta Different Lands Certified Scrum Pratictioner3 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 Roadmapo Il percorso verso lazienda Agile6 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 dallorganizzazione 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 dinnovazione e trasformazione. Il vero obiettivo dovrebbe essere quello di creare 8 9. 9 10. Un fatto certo che lazienda 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 negativosullazienda stessa. Lagilit a livello dei team necessaria ma non sufficiente; LAgilit Aziendale richiede quella dei team, ma questa solo un mezzo verso il fine che appunto: lEnterprise Agility ! Questultima 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 lAgilit a livello aziendale e vincere quetsa sfida estremamente complessa? Cosa e chi coinvolto? Cosa richiesto per creare del vero valore per lorganizzazione? Ogni cosa deve concorrere a realizzare valore per lintera organizzazione! Qual il percorso da compiere? 11 12. Azienda non AgileAzienda AgileCambiamentiScontroRolloutCambiamenti Progetti pilota Accettazione organizzativi Formalizzazioneculturale aziendale globali locali12 13. Allegretto in forma di sonata 14. Azienda non-Agile Progetti pilotao 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 lindividualismo 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 reale17 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.Wikipedia18 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 sullallocazione 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 estrinseca19 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 dalloperativit. Il processo si rifaceva grossolanamente a RUP, pesante e gravato da una scarsa comprensione di una reale metodologia iterativa ed incrementale Waterfall 20 21. Progettipilota Si decide di procedere con un 1 progetto pilota per verificare lefficacia e la percezione della metodologia Agile Effort:~220 story points Elapsed: 4 months Team:5 people 21 22. Progettipilota 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 pilota23 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 lassunzione 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 lesperienza 25 26. Andante quasi blues 27. Il problema Scontro culturale Altri ostacoli27 28. Scontro culturale 28 29. ScontroAccettazioneculturale 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 conservatore29 30. Scontroculturale Difficolt di condividere ed accettare lAgile a causa di molti fattori: differenza culturale diffidenza reciproca sospetto verso linnovazione (cinismo) inadeguatezza a cambiare lascio a voi altre possibili motivazioni30 31. Impedimenti al processo 31 32. Scontroculturale Ostacoli pricipali: Management Businessmen Contesto italiano Resistenza al cambiamento32 33. Scontroculturale Presenza in azienda di un Management Con mentalit arretrata Legato a vecchi valori e principi Amante delle gerarchie Spesso autoritario33 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 dellazienda 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. CambiamentiScontroorganizzativiculturale 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 radiators39 40. Cambiamentiorganizzativi locali Allo scopo di avere una transizione verso una azienda Agile che abbia realmente successo, ogni rischio (sia reale che percepito) associato con lintroduzione dello sviluppo Agile necessit di essere risolto rapidamente dal senior management.40 41. Cambiamenti organizzativilocali 41 42. Dalle premesse si evincono le strategie 42 43. Cambiamenti Formalizzazioneorganizzativi locali A seguito del definirsi dei cambiamenti organizzativi locali Si procede ad una prima formalizzazione del processo Agile 43 44. Formalizzazione 44 45. FormalizzazioneValue System People Collaboration Honesty Trust Agile AdaptiveAttitude Ecosystem Thinking guided Thightly couples by principles and self-organizingreflected in Team to a Productbehaviour OwnerSimpleframework Self organisation Visibility Inspection Adaptation45 46. Formalizzazione Sistemi di valori Persone Collaborazione Onest Fiducia Attitudine Un framework per gestire il cambiamento Ecosistema adattativo 46 47. Formalizzazione Comunicazione Feedback SemplicitCoraggio 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 FavourOver Individual and interactions Processes and toolsComprehensive Working software documentaition Customer collaboration Contract negotiation Responding to changeFollowing a plan50 50. Formalizzazione La nostra massima priorit soddisfare il cliente,per mezzo di tempestivi e continui rilasci di software di valoreSiano benvenuti i cambiamenti nelle specifiche,anche a stadi avanzati dello sviluppo.I processi agili sfruttano il cambiamentoa 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 insiemequotidianamente lungo il progetto.Basa i progetti su individui motivati. 52 51. Formalizzazione Il software funzionante la misura primaria di progressoI 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 variabile56 55. Formalizzazione Waterfall Ambito Qualit variabileTempo Costo 57 56. Formalizzazione Agile Qualit Ambito variabileTempo 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 Limpegno e loperato sia del comitato ETC che del Rollout Team La capacit di imparare dai nostri errori59 58. Rollout Formalizzazioneaziendale Si decide di procedere con ladozione 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. Rolloutaziendale 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 mosse62 61. Cambiamenti RolloutOrganizzativi aziendale globali Il risultato del Rollout aziendale lattuazione 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 team67 62. Cambiamenti Organizzativiglobali 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. CambiamentiOrganizzativi 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 sviluppo69 64. Quality Assurance Quality Mercury Team Jupiter Team Halley Romanian Team 1 Program 1Project 1 Project 3 Task 1 Task N Project 2 Project N Proxy Proxy Life-Cycle Management CRM TestSystems - DBA70 65. Azienda AgileCambiamenti Organizzativiglobali 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 Aree72 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 allora 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 dellEnterprise Rollout Team che ha il compito di gestire la transizione operativa dellazienda 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 Agile87 82. Azienda Agile Improvviso cambiamento dallesterno: Nuovo assetto societario Cambio della classe dirigente Interruzione del processo di rollout aziendale Necessit della condivisione di filosofia, valori, principi e pratiche con nuovi attori88 83. Azienda Agile Come il blues delle origini evolve in una carica evolutiva e progressive cos si trasforma lAzienda 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 lutilizzo finale del software sviluppato. Necessari per il successo: Allineamento con la visione di business Un management altamente focalizzato Pratiche tecniche di alta qualit93 88. Un unica taglia non soddisfa tutti. Unopportuna miscela di best pratice e di processi direttivi richiesta per affrontare le diverse problematiche che le diverse aree aziendali devono affrontare . Lazienda composta da: Product Management Product Portfolio Customer Base Teams Lattenzione 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 AgileXP95 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 nellOrganizzazione attuale Application domain(s) Impedimenti dellOrganizzazione 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 cliente97 92. Principi di Lean Management 98 93. Lutilizzazione 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 responsabilit101 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 linserimento (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 tradizionaliProduct PM BA Designer Developer Tester Owner 107 102. Core Project TeamBADesignerSM/PM DeveloperCore ProjectDBA Team DeveloperTesterProduct Owner 108 103. Core Project Team cross functional Business Analyst (BA) Scrum Master (o Project Manager) DBA Tester Developer Product Owner Designer (Front End ) Olistico109 104. Extended Project Team ReleaseManager Capacity ArchitectPlanner BADesignerSM/PMPeripheralProject Teams Risk Assessor Developer Core TeamDBAProdDeveloper TesterProduct Owner Tech Ops Security IntegratedPlatform-basedTeamBusinessSponsor110 105. Core Project Team Peripheral Project Teams Realease Manager Capacity Planner Security Production Business Sponsor Technical Operationals Risk Assessor Architect111 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 team114 109. Azienda Agile Utilizzare Agile project delivery Integrated platform-based teams Effettuale piccoli rilasci il pi frequentemente possibile Applicare il Lean Thinking per ottimizzare lintero portfolio di progetto Ottimizzare per la produttivit (throughput) Ridurre linventario 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 team115 110. Lobiettivo : Veloce flusso di produzione di Obiettivi Chiave che abbiano Valore ed Alta Qualit. KEY CHALLENGES THE AGILE GAMES SOLUTIONSShared vision in large teams Individuals cannot win, only TeamsObjective definition and validation of value Customers/Product Owners define ValueEnd users validate ValueTeam energy & accountability Teams are measured together116 111. Azienda Agile Molti team Agili si focalizzano sul proprio lavoro e si coordinano solo successivamente. Lorganizzazione 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 clienti118 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 Mockups119 114. Guardando oltre lAgile 120 115. Toyota Production System (TPS) primo grande esempio diLeanPracticesLean. Alle basi del TPS vi lassoluta eliminazione dello spreco (Muda), supportata dai seguenti due pilastri: Just-in-TimeTPS Autonomation, o automazione con un tocco umano Continuous Quality Learning and ManagementImprovement 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 ConstraintsLean ScienceA3s, Kaizens LeaderhipContinuous Education ImprovementVisual Controls5 Whys LeanLeanKnowledge ManagementStewardship124 118. Flow, Cadence, Pull Option Theory Theory of ConstraintsLean Science125 119. Just-in-Time Teoria dellutilizzazione Piccole code e batch size Limitare il WIP Littles law Cause di scarto Pull Management Opzioni reali 126 120. Leaderhip EducationVisual ControlsLean Management127 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, KaizensContinuous Improvement5 WhysLean Knowledge Stewardship 129 123. Lamministrazione della conoscenza Lean include lutilizzo 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 Hendrickson134 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 eXtremeProgramming139 132. 42140