Why Agile Is Failing in Large Enterprises, And What You Can Do About It
•Als PPTX, PDF herunterladen•
35 gefällt mir•15,040 views
Large companies often struggle to adopt agile practices in a meaningful way. This presentation will help you understand why you are struggling to adopt agile, and more importantly, what you can do about it.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Why Agile Is Failing in Large Enterprises, And What You Can Do About It
Ähnlich wie Why Agile Is Failing in Large Enterprises, And What You Can Do About It (20)
Mehr von Mike Cottmeyer
Mehr von Mike Cottmeyer (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Why Agile Is Failing in Large Enterprises, And What You Can Do About It
- 1. Why Is Agile Failing in Large Enterprises… … and what you can do about it
- 3. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story
- 4. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Clarity
- 5. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Clarity Accountability
- 6. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Clarity Accountability Measureable Progress
- 8. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story
- 9. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Lack of Clarity
- 10. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Lack of Clarity Little Accountability
- 11. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Lack of Clarity Little Accountability Can’t Measure Progress
- 12. What Gets In The Way?
- 13. Team 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
- 14. How Do You Begin an Agile Transformation?
- 15. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Remember the Goal…
- 16. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Clarity Remember the Goal…
- 17. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Clarity Accountability Remember the Goal…
- 18. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Clarity Accountability Measureable Progress Remember the Goal…
- 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 Transformation Begins By Defining a Rational System of Delivery for the Enterprise
- 28. Working Hypothesis: True Agility is About Breaking Dependencies Across The Entire Organization
- 29. Working Hypothesis: Healthy Culture and Effective Practices Only Emerge Within a Rational Delivery Framework
- 30. How To Map Your Enterprise Agile Transformation
- 39. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Traditional Agile Lean Startup
- 40. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Traditional Agile Lean Startup Project
- 41. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Traditional Agile Lean Startup Agile Pilot Project
- 42. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Traditional Agile Lean Startup Agile Pilot Agile Rollout
- 43. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Traditional Agile Lean Startup Agile Pilot Agile Rollout
- 44. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Traditional Agile Lean Startup LOB
- 45. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Traditional Agile Lean Startup LOB Low Trust
- 46. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Traditional Agile Lean Startup Agile Pilot LOB Low Trust
- 47. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Traditional Agile Lean Startup Agile Pilot LOB Low Trust Become Predictable
- 48. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Traditional Agile Lean Startup Agile Pilot LOB Low Trust Become Predictable
- 49. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Lean/Agile Agile Lean Startup LOB LOB Low Trust Become Predictable
- 50. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Lean/Agile Agile Lean Startup LOB LOB LOB Low Trust Become Predictable
- 51. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Lean/Agile Agile Lean Startup LOB LOB LOB Low Trust Become Predictable Reduce Batch Size
- 52. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Lean/Agile Agile Lean Startup LOB LOB LOB LOB Low Trust Become Predictable Reduce Batch Size
- 53. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Lean/Agile Agile Lean Startup LOB LOB LOB LOB Low Trust Become Predictable Reduce Batch Size Fully Decouple Teams
- 54. Iterative and Incremental Organizational Improvement
- 55. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Lean/Agile Agile Lean Startup Low Trust Become Predictable Reduce Batch Size Fully Decouple Teams Start
- 56. Predictability Adaptability Emergent Convergent AEPE PC AC Ad-Hoc Lean/Agile Agile Lean Startup 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 Lean Startup 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 Lean Startup 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 Lean Startup 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 Lean Startup 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.
- 66. Team Team TeamTeam Team Team Team Team Product & Services Teams
- 67. Team Team Team Team Team Team Team Team Team Team Team Product & Services Teams Program Teams
- 68. Team Team Team Team Team Team Team Team Team Team Team Team Product & Services Teams Program Teams Portfolio Teams
- 69. Team Team Team Team Team Team Team Team Team Team Team Team Product & Services Teams Program Teams Portfolio Teams Scrum
- 70. Team Team Team Team Team Team Team Team Team Team Team Team Product & Services Teams Program Teams Portfolio Teams Scrum Kanban
- 71. Team Team Team Team Team Team Team Team Team Team Team Team Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban
- 72. Team Team Team Team Team Team Team Team Team Team Team 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 Team Team 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 Team Team 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 Team Team 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 Team Team Team Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Phase 5 Independent Goal Driven Teams Adaptive Planning & Governance AE
- 77. By focusing on the fundamentals and systematically breaking dependencies, we can achieve true enterprise agility at scale
Hinweis der Redaktion
- 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
- 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.