Downloaded 530 times
Uploaded byMike Cottmeyer
Why Agile Is Failing in Large Enterprises, And What You Can Do About It
The document discusses why agile methodologies often fail in large enterprises, attributing failures to lack of clarity, accountability, and measurable progress. It suggests a framework for successful agile transformation, emphasizing the importance of culture, practices, and structure, and highlights strategies for overcoming common obstacles. The text outlines a phased approach for implementing agile practices to achieve sustainable enterprise agility at scale.
More Related Content
Similar to Why Agile Is Failing in Large Enterprises, And What You Can Do About It
Why Agile Is Failing in Large Enterprises, And What You Can Do About It
- 1. Why Is AgileFailing in Large Enterprises… … and what you can do about it
- 2.
- 3. Team Database Report Screen User Story User Story UserStory User Story User Story User Story User Story
- 4. Team Database Report Screen User Story User Story UserStory User Story User Story User Story User Story Clarity
- 5. Team Database Report Screen User Story User Story UserStory User Story User Story User Story User Story Clarity Accountability
- 6. Team Database Report Screen User Story User Story UserStory User Story User Story User Story User Story Clarity Accountability Measureable Progress
- 7.
- 8. Team Database Report Screen User Story User Story UserStory User Story User Story User Story User Story
- 9. Team Database Report Screen User Story User Story UserStory User Story User Story User Story User Story Lack of Clarity
- 10. Team Database Report Screen User Story User Story UserStory User Story User Story User Story User Story Lack of Clarity Little Accountability
- 11. Team Database Report Screen User Story User Story UserStory User Story User Story User Story User Story Lack of Clarity Little Accountability Can’t Measure Progress
- 12. What Gets InThe Way?
- 13. Team Matrixed Organizations Limited Access to SubjectMatter 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
- 14. How Do YouBegin an Agile Transformation?
- 15. Team Database Report Screen User Story User Story UserStory User Story User Story User Story User Story Remember the Goal…
- 16. Team Database Report Screen User Story User Story UserStory User Story User Story User Story User Story Clarity Remember the Goal…
- 17. Team Database Report Screen User Story User Story UserStory User Story User Story User Story User Story Clarity Accountability Remember the Goal…
- 18. Team Database Report Screen User Story User Story UserStory User Story User Story User Story User Story Clarity Accountability Measureable Progress Remember the Goal…
- 19.
- 20. Culture PracticesStructure Three Popular Perspectives… ...all three are essential, but where do you start?
- 21. Culture PracticesStructure Culture First Transformation •Focused on changing hearts and minds • Focused on being agile rather than doing agile • Focused on values and principles
- 22. Culture PracticesStructure Culture First Transformation •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
- 23. Practices StructureCulture Practices First Transformation •Focused on the things that you do • Focused on roles, ceremonies, and artifacts • Can be management driven or technically driven
- 24. Practices StructureCulture Practices First Transformation •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
- 25. Structure CulturePractices Structure First Transformation •Focused on forming teams and governing the flow of value • Focused on aligning the organization first
- 26. Structure CulturePractices Structure First Transformation •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
- 27. Working Hypothesis: Agile TransformationBegins By Defining a Rational System of Delivery for the Enterprise
- 28. Working Hypothesis: True Agilityis About Breaking Dependencies Across The Entire Organization
- 29. Working Hypothesis: Healthy Cultureand Effective Practices Only Emerge Within a Rational Delivery Framework
- 30. How To MapYour Enterprise Agile Transformation
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Traditional Agile LeanStartup Agile Pilot Project
- 42. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Traditional Agile LeanStartup Agile Pilot Agile Rollout
- 43. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Traditional Agile LeanStartup Agile Pilot Agile Rollout
- 44.
- 45.
- 46. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Traditional Agile LeanStartup Agile Pilot LOB Low Trust
- 47. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Traditional Agile LeanStartup Agile Pilot LOB Low Trust Become Predictable
- 48. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Traditional Agile LeanStartup Agile Pilot LOB Low Trust Become Predictable
- 49. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Lean/Agile Agile LeanStartup LOB LOB Low Trust Become Predictable
- 50. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Lean/Agile Agile LeanStartup LOB LOB LOB Low Trust Become Predictable
- 51. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Lean/Agile Agile LeanStartup LOB LOB LOB Low Trust Become Predictable Reduce Batch Size
- 52. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Lean/Agile Agile LeanStartup LOB LOB LOB LOB Low Trust Become Predictable Reduce Batch Size
- 53. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Lean/Agile Agile LeanStartup LOB LOB LOB LOB Low Trust Become Predictable Reduce Batch Size Fully Decouple Teams
- 54. Iterative and Incremental OrganizationalImprovement
- 55. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Lean/Agile Agile LeanStartup Low Trust Become Predictable Reduce Batch Size Fully Decouple Teams Start
- 56. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Lean/Agile Agile LeanStartup Low Trust Become Predictable Reduce Batch Size Fully Decouple Teams Start P1
- 57. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Lean/Agile Agile LeanStartup Low Trust Become Predictable Reduce Batch Size Fully Decouple Teams Start P1 P2
- 58. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Lean/Agile Agile LeanStartup Low Trust Become Predictable Reduce Batch Size Fully Decouple Teams Start P1 P2 P3
- 59. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Lean/Agile Agile LeanStartup Low Trust Become Predictable Reduce Batch Size Fully Decouple Teams Start P1 P2 P3 P4
- 60. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Lean/Agile Agile LeanStartup Low Trust Become Predictable Reduce Batch Size Fully Decouple Teams Start P1 P2 P3 P4 P5
- 61. Team Services Teams –These teams support common services across product lines. These teams support the needs of the product teams.
- 62. Team Team 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.
- 63. Team Team Team 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.
- 64. Team Team Team Team 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.
- 65.
- 66. Team Team TeamTeam Team TeamTeam Team Product & Services Teams
- 67. Team Team Team Team Team Team Team TeamTeam Team Team Product & Services Teams Program Teams
- 68. Team Team Team Team Team Team Team Team Team TeamTeam Team Product & Services Teams Program Teams Portfolio Teams
- 69. Team Team Team Team Team Team Team Team Team TeamTeam Team Product & Services Teams Program Teams Portfolio Teams Scrum
- 70. Team Team Team Team Team Team Team Team Team TeamTeam Team Product & Services Teams Program Teams Portfolio Teams Scrum Kanban
- 71. Team Team Team Team Team Team Team Team Team TeamTeam Team Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban
- 72. Team Team Team Team Team Team Team Team Team TeamTeam Team Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Phase I Form Teams, Basic Agile Practices PC
- 73. Team Team Team Team Team Team Team Team Team TeamTeam Team Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Phase 2 Mature Practices & Culture Regular Delivery Cadence PC
- 74. Team Team Team Team Team Team Team Team Team TeamTeam Team Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Phase 2 Decouple Services and Products Testing, CI and DevOps AC
- 75. Team Team Team Team Team Team Team Team Team TeamTeam Team Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Phase 4 Smaller Batches Enterprise Wide Goal Oriented Funding Framework AC
- 76. Team Team Team Team Team Team Team Team Team TeamTeam Team Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Phase 5 Independent Goal Driven Teams Adaptive Planning & Governance AE
- 77. By focusing onthe fundamentals and systematically breaking dependencies, we can achieve true enterprise agility at scale
Editor's Notes
- #4 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.
- #5 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.
- #6 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.
- #7 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.
- #9 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.
- #10 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 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.
- #12 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.
- #14 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
- #16 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.
- #17 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.
- #18 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.
- #19 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.