Agile WTF

4,673
-1

Published on

An introductory presentation by Naresh Jain on the essence of Being Agile vs. Following Agile and why being Agile is important? Naresh also shows an evolution of Agile methods over the last 11 years and the future of Agile. Also take a sneak preview into what challenges an organizations may face when trying to be agile?

Published in: Technology, Self Improvement

Agile WTF

  1. 1. Agile WTF! Naresh Jain naresh@agilefaqs.com twitter: @nashjain http://nareshjain.comFriday 15 June 2012 1
  2. 2. Agile WTF! Agile Way to Fail! Naresh Jain naresh@agilefaqs.com twitter: @nashjain http://nareshjain.comFriday 15 June 2012 1
  3. 3. Being ‘agile’ OVERFollowing ‘Agile’ Naresh Jain naresh@agilefaqs.com twitter: @nashjain http://nareshjain.comFriday 15 June 2012 2
  4. 4. Friday 15 June 2012 3
  5. 5. Friday 15 June 2012 4
  6. 6. Why is there only ONE Toyota or Apple today?Friday 15 June 2012 5
  7. 7. Processes are like haircuts Copying someone else’s rarely worksFriday 15 June 2012 6
  8. 8. Retrospec)ve  CoherenceFriday 15 June 2012 7
  9. 9. Retrospec)ve  Coherence Hindsight does not lead to foresight!Friday 15 June 2012 7
  10. 10. Albert EinsteinFriday 15 June 2012 8
  11. 11. A perfection of means, and confusion of aims, seems to be our main problem. Albert EinsteinFriday 15 June 2012 8
  12. 12. Process  is  a  placebo 9Friday 15 June 2012 9
  13. 13. Process  is  a  placebo Jared  spool’s  tricks  to  Dogma  con7nuum  arranges   terminology  from  improvisa7on  to  atrophy 9Friday 15 June 2012 9
  14. 14. Process is built on values and principles and tailored to fit its context Src: Jeff PattonFriday 15 June 2012 10
  15. 15. Src: Jeff PattonFriday 15 June 2012 11
  16. 16. MEFriday 15 June 2012 12
  17. 17. Friday 15 June 2012 13
  18. 18. MumbaiFriday 15 June 2012 14
  19. 19. Tech Talks!Friday 15 June 2012 15
  20. 20. FitNesse Panopticode ProTest DBFit FitDecorator ProFIT La"u Patang QWickFriday 15 June 2012 16
  21. 21. Friday 15 June 2012 17
  22. 22. Friday 15 June 2012 18
  23. 23. Friday 15 June 2012 19
  24. 24. Friday 15 June 2012 20
  25. 25. Friday 15 June 2012 21
  26. 26. Friday 15 June 2012 22
  27. 27. Taking ownership of a simple process Adapted from Jeff PattonFriday 15 June 2012 23
  28. 28. The  Ball  Point  GameFriday 15 June 2012 24
  29. 29. The  Ball  Point  Game Your  goal:  As  a  team  predictably  "process"  the  most  number    of  balls  in  a  round  by  passing  a   ball  to  each  member  You  have  3  rounds  to  get  the  best  score  you  canFriday 15 June 2012 24
  30. 30. The  Ball  Point  Game Your  goal:  As  a  team  predictably  "process"  the  most  number    of  balls  in  a  round  by  passing  a   ball  to  each  member  You  have  3  rounds  to  get  the  best  score  you  can Simple  structure:  Predict  the  number  of  balls  you  can  process  Pass  balls  for  2  minutes  (no  more,  no  less)  Take  2  minute  to  discuss  and  improve  your  strategyFriday 15 June 2012 24
  31. 31. The  Ball  Point  Game Your  goal:  As  a  team  predictably  "process"  the  most  number    of  balls  in  a  round  by  passing  a   ball  to  each  member  You  have  3  rounds  to  get  the  best  score  you  can Simple  structure:  Predict  the  number  of  balls  you  can  process  Pass  balls  for  2  minutes  (no  more,  no  less)  Take  2  minute  to  discuss  and  improve  your  strategy Simple  rules:  Everyone  must  touch  the  ball  for  it  to  be  “done”  The  ball  must  have  “air  )me”  -­‐  it  must  be  tossed  or  dropped  between  team  membersFriday 15 June 2012 24
  32. 32. Core  Agile  concepts  learned? Adapted from Jeff PattonFriday 15 June 2012 25
  33. 33. Core  Agile  concepts  learned?  Ideal  processes  use  a  simple  framework  -­‐  like  a  game   Adapted from Jeff PattonFriday 15 June 2012 25
  34. 34. Core  Agile  concepts  learned?  Ideal  processes  use  a  simple  framework  -­‐  like  a  game    Changing  your  strategies  &  tac7cs,  not  the  framework,  allow  you   to  improve   Adapted from Jeff PattonFriday 15 June 2012 25
  35. 35. Core  Agile  concepts  learned?  Ideal  processes  use  a  simple  framework  -­‐  like  a  game    Changing  your  strategies  &  tac7cs,  not  the  framework,  allow  you   to  improve    Process  improvement  comes  from  change   Adapted from Jeff PattonFriday 15 June 2012 25
  36. 36. Core  Agile  concepts  learned?  Ideal  processes  use  a  simple  framework  -­‐  like  a  game    Changing  your  strategies  &  tac7cs,  not  the  framework,  allow  you   to  improve    Process  improvement  comes  from  change    Skill  improvement  come  from  prac7ce   Adapted from Jeff PattonFriday 15 June 2012 25
  37. 37. Core  Agile  concepts  learned?  Ideal  processes  use  a  simple  framework  -­‐  like  a  game    Changing  your  strategies  &  tac7cs,  not  the  framework,  allow  you   to  improve    Process  improvement  comes  from  change    Skill  improvement  come  from  prac7ce    Certain  kind  of  es=mates  improves  with  frequent  measurement   Adapted from Jeff PattonFriday 15 June 2012 25
  38. 38. Core  Agile  concepts  learned?  Ideal  processes  use  a  simple  framework  -­‐  like  a  game    Changing  your  strategies  &  tac7cs,  not  the  framework,  allow  you   to  improve    Process  improvement  comes  from  change    Skill  improvement  come  from  prac7ce    Certain  kind  of  es=mates  improves  with  frequent  measurement    Velocity  is  agile’s  language  for  measuring  throughput   Adapted from Jeff PattonFriday 15 June 2012 25
  39. 39. Core  Agile  concepts  learned?  Ideal  processes  use  a  simple  framework  -­‐  like  a  game    Changing  your  strategies  &  tac7cs,  not  the  framework,  allow  you   to  improve    Process  improvement  comes  from  change    Skill  improvement  come  from  prac7ce    Certain  kind  of  es=mates  improves  with  frequent  measurement    Velocity  is  agile’s  language  for  measuring  throughput    Visibility  of  work  helps  us  make  improvement  decisions   Adapted from Jeff PattonFriday 15 June 2012 25
  40. 40. Core  Agile  concepts  learned?  Ideal  processes  use  a  simple  framework  -­‐  like  a  game    Changing  your  strategies  &  tac7cs,  not  the  framework,  allow  you   to  improve    Process  improvement  comes  from  change    Skill  improvement  come  from  prac7ce    Certain  kind  of  es=mates  improves  with  frequent  measurement    Velocity  is  agile’s  language  for  measuring  throughput    Visibility  of  work  helps  us  make  improvement  decisions    Reflec7on:  observing,  measuring  &  changing  is  the  means  for   process  improvement Adapted from Jeff PattonFriday 15 June 2012 25
  41. 41. Core  Agile  concepts  learned?  Ideal  processes  use  a  simple  framework  -­‐  like  a  game    Changing  your  strategies  &  tac7cs,  not  the  framework,  allow  you   to  improve    Process  improvement  comes  from  change    Skill  improvement  come  from  prac7ce    Certain  kind  of  es=mates  improves  with  frequent  measurement    Velocity  is  agile’s  language  for  measuring  throughput    Visibility  of  work  helps  us  make  improvement  decisions    Reflec7on:  observing,  measuring  &  changing  is  the  means  for   process  improvement  Team  work  is  an  individual  skill Adapted from Jeff PattonFriday 15 June 2012 25
  42. 42. “Simple, clear purpose and principles give rise to complex and intelligent behavior. Complex rules and regulations give rise to simple and stupid behavior.” Dee HockFriday 15 June 2012 26
  43. 43. Your  SoNware  Development  Game? What  would  be:  Your  goal  Simple  structure  Simple  rulesFriday 15 June 2012 27
  44. 44. The  Agile  Game Adapted from Jeff PattonFriday 15 June 2012 28
  45. 45. The  Agile  Game Your  goal:  As  a  team,  predictably  deliver  max  value  to  users  &  stakeholders Adapted from Jeff PattonFriday 15 June 2012 28
  46. 46. The  Agile  Game Your  goal:  As  a  team,  predictably  deliver  max  value  to  users  &  stakeholders Simple  structure:    As  a  team,  set  a  goal  &  plan  to  accomplish  the  work    Deliver  working  solu=on  by  the  end  of  a  fixed  cycle    Reflect  &  improve  your  Product,  Plan,  People  and  Process Adapted from Jeff PattonFriday 15 June 2012 28
  47. 47. The  Agile  Game Your  goal:  As  a  team,  predictably  deliver  max  value  to  users  &  stakeholders Simple  structure:    As  a  team,  set  a  goal  &  plan  to  accomplish  the  work    Deliver  working  solu=on  by  the  end  of  a  fixed  cycle    Reflect  &  improve  your  Product,  Plan,  People  and  Process Simple  rules:  Whole  team  works  together  &  takes  responsibility  for  the  outcome  Progress  and  quality  must  be  kept  visible  Finished  work  (working  solu=on)  is  the  only  measure  of  progress Adapted from Jeff PattonFriday 15 June 2012 28
  48. 48. Why Agile?Friday 15 June 2012 29
  49. 49. Lower  cost  of  change  curve Traditional cost profileFriday 15 June 2012 30
  50. 50. Lower  cost  of  change  curve Traditional cost profile Agile system cost profileFriday 15 June 2012 30
  51. 51. Clear  communica)on  is  the  founda)on “I’m glad we’re all agreed then.”Friday 15 June 2012 31
  52. 52. Get  mental  models  out  on  the  table “Ah...”Friday 15 June 2012 32
  53. 53. Convergence  through  itera)on “Ah!”Friday 15 June 2012 33
  54. 54. A  genuinely  shared  understanding “I’m glad we’re all agreed then.”Friday 15 June 2012 34
  55. 55. Tradi7onal  so>ware  development  fixes  scope   then  es7mates  to  figure  out  7me  and  cost Traditional software development Src: Jeff PattonFriday 15 June 2012 35
  56. 56. Tradi7onal  so>ware  development  fixes  scope   then  es7mates  to  figure  out  7me  and  cost Scope Traditional software development Time Cost (resources) Src: Jeff PattonFriday 15 June 2012 35
  57. 57. Tradi7onal  so>ware  development  fixes  scope   then  es7mates  to  figure  out  7me  and  cost Scope Traditional software development Time Cost (resources) Src: Jeff PattonFriday 15 June 2012 35
  58. 58. Tradi7onal  so>ware  development  fixes  scope   then  es7mates  to  figure  out  7me  and  cost Scope Traditional software development Time Cost (resources) Src: Jeff PattonFriday 15 June 2012 35
  59. 59. Agile  development  fixes  7me  and  cost,  then  leverages   itera7on  and  incremen7ng  to  maximize  scope   Scope Traditional software development Time Cost (resources) Src: Jeff PattonFriday 15 June 2012 36
  60. 60. Agile  development  fixes  7me  and  cost,  then  leverages   itera7on  and  incremen7ng  to  maximize  scope   Scope Traditional software development Time Cost (resources) Src: Jeff PattonFriday 15 June 2012 36
  61. 61. Agile  development  fixes  7me  and  cost,  then  leverages   itera7on  and  incremen7ng  to  maximize  scope   Scope Agile software development Traditional software development Time Cost (resources) Src: Jeff PattonFriday 15 June 2012 36
  62. 62. Agile  development  fixes  7me  and  cost,  then  leverages   itera7on  and  incremen7ng  to  maximize  scope   Cost Scope Time (resources) Agile software development Traditional software development Time Cost (resources) Src: Jeff PattonFriday 15 June 2012 36
  63. 63. Agile  development  fixes  7me  and  cost,  then  leverages   itera7on  and  incremen7ng  to  maximize  scope   Cost Scope Time (resources) Agile software development Traditional software development Time Cost Scope (resources) Src: Jeff PattonFriday 15 June 2012 36
  64. 64. Leverage  a  shared  understanding  of  desired  product   goals  to  minimize  scope  while  maximizing  value Cost Scope Time (resources) Agile software development Traditional software development Time Cost Scope (resources) Src: Jeff PattonFriday 15 June 2012 37
  65. 65. Leverage  a  shared  understanding  of  desired  product   goals  to  minimize  scope  while  maximizing  value Cost Scope Time (resources) Agile software development Traditional software development Time Cost Scope (resources) Target business goals & Src: Jeff Patton outcomesFriday 15 June 2012 37
  66. 66. Building  Quality  into  the  Process Toyoda LoomFriday 15 June 2012 38
  67. 67. Focus  on  Throughput Utilization (%) Source: Beyond Agile Software Development Becoming Lean, Mary Poppendieck, Poppendieck.llcFriday 15 June 2012 39
  68. 68. Tradi)onal  ProcessFriday 15 June 2012 40
  69. 69. Tradi)onal  ProcessFriday 15 June 2012 40
  70. 70. Applying  Lean  Principles   to  SoNware  DevelopmentFriday 15 June 2012 41
  71. 71. Applying  Lean  Principles   to  SoNware  Development End-to-End small slices of workFriday 15 June 2012 41
  72. 72. Applying  Lean  Principles   to  SoNware  Development End-to-End small slices 20 % done = 100 % usable of workFriday 15 June 2012 41
  73. 73. Lean  Principles  applied   to  SoNware  Development   Project Plan/Estimation Requirements Gathering Use Cases / Functional Specs Design Specifications Code Test Fix / Integrate $ Inception $ $ $ $Friday 15 June 2012 42
  74. 74. Itera)ve Adapted from Jeff PattonFriday 15 June 2012 43
  75. 75. Itera)ve Adapted from Jeff PattonFriday 15 June 2012 43
  76. 76. Itera)ve Adapted from Jeff PattonFriday 15 June 2012 43
  77. 77. Itera)ve Adapted from Jeff PattonFriday 15 June 2012 43
  78. 78. Incremental Adapted from Jeff PattonFriday 15 June 2012 44
  79. 79. Incremental Adapted from Jeff PattonFriday 15 June 2012 44
  80. 80. Incremental Adapted from Jeff PattonFriday 15 June 2012 44
  81. 81. Incremental Adapted from Jeff PattonFriday 15 June 2012 44
  82. 82. Itera)ve  AND  Incremental Adapted from Jeff PattonFriday 15 June 2012 45
  83. 83. Itera)ve  AND  Incremental • Mix  the  strategies: –Iterate to  find  and  improve  solu6ons –Increment to  add  func6onality   Adapted from Jeff PattonFriday 15 June 2012 45
  84. 84. Itera)ve  AND  Incremental • Mix  the  strategies: –Iterate to  find  and  improve  solu6ons –Increment to  add  func6onality   Adapted from Jeff PattonFriday 15 June 2012 45
  85. 85. Itera)ve  AND  Incremental • Mix  the  strategies: –Iterate to  find  and  improve  solu6ons –Increment to  add  func6onality   Adapted from Jeff PattonFriday 15 June 2012 45
  86. 86. Itera)ve  AND  Incremental • Mix  the  strategies: –Iterate to  find  and  improve  solu6ons –Increment to  add  func6onality   Adapted from Jeff PattonFriday 15 June 2012 45
  87. 87. Itera)ve  AND  Incremental • Mix  the  strategies: –Iterate to  find  and  improve  solu6ons –Increment to  add  func6onality   Adapted from Jeff PattonFriday 15 June 2012 45
  88. 88. Agile Birth of a new Software Movement!Friday 15 June 2012 46
  89. 89. Agile  has  evolved  over  many  years Src: Jeff PattonFriday 15 June 2012 47
  90. 90. Agile  Umbrella Agile XP Scrum DSDM FDD Adaptive Pragmatic Crystal LeanFriday 15 June 2012 48
  91. 91. Agile ManifestoFriday 15 June 2012 49
  92. 92. Agile Manifesto “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:Friday 15 June 2012 49
  93. 93. Agile Manifesto “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: – Individuals and interactions OVER processes and tools.Friday 15 June 2012 49
  94. 94. Agile Manifesto “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: – Individuals and interactions OVER processes and tools. – Working software OVER comprehensive documentation.Friday 15 June 2012 49
  95. 95. Agile Manifesto “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: – Individuals and interactions OVER processes and tools. – Working software OVER comprehensive documentation. – Customer collaboration OVER contract negotiation.Friday 15 June 2012 49
  96. 96. Agile Manifesto “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: – Individuals and interactions OVER processes and tools. – Working software OVER comprehensive documentation. – Customer collaboration OVER contract negotiation. – Responding to change OVER following a plan.Friday 15 June 2012 49
  97. 97. Agile Manifesto “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: – Individuals and interactions OVER processes and tools. – Working software OVER comprehensive documentation. – Customer collaboration OVER contract negotiation. – Responding to change OVER following a plan. That is, while there is value in the items on the right, we value the items on the left more.” © 2001 Agile Alliance. http://www.agilemanifesto.orgFriday 15 June 2012 49
  98. 98. Agile Manifesto PrinciplesFriday 15 June 2012 50
  99. 99. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.Friday 15 June 2012 51
  100. 100. Welcome changing requirements, even late in development. Agile processes harness change for the customers competitive advantage.Friday 15 June 2012 52
  101. 101. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.Friday 15 June 2012 53
  102. 102. Business people and developers must work together daily throughout the project.Friday 15 June 2012 54
  103. 103. Build projects around motivated individuals. Givethem the environment and support they need, and trust them to get the job done.Friday 15 June 2012 55
  104. 104. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.Friday 15 June 2012 56
  105. 105. Working software is the primary measure of progress.Friday 15 June 2012 57
  106. 106. Agile processes promote sustainable development. Thesponsors, developers, and users should be able to maintain a constant pace indefinitely.Friday 15 June 2012 58
  107. 107. Simplicity the art of maximizing the amount of work not done is essential.Friday 15 June 2012 59
  108. 108. Continuous attention to technical excellence and good design enhances agility.Friday 15 June 2012 60
  109. 109. The best architectures, requirements, and designs emerge from self-organizing teams.Friday 15 June 2012 61
  110. 110. At regular intervals, the teamreflects on how to become moreeffective, then tunes and adjusts its behavior accordingly.Friday 15 June 2012 62
  111. 111. It  turns  out...Friday 15 June 2012 63
  112. 112. It  turns  out...  Zivs  law  -­‐  specifica=ons  will  never  be  fully  understood.Friday 15 June 2012 63
  113. 113. It  turns  out...  Zivs  law  -­‐  specifica=ons  will  never  be  fully  understood.  Humphreys  law  -­‐  the  user  will  never  know  what  they  want  un=l   aOer  the  system  is  in  produc=on  (maybe  not  even  then)Friday 15 June 2012 63
  114. 114. It  turns  out...  Zivs  law  -­‐  specifica=ons  will  never  be  fully  understood.  Humphreys  law  -­‐  the  user  will  never  know  what  they  want  un=l   aOer  the  system  is  in  produc=on  (maybe  not  even  then)  Wegners  lemma  -­‐  an  interac=ve  system  can  never  be  fully   specified  nor  can  it  ever  be  fully  tested.  Friday 15 June 2012 63
  115. 115. It  turns  out...  Zivs  law  -­‐  specifica=ons  will  never  be  fully  understood.  Humphreys  law  -­‐  the  user  will  never  know  what  they  want  un=l   aOer  the  system  is  in  produc=on  (maybe  not  even  then)  Wegners  lemma  -­‐  an  interac=ve  system  can  never  be  fully   specified  nor  can  it  ever  be  fully  tested.    Langdons  lemma  -­‐  soOware  evolves  more  rapidly  as  it   approaches  chao=c  regions  (taking  care  not  to  spill  over  into   chaos)Friday 15 June 2012 63
  116. 116. It  turns  out...  Zivs  law  -­‐  specifica=ons  will  never  be  fully  understood.  Humphreys  law  -­‐  the  user  will  never  know  what  they  want  un=l   aOer  the  system  is  in  produc=on  (maybe  not  even  then)  Wegners  lemma  -­‐  an  interac=ve  system  can  never  be  fully   specified  nor  can  it  ever  be  fully  tested.    Langdons  lemma  -­‐  soOware  evolves  more  rapidly  as  it   approaches  chao=c  regions  (taking  care  not  to  spill  over  into   chaos) Any association of predictive or defined processes with Agile is an exercise in futility. - JeffFriday 15 June 2012 63
  117. 117. Treat  agile  principles  as  “proper)es”  you   use  to  assess  process  health Performing  a  simple  process  health  checkup:  hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2  Friday 15 June 2012 64
  118. 118. Treat  agile  principles  as  “proper)es”  you   use  to  assess  process  health 1. Frequent  delivery Performing  a  simple  process  health  checkup:  hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2  Friday 15 June 2012 64
  119. 119. Treat  agile  principles  as  “proper)es”  you   use  to  assess  process  health 1. Frequent  delivery 2. Reflec6ve  improvement Performing  a  simple  process  health  checkup:  hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2  Friday 15 June 2012 64
  120. 120. Treat  agile  principles  as  “proper)es”  you   use  to  assess  process  health 1. Frequent  delivery 2. Reflec6ve  improvement 3. Close  communica6on Performing  a  simple  process  health  checkup:  hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2  Friday 15 June 2012 64
  121. 121. Treat  agile  principles  as  “proper)es”  you   use  to  assess  process  health 1. Frequent  delivery 2. Reflec6ve  improvement 3. Close  communica6on 4. Focus Performing  a  simple  process  health  checkup:  hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2  Friday 15 June 2012 64
  122. 122. Treat  agile  principles  as  “proper)es”  you   use  to  assess  process  health 1. Frequent  delivery 2. Reflec6ve  improvement 3. Close  communica6on 4. Focus 5. Personal  safety Performing  a  simple  process  health  checkup:  hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2  Friday 15 June 2012 64
  123. 123. Treat  agile  principles  as  “proper)es”  you   use  to  assess  process  health 1. Frequent  delivery 2. Reflec6ve  improvement 3. Close  communica6on 4. Focus 5. Personal  safety 6. Easy  access  to  experts Performing  a  simple  process  health  checkup:  hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2  Friday 15 June 2012 64
  124. 124. Treat  agile  principles  as  “proper)es”  you   use  to  assess  process  health 1. Frequent  delivery 7. Strong  technical  environment 2. Reflec6ve  improvement 3. Close  communica6on 4. Focus 5. Personal  safety 6. Easy  access  to  experts Performing  a  simple  process  health  checkup:  hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2  Friday 15 June 2012 64
  125. 125. Treat  agile  principles  as  “proper)es”  you   use  to  assess  process  health 1. Frequent  delivery 7. Strong  technical  environment 2. Reflec6ve  improvement 8. Sunny  day  visibility 3. Close  communica6on 4. Focus 5. Personal  safety 6. Easy  access  to  experts Performing  a  simple  process  health  checkup:  hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2  Friday 15 June 2012 64
  126. 126. Treat  agile  principles  as  “proper)es”  you   use  to  assess  process  health 1. Frequent  delivery 7. Strong  technical  environment 2. Reflec6ve  improvement 8. Sunny  day  visibility 3. Close  communica6on 9. Regular  cadence 4. Focus 5. Personal  safety 6. Easy  access  to  experts Performing  a  simple  process  health  checkup:  hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2  Friday 15 June 2012 64
  127. 127. Treat  agile  principles  as  “proper)es”  you   use  to  assess  process  health 1. Frequent  delivery 7. Strong  technical  environment 2. Reflec6ve  improvement 8. Sunny  day  visibility 3. Close  communica6on 9. Regular  cadence 4. Focus 10.High  energy 5. Personal  safety 6. Easy  access  to  experts Performing  a  simple  process  health  checkup:  hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2  Friday 15 June 2012 64
  128. 128. Treat  agile  principles  as  “proper)es”  you   use  to  assess  process  health 1. Frequent  delivery 7. Strong  technical  environment 2. Reflec6ve  improvement 8. Sunny  day  visibility 3. Close  communica6on 9. Regular  cadence 4. Focus 10.High  energy 5. Personal  safety 11.Empowered  teams 6. Easy  access  to  experts Performing  a  simple  process  health  checkup:  hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2  Friday 15 June 2012 64
  129. 129. Treat  agile  principles  as  “proper)es”  you   use  to  assess  process  health 1. Frequent  delivery 7. Strong  technical  environment 2. Reflec6ve  improvement 8. Sunny  day  visibility 3. Close  communica6on 9. Regular  cadence 4. Focus 10.High  energy 5. Personal  safety 11.Empowered  teams 6. Easy  access  to  experts 12.Disrup6ve  change Performing  a  simple  process  health  checkup:  hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2  Friday 15 June 2012 64
  130. 130. Our  Team  RoomsFriday 15 June 2012 65
  131. 131. some  more  plans…Friday 15 June 2012 66
  132. 132. src: ThoughtWorks IndiaFriday 15 June 2012 67
  133. 133. Work or Fun or Both? src: ThoughtWorks IndiaFriday 15 June 2012 68
  134. 134. Work or Fun or Both? src: ThoughtWorks IndiaFriday 15 June 2012 68
  135. 135. Agile EvolutionFriday 15 June 2012 69
  136. 136. Agile  Umbrella Agile XP Scrum DSDM FDD Adaptive Pragmatic Crystal LeanFriday 15 June 2012 70
  137. 137. Agile  become... Agile XP ScrumFriday 15 June 2012 71
  138. 138. Friday 15 June 2012 72
  139. 139. Balance discovery with delivery Discovery:understanding theright product to build Delivery: building product right Src: Jeff PattonFriday 15 June 2012 73
  140. 140. Then  came  along... Agile Ecosystem Agile Agile-UX XP Lean Scrum Product DiscoveryFriday 15 June 2012 74
  141. 141. High Level View of an Agile Process Src: Jeff PattonFriday 15 June 2012 75
  142. 142. Then  came  along... Agile Ecosystem Agile Agile-UX XP Lean Scrum Kanban Product DiscoveryFriday 15 June 2012 76
  143. 143. Where did Agile Originate? Src: Jeff PattonFriday 15 June 2012 77
  144. 144. Where  Agile  appears  to  work  best? Unknown Solution Known Known Unknown Problem Src: Eric RiesFriday 15 June 2012 78
  145. 145. Where  Agile  appears  to  work  best? Unknown le Solution gi Known A Known Unknown Problem Src: Eric RiesFriday 15 June 2012 78
  146. 146. Where  Agile  appears  to  work  best? Unknown ?? le Solution gi Known A Known Unknown Problem Src: Eric RiesFriday 15 June 2012 78
  147. 147. Kaizen vs. KaikakuFriday 15 June 2012 79
  148. 148. Currently... Agile Ecosystem Lean Agile Startup Agile-UX XP Lean Scrum Kanban Dev-OPs Product DiscoveryFriday 15 June 2012 80
  149. 149. The  Future Lean Startup CD Pivot Costumer Development CD Agile Continuous Delivery XP Agile-UX Scrum Lean Kanban Dev-OPs MVP Product DiscoveryFriday 15 June 2012 81
  150. 150. Friday 15 June 2012 82
  151. 151. Organizations have habits, and they will stick to their habits even at the risk of their own survival. Brad Anderson, CEO, Best BuyFriday 15 June 2012 83
  152. 152. Organizational structures have a short life... Nobody likes to reorganize, and you always run the risk that you distract your employees and lose focus on customers. But if you dont do it, you lose your competitive edge. Nancy McKinstry, CEO, Wolters KluwerFriday 15 June 2012 84
  153. 153. Friday 15 June 2012 85
  154. 154. Friday 15 June 2012 86
  155. 155. InnovationFriday 15 June 2012 87
  156. 156. Metrics MessFriday 15 June 2012 88
  157. 157. Friday 15 June 2012 89
  158. 158. Knowledge Islands Metrics MessFriday 15 June 2012 90
  159. 159. Friday 15 June 2012 91
  160. 160. Be  careful  not  to… Naresh Jain naresh@agilefaqs.com twitter: @nashjain http://nareshjain.comFriday 15 June 2012 92
  161. 161. Be  careful  not  to… Naresh Jain Ques7ons? naresh@agilefaqs.com twitter: @nashjain http://nareshjain.comFriday 15 June 2012 92
  162. 162. Be  careful  not  to… Naresh Jain Ques7ons? naresh@agilefaqs.com twitter: @nashjain http://nareshjain.comFriday 15 June 2012 92
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×