Why Agile is Failing in Large Enterprises
•Download as PPTX, PDF•
0 likes•508 views
Agile works. We get it. You don’t have to sell people on the underlying principles anymore. Even so, many large-scale agile transformations are struggling. Some have failed. Others can’t figure out why things aren't working after multiple attempts. It’s easy to blame the people, the process, and the culture. And it’s especially easy to blame management. However, the underlying problem is that most large organizations weren’t built to be agile. You need a way to safely and pragmatically refactor your company into an organization that can adopt agile and sustain the transformation. Mike Cottmeyer introduces a framework for understanding the type of company in which you work, its delivery constraints, and likely challenges you’ll face in your agile transformation. Mike shares a strategy for establishing an end-state vision and operational model to guide your transformation. Finally, he defines an approach for incrementally introducing change, measuring outcomes, and sustaining those changes.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (6)
Similar to Why Agile is Failing in Large Enterprises
Similar to Why Agile is Failing in Large Enterprises (20)
More from LeadingAgile
More from LeadingAgile (17)
Recently uploaded
Recently uploaded (20)
Why Agile is Failing in Large Enterprises
- 1. WHY AGILE IS FAILING IN LARGE ENTERPRISES
- 2. WHY AGILE IS FAILING IN LARGE ENTERPRISES …and what you can do about it
- 5. 1943 1950- 1960s 1985 1990 1995 1996 1997 1998 2000 2001 USAF & NASA X-15 hypersonic jet Iterative Incremental Delivery Hirotaka Takeuchi & Ikujiro Nonaka The New New Product Development Game 1990 - Sutherland & Schwaber Scrum Framework DSDN Consortium Dynamic System Development Method 1996 - Beck, Cunningham, Jeffries Extreme Programming Jeff de Luca Feature Driven Development Alistair Cockburn Crystal Methodologies Robert Charette Lean Development THE AGILE MANIFEST O Taiichi Ohno Toyota Production System Kanban Hardware Software
- 6. Individuals & interactions Processes & toolsover Working software Comprehensive documentation over Customer collaboration Contract negotiationover Responding to change Following a planover That is, while there is value in the items on the right, we value the items on the left more. We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Source: www.agilemanifesto.org MANIFESTO VALUES
- 7. Satisfy the Customer Welcome Change Deliver Frequently Collaborate Daily Support & Trust Motivated Teams Promote Face-to-Face Conversations Deliver Working Software Promote Sustainable Pace Promote Technical Excellence Maximize Through Simplicity Have Self-Organized Teams Reflect & Adjust Regularly Source: www.agilemanifesto.org MANIFESTO PRINCIPLES
- 8. BELIEFS ABOUT AGILE & TRANSFORMATION
- 10. Culture PracticesStructure • Focused on changing hearts and minds • Focused on being agile rather than doing agile • Focused on values and principles CULTURE DRIVEN
- 11. Culture PracticesStructure • Focused on changing hearts and minds • Focused on being agile rather than doing agile • Focused on values and principles • Belief that delivery systems will emerge based on new thinking CULTURE DRIVEN
- 12. Practices StructureCulture • Focused on the things that you do • Focused on roles, ceremonies, and artifacts • Can be management driven or technically driven PRACTICES DRIVEN
- 13. Practices StructureCulture • Focused on the things that you do • Focused on roles, ceremonies, and artifacts • Can be management driven or technically driven • Belief that agile is a process or way to work PRACTICES DRIVEN
- 14. Structure CulturePractices • Focused on forming teams and governing the flow of value • Focused on aligning the organization first STRUCTURE DRIVEN
- 15. Structure CulturePractices • Focused on forming teams and governing the flow of value • Focused on aligning the organization first • Belief that culture and practices only emerge within a rational structural and planning framework STRUCTURE DRIVEN
- 16. Culture PracticesStructure ... all three are essential, but where you start is also essential… WHERE TO START?
- 18. Theory of Transformation Agile transformation begins by defining a rational system of delivery for the enterprise
- 19. Theory of Transformation True agility comes by breaking dependencies between teams across the organization
- 20. Theory of Transformation Healthy culture and solid practices emerge within a rational delivery framework
- 21. WHY AGILE WORKS
- 22. Team
- 23. Team User Story User Story User Story User Story User Story User Story User Story
- 24. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story
- 25. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Clarity
- 26. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Clarity Accountability
- 27. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Clarity Accountability Measureable Progress
- 28. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Clarity Accountability Measureable Progress Few if any dependencies
- 29. WHY AGILE WORKS AT SCALE
- 30. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Clarity Accountability Measureable Progress
- 31. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Governance Accountability Measureable Progress
- 32. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Structure Measureable Progress Governance
- 33. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Structure Metrics & Tools Governance
- 34. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Structure Metrics & Tools Governance Teams have autonomy across the organization
- 35. WHY AGILE FAILS
- 36. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story
- 37. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Lack of Clarity
- 38. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Lack of Clarity Lack of Accountability
- 39. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Lack of Clarity Lack of Accountability Lack of Measureable Progress
- 40. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Lack of Clarity Lack of Accountability Lack of Measureable Progress Often caused by too many external dependencies
- 41. WHY AGILE FAILS AT SCALE
- 42. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Lack of Clarity Lack of Accountability Lack of Measureable Progress
- 43. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Lack of Governance Lack of Measureable Progress Lack of Accountability
- 44. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Lack of Structure Lack of Measureable Progress Lack of Governance
- 45. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Lack of Metrics & Tools Lack of Governance Lack of Structure
- 46. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Lack of Metrics & Tools Lack of Governance Lack of Structure Too much coordination between teams
- 48. Team
- 51. Matrixed Organizations Limited Access to Subject Matter Expertise Non-instantly Available Resources Team
- 52. Matrixed Organizations Limited Access to Subject Matter Expertise Non-instantly Available Resources Shared Requirements Between Teams Team
- 53. Matrixed Organizations Limited Access to Subject Matter Expertise Non-instantly Available Resources Too Much Work In Process Shared Requirements Between Teams Team
- 54. Matrixed Organizations Limited Access to Subject Matter Expertise Non-instantly Available Resources Too Much Work In Process Shared Requirements Between Teams Large Products with Diverse TechnologyTeam
- 55. Matrixed Organizations Limited Access to Subject Matter Expertise Non-instantly Available Resources Too Much Work In Process Shared Requirements Between Teams Technical Debt & Defects Large Products with Diverse TechnologyTeam
- 56. Matrixed Organizations Limited Access to Subject Matter Expertise Non-instantly Available Resources Too Much Work In Process Low Cohesion & Tight Coupling Shared Requirements Between Teams Technical Debt & Defects Large Products with Diverse TechnologyTeam
- 57. Corollary One: Solving for the issues that get in the way of effectively practicing agile is what should guide your agile transformation initiative
- 67. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Traditional Agile Lean Startup
- 68. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Traditional Agile Lean Startup Project
- 69. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Traditional Agile Lean Startup Project Pilot
- 70. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Traditional Agile Lean Startup Project Pilot
- 71. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Traditional Agile Lean Startup Adopt Pilot
- 72. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Traditional Agile Lean Startup LOB
- 73. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Traditional Agile Lean Startup LOB Low Trust
- 74. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Traditional Agile Lean Startup LOB Low Trust LOB Become Predictable
- 75. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Traditional Agile Lean Startup LOB Low Trust LOB Become Predictable
- 76. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Lean/Agile Agile Lean Startup LOB Low Trust LOB Become Predictable
- 77. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Lean/Agile Agile Lean Startup LOB Low Trust LOB Become Predictable LOB Reduce Batch Size
- 78. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Lean/Agile Agile Lean Startup LOB LOB LOB LOB Low Trust Become Predictable Reduce Batch Size Fully Decouple
- 79. Corollary Two: Agile can mean different things to different companies and not all agile approaches will work well for every organization
- 81. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Lean/Agile Agile Lean Startup Org Slice Low Trust Become Predictable Reduce Batch Size Fully Decouple
- 82. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Lean/Agile Agile Lean Startup Org Slice Low Trust Become Predictable Reduce Batch Size Fully Decouple Phase One
- 83. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Lean/Agile Agile Lean Startup Org Slice Low Trust Become Predictable Reduce Batch Size Fully Decouple Phase One Phase Two
- 84. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Lean/Agile Agile Lean Startup Org Slice Low Trust Become Predictable Reduce Batch Size Fully Decouple Phase One Phase Three Phase Two
- 85. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Lean/Agile Agile Lean Startup Org Slice Low Trust Become Predictable Reduce Batch Size Fully Decouple Phase One Phase Three Phase Four Phase Two
- 86. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Lean/Agile Agile Lean Startup Org Slice Low Trust Become Predictable Reduce Batch Size Fully Decouple Phase One Phase Three Phase Four Phase Two Phase Five
- 87. Corollary Three: Organizational change can be mapped out in such a way that outcomes are measureable and predictable and economically justified
- 89. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Structure Governance Metrics & Tools
- 90. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Structure Governance Metrics & Tools
- 91. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Governance Metrics & Tools Structure
- 92. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Governance Metrics & Tools Structure
- 93. STRUCTURE
- 94. Services Teams – These teams support common services across product lines. These teams support the needs of the product teams. Team
- 95. Product Teams – These teams integrate services and write customer facing features. This is the proto- typical Scrum team. Services Teams – These teams support common services across product lines. These teams support the needs of the product teams. Team Team
- 96. Programs Teams – These teams define requirements, set technical direction, and provide context and coordination. Product Teams – These teams integrate services and write customer facing features. This is the proto- typical Scrum team. Services Teams – These teams support common services across product lines. These teams support the needs of the product teams. Team Team Team
- 97. Portfolio Teams – These teams govern the portfolio and make sure that work is moving through the system. Programs Teams – These teams define requirements, set technical direction, and provide context and coordination. Product Teams – These teams integrate services and write customer facing features. This is the proto- typical Scrum team. Services Teams – These teams support common services across product lines. These teams support the needs of the product teams. Team Team Team Team
- 98. Team Team Team Team TeamTeamTeam Product & Services Teams
- 99. Team Team Team Team Team Team Team TeamTeamTeam Product & Services Teams Program Teams
- 100. Team Team Team Team Team Team Team Team TeamTeamTeam Product & Services Teams Program Teams Portfolio Teams
- 101. GOVERNANCE
- 102. Team Team Team Team Team Team Team Team TeamTeamTeam Product & Services Teams Program Teams Portfolio Teams
- 103. Product & Services Teams Scrum Team Team Team Team Team Team Team Team TeamTeamTeam Program Teams Portfolio Teams
- 104. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Team Team Team Team Team Team Team Team TeamTeamTeam
- 105. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam
- 106. METRICS
- 107. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam
- 108. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team • Backlog Size • Velocity • Burndown • Escaped Defects • Commit % Ratio • Acceptance % Ratio • Scope Change
- 109. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team • Cycle Time • Features Blocked • Rework/Defects • Backlog Size • Velocity • Burndown • Escaped Defects • Commit % Rate • Acceptance % Ratio • Scope Change
- 110. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban • Backlog Size • Velocity • Burndown • Escaped Defects • Commit % Ratio • Acceptance % Ratio • Scope Change • Cycle Time • Features Blocked • Rework/Defects • Takt Time/Cycle Time • Time/Cost/Scope/Value • RIO/Capitalization
- 111. Corollary Four: Organizational constructs, governance models, metrics and controls can be established without violating the principles of agile
- 113. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam Agile Pilot Increment One
- 114. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam Agile Pilot Increment One Agile Rollout Increment Two
- 115. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam Agile Pilot Increment One Agile Rollout Three - N
- 117. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam Agile Pilot Iteration One
- 118. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam Agile Pilot Iteration Two
- 119. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam Agile Pilot Iteration Three
- 120. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Agile Pilot Iteration Four Team Team Team Team Team Team Team Team TeamTeamTeam
- 121. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Agile Pilot Iteration Five Team Team Team Team Team TeamTeamTeam Team Team Team
- 123. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Agile Pilot Iteration One Team Team Team Team Team TeamTeamTeam Team Team Team
- 124. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Agile Pilot Team Team Team Team Team TeamTeamTeam Team Team Team Iteration Two
- 125. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Agile Pilot Iteration Three Agile Rollout Iteration One Team Team Team Team Team TeamTeamTeam Team Team Team
- 126. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Agile Pilot Iteration Four Agile Rollout Iteration Two Team Team Team Team Team TeamTeamTeam Team Team Team
- 127. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Agile Pilot Iteration Five Agile Rollout Iteration Three Team Team Team Team Team TeamTeamTeam Team Team Team
- 128. Corollary Five: Organizations can adopt agile safely and pragmatically by iteratively and incrementally introducing structure, governance, and metrics and maturing practices and culture over time
- 129. SUMMARY
- 130. Theory of Transformation Agile transformation begins by defining a rational system of delivery for the enterprise
- 131. Theory of Transformation True agility comes by breaking dependencies between teams across the organization
- 132. Theory of Transformation Healthy culture and solid practices emerge within a rational delivery framework
- 133. Corollary One: Solving for the issues that get in the way of effectively practicing agile is what should guide your agile transformation initiative
- 134. Corollary Two: Agile can mean different things to different companies and not all agile approaches will work well for every organization
- 135. Corollary Three: Organizational change can be mapped out in such a way that outcomes are measureable and predictable and economically justified
- 136. Corollary Four: Organizational constructs, governance models, metrics and controls can be established without violating the principles of agile
- 137. Corollary Five: Organizations can adopt agile safely and pragmatically by iteratively and incrementally introducing structure, governance, and metrics and maturing practices and culture over time
- 138. Summary By focusing on the fundamentals of agile delivery, while systematically and methodically breaking dependencies, we can achieve true enterprise agility
- 139. WHY AGILE IS FAILING IN LARGE ENTERPRISES …and what you can do about it