Why Agile Is Failing in Large Enterprises
•Download as PPTX, PDF•
16 likes•3,581 views
The document discusses why agile approaches often fail in large enterprises and provides recommendations for successful agile transformation. It notes that agile fails at scale due to lack of clarity, accountability, measurable progress, structure, governance and tools. It recommends starting the transformation by defining a rational delivery system for the enterprise to improve predictability. True agility comes from breaking dependencies between teams. An incremental approach using pilots, phases and iterations is suggested. Structure, governance, and metrics are also important to support the transformation.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (18)
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 (18)
Recently uploaded
Recently uploaded (20)
Why Agile Is Failing in Large Enterprises
- 1. WHY AGILE IS FAILING IN LARGE ENTERPRISES
- 4. Team
- 5. Team User Story User Story User Story User Story User Story User Story User Story
- 6. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story
- 7. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Clarity
- 8. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Clarity Accountability
- 9. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Clarity Accountability Measureable Progress
- 10. WHY AGILE WORKS AT SCALE
- 11. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Clarity Accountability Measureable Progress
- 12. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Structure Accountability Measureable Progress
- 13. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Governance Measureable Progress Structure
- 14. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Governance Metrics & Tools Structure
- 15. WHY AGILE FAILS
- 16. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Lack of Clarity
- 17. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Lack of Clarity Lack of Accountability
- 18. 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
- 19. WHY AGILE FAILS AT SCALE
- 20. 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
- 21. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Lack of Clarity Lack of Structure Lack of Measureable Progress
- 22. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Lack of Governance Lack of Structure Lack of Measureable Progress
- 23. 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
- 25. Team
- 28. Matrixed Organizations Limited Access to Subject Matter Expertise Non-instantly Available Resources Team
- 29. Matrixed Organizations Limited Access to Subject Matter Expertise Non-instantly Available Resources Shared Requirements Between Teams Team
- 30. Matrixed Organizations Limited Access to Subject Matter Expertise Non-instantly Available Resources Too Much Work In Process Shared Requirements Between Teams Team
- 31. 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 Technology Team
- 32. 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 Technology Team
- 33. 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 Technology Team
- 34. WHERE DO YOU GET STARTED?
- 35. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story
- 36. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Remember the goal…
- 37. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Clarity
- 38. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Clarity Accountability
- 39. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Clarity Accountability Measureable Progress
- 40. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story … at all levels of scale
- 42. Culture PracticesStructure ... all three are essential, but where do you start?
- 43. Culture PracticesStructure • Focused on changing hearts and minds • Focused on being agile rather than doing agile • Focused on values and principles
- 44. 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
- 45. Practices StructureCulture • Focused on the things that you do • Focused on roles, ceremonies, and artifacts • Can be management driven or technically driven
- 46. 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
- 47. Structure CulturePractices • Focused on forming teams and governing the flow of value • Focused on aligning the organization first
- 48. 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
- 49. Working Hypothesis: Agile transformation begins by defining a rational system of delivery for the enterprise
- 50. Working Hypothesis: True agility comes by breaking dependencies between teams across the organization
- 51. Working Hypothesis: Healthy culture and solid practices emerge within a rational delivery framework
- 61. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Traditional Agile Lean Startup
- 62. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Traditional Agile Lean Startup LOB
- 63. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Traditional Agile Lean Startup LOB Pilot
- 64. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Traditional Agile Lean Startup LOB Pilot
- 65. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Traditional Agile Lean Startup Adopt Pilot
- 66. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Traditional Agile Lean Startup LOB
- 67. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Traditional Agile Lean Startup LOB Low Trust
- 68. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Traditional Agile Lean Startup LOB Low Trust LOB Become Predictable
- 69. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Traditional Agile Lean Startup LOB Low Trust LOB Become Predictable
- 70. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Lean/Agile Agile Lean Startup LOB Low Trust LOB Become Predictable
- 71. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Lean/Agile Agile Lean Startup LOB Low Trust LOB Become Predictable LOB Reduce Batch Size
- 72. 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
- 74. 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
- 75. 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
- 76. 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
- 77. 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
- 78. 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
- 79. 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
- 80. STRUCTURE
- 81. Services Teams – These teams support common services across product lines. These teams support the needs of the product teams. Team
- 82. 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
- 83. 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
- 84. 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
- 85. Team Team Team Team TeamTeamTeam Product & Services Teams
- 86. Team Team Team Team Team Team Team TeamTeamTeam Product & Services Teams Program Teams
- 87. Team Team Team Team Team Team Team Team TeamTeamTeam Product & Services Teams Program Teams Portfolio Teams
- 88. GOVERNANCE
- 89. Team Team Team Team Team Team Team Team TeamTeamTeam Product & Services Teams Program Teams Portfolio Teams
- 90. Product & Services Teams Scrum Team Team Team Team Team Team Team Team TeamTeamTeam Program Teams Portfolio Teams
- 91. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Team Team Team Team Team Team Team Team TeamTeamTeam
- 92. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam
- 93. METRICS
- 94. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam
- 99. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam Agile Pilot Increment One
- 100. 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
- 101. 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
- 103. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam Agile Pilot Iteration One
- 104. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam Agile Pilot Iteration Two
- 105. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam Agile Pilot Iteration Three
- 106. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam Agile Pilot Iteration Four
- 107. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam Agile Pilot Iteration Five
- 109. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam Agile Pilot Iteration One
- 110. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam Agile Pilot Iteration Two
- 111. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam Agile Pilot Iteration Three Agile Rollout Iteration One
- 112. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam Agile Pilot Iteration Four Agile Rollout Iteration Two
- 113. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam Agile Pilot Iteration Five Agile Rollout Iteration Three
- 114. SUMMARY
- 115. Summary By focusing on the fundamentals of agile delivery, while systematically and methodically breaking dependencies, we can achieve true enterprise agility
- 116. WHY AGILE IS FAILING IN LARGE ENTERPRISES
Editor's Notes
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- Matrixed management Non-instantly available resources Project funding models Limited access to subject matter expertise Shared requirements between teams Technical debt Defects Tightly coupled architectures
- Matrixed management Non-instantly available resources Project funding models Limited access to subject matter expertise Shared requirements between teams Technical debt Defects Tightly coupled architectures
- Matrixed management Non-instantly available resources Project funding models Limited access to subject matter expertise Shared requirements between teams Technical debt Defects Tightly coupled architectures
- Matrixed management Non-instantly available resources Project funding models Limited access to subject matter expertise Shared requirements between teams Technical debt Defects Tightly coupled architectures
- Matrixed management Non-instantly available resources Project funding models Limited access to subject matter expertise Shared requirements between teams Technical debt Defects Tightly coupled architectures
- Matrixed management Non-instantly available resources Project funding models Limited access to subject matter expertise Shared requirements between teams Technical debt Defects Tightly coupled architectures
- Matrixed management Non-instantly available resources Project funding models Limited access to subject matter expertise Shared requirements between teams Technical debt Defects Tightly coupled architectures
- Matrixed management Non-instantly available resources Project funding models Limited access to subject matter expertise Shared requirements between teams Technical debt Defects Tightly coupled architectures
- Matrixed management Non-instantly available resources Project funding models Limited access to subject matter expertise Shared requirements between teams Technical debt Defects Tightly coupled architectures
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.