Scaling Lean Agile - mini iad 2014

1,173 views

Published on

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.

Scaling Lean Agile - mini iad 2014

  1. 1. Fabio  Armani   OpenWare  
  2. 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. 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. 4. What  Agile  is  NOT  !!  
  5. 5. Accelerate  Eme  to  market   Managing  changing  prioriEes   BeMer  align  IT/Business   Increase  producEvity   Enhance  soOware  quality   Project  visibility   Reduce  risks  
  6. 6. Agile  Overtakes  Waterfall  
  7. 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. 8. Technical   Prac6ces?  Project   Ini6a6on?   Release  into   Produc6on?   Operate  in   Produc6on?  Enterprise   Disciplines?   Project   Selec6on?  
  9. 9. Lean  Agile  @Enterprise  
  10. 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. 11. Small-­‐scale  vs  Large-­‐scale  
  12. 12. Small-­‐scale  vs  Large-­‐scale  
  13. 13. Small-­‐scale  vs  Large-­‐scale  
  14. 14. Small-­‐scale  vs  Large-­‐scale  
  15. 15. Small-­‐scale  vs  Large-­‐scale  
  16. 16. Small-­‐scale  vs  Large-­‐scale  
  17. 17. Small-­‐scale  vs  Large-­‐scale  
  18. 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. 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. 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. 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. 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. 23.  
  24. 24. DAD  -­‐  Disciplined  Agile  Delivery  
  25. 25. The  Disciplined  Agile  Lifecycle:   An  extension  of  Scrum  
  26. 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. 27. The  IncepEon  Phase  
  28. 28. Typical  ConstrucEon  IteraEon  
  29. 29. Typical  day  during  construcEon  
  30. 30. The  TransiEon  phase  
  31. 31. * Slide Courtesy of IBM Agile Scaling Factors
  32. 32. DAD  -­‐  Disciplined  Agile  Delivery   •  Decision  oriented  framework  
  33. 33.  
  34. 34. SAFe  -­‐  Scaled  Agile  Framework  
  35. 35. SAFe  -­‐  Scaled  Agile  Framework  
  36. 36. Roots  of  the  Scaled  Agile  Framework  
  37. 37. Scaled  Agile  Framework  –  Big  Picture  
  38. 38. Agile  Teams  
  39. 39. Scale  to  Program  Level  
  40. 40. Scale  to  Porlolio  
  41. 41. SAFe  –  Scaling  Agile  Framework   •  PrescripEve  framework  
  42. 42. DAD  vs  SAFe  
  43. 43.  
  44. 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. 45. Direct Evidence of an Organization’s Value
  46. 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. 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. 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. 49. Relating value to organizational patterns Informs  priority  Measure Diagnose Improve Influences  Outcomes   More at http://evidencebasedmanagement.org
  50. 50. EBM measures the value of the organization. EBM  
  51. 51. EBM diagnoses likely contributors, and discovers capabilities you can build on. EBM  
  52. 52. EBM helps you improve by using evidence as a driver of change EBM  
  53. 53. Agility Path implements Evidence-Based Management Repeat  
  54. 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. 55. Agility  Path  Events   •  Sprint •  Sprint Planning –  Functional Change –  Sprint Goal •  Weekly Scrum •  Evaluation –  Sprint Review –  Sprint Retrospective
  56. 56. Agility  Path  ArEfacts   •  Practice Backlog •  Sprint Backlog •  Evaluation Backlog •  Increment of Change
  57. 57. Agility  Path  Metrics   •  Agility Index •  Agility Acceleration
  58. 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. 59. CIF  Overview   •  CIF  consists  of  two  interacEng  processes:  product   development  and  con6nuous  improvement.  
  60. 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. 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. 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. 63.  
  64. 64. Scaling  Lean  &  Agile  Development  
  65. 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. 66. Scaled  Lean  &  Agile   •  Empirical  oriented  framework  
  67. 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. 68. Ken Schwaber
  69. 69. Ken Schwaber co-founder of Scrum
  70. 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. 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. 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. 73. Abandoning  a  Process-­‐Centric   Approach  to  Improvement     David J. Anderson
  74. 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. 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. 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. 77. Dave Snowden father of Cynefin Framework
  78. 78. SAFe:  the  infan9lism  of  management   Dave Snowden
  79. 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. 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. 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. 82. A  possible  way  …  
  83. 83. 100%  predictability  =   0%  innova6on  
  84. 84. Value  &  Impact  >  Velocity  
  85. 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. 86. Lean  from  the  trenches  
  87. 87. Lean  Mindset  
  88. 88. Agility  AdopEon  Rather  Than   Agile  At  Scale  
  89. 89. Keep  the  values,  keep  the  principles,   think  for  yourself.    
  90. 90. Keep  the  values,  keep  the  principles,   think  for  yourself.    
  91. 91. Keep  the  values,  keep  the  principles,   think  for  yourself!     Ken Schwaber
  92. 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

×