Your SlideShare is downloading. ×
0
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Scaling Lean Agile - mini iad 2014

561

Published on

Perché parliamo di Scaling Lean Agile? …

Perché parliamo di Scaling Lean Agile?
Ci sono due aspetti primari inerenti lo scalare delle tecniche agili a livello di Enterprise che è necessario considerare. In primo luogo lo scalare delle tecniche agili a livello di progetto per affrontare le sfide peculiari che i team di progetto devono affrontare. In secondo luogo è lo scalare la vostra strategia agile attraverso l'intero reparto IT, in modo appropriato. E' abbastanza semplice applicare Lean Agile su una manciata di progetti, ma può essere molto difficile far evolvere la cultura e l’intera struttura organizzativa per adottare appieno il modo agile di lavorare.
Lean e Agile (in particolar modo metodologie come Scrum e XP) hanno pienamente dimostrato il loro valore a livello di team. Cosa succede però nel momento in cui tentiamo di utilizzarle in contesti reali più complessi? Nelle reali organizzazioni che caratterizzano un’importante parte del panorama dell'IT in Italia? Muovendosi dal livello dei team verso il livello dell'organizzazione si incontrano una serie di problematiche più complesse e per un certo verso nuove. Ecco quindi l'importanza di conoscere valori e principi che sono alla base del tema del Lean Agile Scaling. Esistono parecchi modelli che negli ultimi anni si confrontano con le realtà delle organizzazioni.
In questo talk tratteremo a livello olistico questo tema e confronteremo alcuni di tali modelli di Scaling Lean Agile, quali: Scrum standard (Ken Schwaber, Mike Cohn, ...) – il modello di Larmann & Vodde - SAFe – Disciplined Agile Delivery di Scott Ambler – Path to Agility (Ken Schwaber). Inoltre verranno affrontate e discusse le esperienze personali effettuate in diverse società in fase di adozione o utilizzo su larga scala di Lean Agile.

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
561
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
28
Comments
0
Likes
4
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Fabio  Armani   OpenWare  
  • 2. Agenda   •  Agile  Development   •  Extended  Lean  Agile  Frameworks   •  Disciplined  Agile  Development  (DAD)   •  Scaling  Agile  Framework  (SAFe)   •  Agility  Path  +  CIF   •  Large-­‐scale  Scrum   •  ConsideraEons   •  Conclusion   2
  • 3. Agenda   •  Agile  Development   •  Extended  Lean  Agile  Frameworks   •  Disciplined  Agile  Development  (DAD)   •  Scaling  Agile  Framework  (SAFe)   •  Agility  Path  +  CIF   •  Large-­‐scale  Scrum   •  ConsideraEons   •  Conclusion   3
  • 4. What  Agile  is  NOT  !!  
  • 5. Accelerate  Eme  to  market   Managing  changing  prioriEes   BeMer  align  IT/Business   Increase  producEvity   Enhance  soOware  quality   Project  visibility   Reduce  risks  
  • 6. Agile  Overtakes  Waterfall  
  • 7. Improve  things  with  Scrum   Remove  waste     •  Technical  debt     •  Unnecessary  documentaEon     •  Unnecessary  requirements     •  Unused  requirements     •  Architecture  that  must  be   reworked   Improve  producEvity     •  Collocated,  self-­‐organizing  teams     •  Cross-­‐funcEonal  teams     •  FTF  communicaEons     •  Improved  decision  making    
  • 8. Technical   Prac6ces?  Project   Ini6a6on?   Release  into   Produc6on?   Operate  in   Produc6on?  Enterprise   Disciplines?   Project   Selec6on?  
  • 9. Lean  Agile  @Enterprise  
  • 10. Does  Agile  Scale?  YES   Scaling:   •  The  majority  of  agile  teams  are  geographically  distributed  in  some  manner   •  OrganizaEons  have  reported  successful  agile  programs  of  500+  people   •  One  third  of  agile  teams  are  in  regulatory  situaEons   •  75%  of  organizaEons  doing  agile  are  doing  so  on  medium  complexity  or  greater  projects   •  17%  of  organizaEons  are  successfully  applying  agile  in  outsourcing  situaEons   •  78%  of  teams  are  working  with  legacy  systems   •  32%  of  organizaEons  report  successful  interacEon  between  enterprise  architects  and  agile   teams   •  11%  of  organizaEons  report  that  their  governance  strategy  works  well  with  agile  teams   (yikes)       Source:   •  DDJ  November  2009  State  of  the  IT  Union  Survey,  www.ambysoO.com/surveys/    
  • 11. Small-­‐scale  vs  Large-­‐scale  
  • 12. Small-­‐scale  vs  Large-­‐scale  
  • 13. Small-­‐scale  vs  Large-­‐scale  
  • 14. Small-­‐scale  vs  Large-­‐scale  
  • 15. Small-­‐scale  vs  Large-­‐scale  
  • 16. Small-­‐scale  vs  Large-­‐scale  
  • 17. Small-­‐scale  vs  Large-­‐scale  
  • 18. Problems  of  Scaling   §  SoS  –  Scrum  Of  Scrums   –  Becomes  more  difficult  aOer  6  or  so  Teams   –  Planning  &  Ceremonial  Events  conflict   §  Doesn’t  really  address  a  Porlolio  &  Program  View   –  SEll  thinks  of  smaller  “projects”   –  Planning  Roadmap  horizons  are  sEll  short   §  Fails  to  recognize  that  Waterfall  sEll  exists   §  Governance  &  Authority  start  to  fail   –  No  Clear  Content  Authority  once  you  scale  to  a  Program  or  Porlolio  level   –  Who  resolves  prioriEes  across  dozens  of  teams?   –  Who  then  drives  releases?  
  • 19. 24 Problems  of  Scaling   §  ReporEng  &  Metrics  aren’t  sufficient  across  large  numbers  of  teams  or   programs   §  TradiEonal  sources  of  informaEon  (Scrum/Agile  Alliance)  aren’t  mature  to   help  this   –  Note:  In  Jan  ‘2013  Ken  Schwaber  introduced  CIF  –  ConEnuous  Improvement   Framework    
  • 20. Agenda   •  Agile  Development   •  Extended  Lean  Agile  Frameworks   •  Disciplined  Agile  Development  (DAD)   •  Scaling  Agile  Framework  (SAFe)   •  Agility  Path  +  CIF   •  Large-­‐scale  Scrum   •  ConsideraEons   •  Conclusion   25
  • 21. What  Should  a  Scaled  Framework   Address?   §  Mul6ple  Agile  Teams   –  Should  be  able  to  handle  dozens  of  teams  (Scrum   starts  to  break  around  7)   –  IncorporaEon  of  XP  Engineering  pracEces   §  Waterfall  Teams   –  They  sEll  exist.  Not  everything  can  be  Agile   §  Program  Level  planning  and  views  
  • 22. What  Should  a  Scaled  Framework   Address?   §  Governance  and  shared  resources     (like  Enterprise/System  Architects,  UX,  etc.)   §  Specialized  teams  for  Release  planning,  system   integra6on   §  Clear  content  authority   §  PorPolio  Management  and  the  management  of   WIP  
  • 23.  
  • 24. DAD  -­‐  Disciplined  Agile  Delivery  
  • 25. The  Disciplined  Agile  Lifecycle:   An  extension  of  Scrum  
  • 26. Concept:  The  Agile  3C  Rhythm     Incep6on       Coordinate     Construc6on       Collaborate     Transi6on       Conclude   Release rhythm Itera6on   Planning       Coordinate     Development       Collaborate     Stabilize       Conclude   Iteration rhythm CoordinaEon   MeeEng       Coordinate     Daily  work       Collaborate     Stabilize       Conclude   Daily rhythm The Coordinate-Collaborate-Conclude rhythm occurs at several scales on a DAD project:
  • 27. The  IncepEon  Phase  
  • 28. Typical  ConstrucEon  IteraEon  
  • 29. Typical  day  during  construcEon  
  • 30. The  TransiEon  phase  
  • 31. * Slide Courtesy of IBM Agile Scaling Factors
  • 32. DAD  -­‐  Disciplined  Agile  Delivery   •  Decision  oriented  framework  
  • 33.  
  • 34. SAFe  -­‐  Scaled  Agile  Framework  
  • 35. SAFe  -­‐  Scaled  Agile  Framework  
  • 36. Roots  of  the  Scaled  Agile  Framework  
  • 37. Scaled  Agile  Framework  –  Big  Picture  
  • 38. Agile  Teams  
  • 39. Scale  to  Program  Level  
  • 40. Scale  to  Porlolio  
  • 41. SAFe  –  Scaling  Agile  Framework   •  PrescripEve  framework  
  • 42. DAD  vs  SAFe  
  • 43.  
  • 44. Evidence-Based Management (“EBM”): •  Roots in the medical practice. •  The application of direct, objective evidence* by managers to make decisions. •  For software development, EBM is employed to maximize the value of software to the entire organization. A Matter of Managerial Culture Evidence, broadly construed, is anything presented in support of an assertion: •  Strongest type of evidence is that which provides direct proof of the validity of the assertion. •  Weakest type of evidence is that which is merely consistent with the assertion, but doesn’t rule out contradictory assertions, as in circumstantial evidence. *Source: Wikipedia
  • 45. Direct Evidence of an Organization’s Value
  • 46. Outcome Is Measured for Direct Evidence Of Value Current  Value   Ability  to  Innovate  Time  to  Market   Release   Frequency   Release   StabilizaEon   Cycle  Time   Installed   Version  Index   Usage  Index   InnovaEon  Rate   Defects   Revenue  per   Employee   Employee   SaEsfacEon   Customer   SaEsfacEon   Product  Cost   RaEo  
  • 47. Circumstantial evidence is evidence that relies on inference to connect it to a conclusion of fact, allowing more than one explanation to be possible: •  Usually accumulates into a collection so the pieces become corroborating evidence. •  Explanation involving circumstantial evidence becomes more valid as proof of a fact when the alternative explanations have been ruled. Entry points to collect circumstantial evidence
  • 48. Diagnosing circumstantial evidence in organizational patterns Process   Produc6vity   Value   Quality   Enterprise     •  Scrum   •  Self-­‐ organizaEon   •  Product   Backlog   •  Sprint   Planning   •  Daily  Scrum   •  Sprint  Review   •  Sprint   RetrospecEve   •  Scaling  Scrum   •  DefiniEon  of   Done   •  TesEng   •  Clean  code   •  Test-­‐Driven   development   •  ConEnuous   IntegraEon   •  Emergent   Architecture   •  Accountability   •  Transparency   •  Product  Backlog   •  Alignment   •  Release  planning   and  orientaEon   •  Porlolio   Management   •  Engineering   standards   •  Architecture   •  QA   •  ALM   •  CommunicaEon   •  OrganizaEon     •  Culture   •  People   PracEces   •  Sales   •  Lean  
  • 49. Relating value to organizational patterns Informs  priority  Measure Diagnose Improve Influences  Outcomes   More at http://evidencebasedmanagement.org
  • 50. EBM measures the value of the organization. EBM  
  • 51. EBM diagnoses likely contributors, and discovers capabilities you can build on. EBM  
  • 52. EBM helps you improve by using evidence as a driver of change EBM  
  • 53. Agility Path implements Evidence-Based Management Repeat  
  • 54. Agility  Team   •  Enterprise Product Owner –  Domain Product Owner –  Product Owner •  Enterprise Change Team –  Domain Change Team –  Change Team •  Enterprise Scrum Master –  Domain Scrum Master –  Scrum Master
  • 55. Agility  Path  Events   •  Sprint •  Sprint Planning –  Functional Change –  Sprint Goal •  Weekly Scrum •  Evaluation –  Sprint Review –  Sprint Retrospective
  • 56. Agility  Path  ArEfacts   •  Practice Backlog •  Sprint Backlog •  Evaluation Backlog •  Increment of Change
  • 57. Agility  Path  Metrics   •  Agility Index •  Agility Acceleration
  • 58. Scale  Scrum  Beyond  Your  Team   •  “We  have  worked  with  thousand  of  organizaEons  that  are   aMempEng  to  become  more  effecEve  and  more  agile.   •  They  usually  start  by  implemenEng  Scrum.   •  Then  they  are  faced  with  the  issue  of  how  to  get  the  most  out   of  their  investment  in  Scrum.   •  They  wonder  how  to  manage  its  scaling  throughout  the   organizaEon.”  
  • 59. CIF  Overview   •  CIF  consists  of  two  interacEng  processes:  product   development  and  con6nuous  improvement.  
  • 60. Product  Development  Process   •  The  CIF  product  development  process  lays  out  the  flow  of   work  through  the  major  product  development  funcEons  of   product  management,  program  management,  and  product   development,  based  on  Scrum.   •  These  are  then  integrated  into  porlolio  and  product  family   management  for  mulEple  products  and  systems.   •  The  work  flows  into  and  out  of  the  Product  Backlog.  
  • 61. ConEnuous  Improvement  Process     •  The  CIF  con6nuous  improvement  process  implements  new   agile  pracEces  into  the  product  development  process.  It   periodically  captures  metrics  and  pracEce  usage.   •  PaMerns  of  metrics  and  pracEces  are  assessed  for  dysfuncEon   and  effecEveness.   •  Your  overall  agility  is  compared  to  that  in  other  organizaEons.   •  Ways  to  increase  the  effecEveness  for  conEnuous   improvement  are  devised  and  applied.  
  • 62. Process  InteracEon     •  CIF  is  oriented  around  two  databases:     –  Metrics  -­‐  are  implanted  in  the  product  development  process  and  a  baseline  is  created.   Processes  are  periodically  sampled  to  measure  change  in  producEvity,  quality,  value,   agility,  and  key  performance  indicators.   –  Prac6ces  -­‐  that  maximize  value  and  eliminate  waste  are  applied  to  change  your  current   processes.  They  are  organized  by  the  business  funcEons  of  product  development,  sales,   markeEng,  finance,  human  resources,  and  customer  support.  These  pracEces  are   ordered  and  tracked  in  the  pracEce  backlog  so  their  progressive  adaptaEon  and   implementaEon  conEnuously  improve  your  organizaEon,  as  reported  by  the  metrics.   PracEce  details  are  referenced  from  a  pracEce  database.    
  • 63.  
  • 64. Scaling  Lean  &  Agile  Development  
  • 65. Scaling  Lean  &  Agile  Development   •  Large  Scale  Scrum  is  Scrum:  change  implicaEons   •  Fractal  structure   •  Feature  teams  vs  Components  Teams   •  Lean  Concepts  and  Principles   •  Complex  Systems   •  Queues  theory  
  • 66. Scaled  Lean  &  Agile   •  Empirical  oriented  framework  
  • 67. Agenda   •  Agile  Development   •  Extended  Lean  Agile  Frameworks   •  Disciplined  Agile  Development  (DAD)   •  Scaling  Agile  Framework  (SAFe)   •  Agility  Path  +  CIF   •  Large-­‐scale  Scrum   •  Considera6ons   •  Conclusion  
  • 68. Ken Schwaber
  • 69. Ken Schwaber co-founder of Scrum
  • 70. unSAFe  at  any  speed   Many  organizaEons  will  open  their  checkbooks   for  SAFe  and  its  partners.  I  suggest  that  they   measure  the  improvement,  as  that  is  the  job  of   management.  Investments  are  supposed  to   have  returns.     Ken  Schwaber  
  • 71. unSAFe  at  any  speed   •  Measure:   –  Cycle  Eme  –  quickest  Eme  to  get  one  feature  out   –  Release  cycle  –  Eme  to  get  a  release  out   –  Defects    –  change  in  defects   –  ProducEvity  –  normalized  effort  to  get  a  unit  of  funcEonality  “done”   –  StabilizaEon  –  aOer  code  complete,    %  of  a  release  is  spent  stabilizing  before  release   –  Customer  saEsfacEon  –  up  or  down   –  Employee  saEsfacEon  –  up  or  down  
  • 72. unSAFe  at  any  speed   •  A  core  premise  of  Agile  is  that  the  people  doing  the  work  are  the  people   who  can  best  figure  out  how  to  do  it.   •  The  job  of  management  is  to  do  anything  to  help  them  do  so,  not   suffocate  them  with  SAFe!   Ken  Schwaber  
  • 73. Abandoning  a  Process-­‐Centric   Approach  to  Improvement     David J. Anderson
  • 74. Kanban  >  anE-­‐SAFe   The  Kanban  Method  will  coexist  with  SAFe  in  the   marketplace.  People  will  choose  between  a  modern   21st  Century  approach  to  complex  situaEons  or  a   familiar  20th  Century  approach  to  change  and  their   soOware  engineering  processes.  Choice  is  good  in  a   marketplace!  Kanban  offers  a  counter-­‐intuiEve   innovaEve  modern  approach.  SAFe  offers  something   familiar.     David  J.  Anderson  
  • 75. Kanban  >  anE-­‐SAFe   Coexistence  of  SAFe  and  Kanban  is  a  good  thing.   Providing  alternaEve  approaches  to  large  scale   business  agility  is  a  good  thing.  Both  approaches  will   carry  the  label  "Agile."  Both  will  be  marketed  as   soluEons  scaling  Agile.    
  • 76. Kanban  >  anE-­‐SAFe   Coexistence  of  SAFe  and  Kanban  is  a  good  thing.   Providing  alternaEve  approaches  to  large  scale   business  agility  is  a  good  thing.  Both  approaches  will   carry  the  label  "Agile."  Both  will  be  marketed  as   soluEons  scaling  Agile.  I  believe  there  is  considerable   irony  in  that.     David  J.  Anderson  
  • 77. Dave Snowden father of Cynefin Framework
  • 78. SAFe:  the  infan9lism  of  management   Dave Snowden
  • 79. SAFe  :  infanElism  of  …   Put  brutally  SAFe  seemed  to  be  PRINCE  II  camouflaged   in  Agile  language.  SCRUM  as  an  approach  was   emasculated  in  a  small  box  to  the  boMom  right  of  a   hugely  overcomplicated  linear  model.  The  grandiose   name  of  a  dependency  map  was  applied  to  something   which  is  no  different  from  a  PERT  chart  and  in  general   what  we  had  is  an  old  stale  wine  forced  into  shiny  new   wineskins.     Dave  Snowden  
  • 80. SAFe  :  infanElism  of  …   My  strong  and  increasingly  passionate  argument  was   that  SAFe  is  not  only  a  betrayal  of  the  promise  offered   by  AGILE  but  is  a  massive  retrograde  step  giving  the   managerial  class  an  excuse  to  avoid  any  significant   change.   Dave  Snowden  
  • 81. SAFe  :  infanElism  of  …   …  Such  excuses  abound  and  allowing  these  false  linear   models  to  perpetuate  themselves  is  a  form  of   infanElism,  a  failure  to  carry  through  on  the  need  for   change.  In  parEcular  the  failure  to  realize  that  soOware   development  needs  to  be  seen  as  a  service  and  as  an   ecology  not  as  a  manufacturing  process.   Dave  Snowden  
  • 82. A  possible  way  …  
  • 83. 100%  predictability  =   0%  innova6on  
  • 84. Value  &  Impact  >  Velocity  
  • 85. Culture  >  Process   •  Shu-­‐level  Scrum  can  get  you  out  a  ditch,  but  won’t  make  you  fly.   –  Learn  the  rules  so  you  can  break  them.   •  Healthy  Culture  heals  broken  process.   –  Hack  the  culture,  and  process  will  follow.   •  Agile  is  Fragile.   –  It  is  only  sustainable  over  the  long  term  if  all  parts  of  the  organizaEon  are  commiMed  to   it.   •  You  are  the  culture.   –  Model  the  behavior  you  want  to  see.  
  • 86. Lean  from  the  trenches  
  • 87. Lean  Mindset  
  • 88. Agility  AdopEon  Rather  Than   Agile  At  Scale  
  • 89. Keep  the  values,  keep  the  principles,   think  for  yourself.    
  • 90. Keep  the  values,  keep  the  principles,   think  for  yourself.    
  • 91. Keep  the  values,  keep  the  principles,   think  for  yourself!     Ken Schwaber
  • 92. Agenda   •  Agile  Development   •  Extended  Lean  Agile  Frameworks   •  Disciplined  Agile  Development  (DAD)   •  Scaling  Agile  Framework  (SAFe)   •  Agility  Path  +  CIF   •  Large-­‐scale  Scrum   •  ConsideraEons   •  Conclusion   124

×