The Three Things You Need to Know to Transform Any Size Organization Into an Agile Enterprise
•Télécharger en tant que PPTX, PDF•
348 j'aime•54,596 vues
The three most important things you need to keep in mind when leading agile agile transformation... and some other useful stuff.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à The Three Things You Need to Know to Transform Any Size Organization Into an Agile Enterprise
Similaire à The Three Things You Need to Know to Transform Any Size Organization Into an Agile Enterprise (20)
Plus de Mike Cottmeyer
Plus de Mike Cottmeyer (20)
Dernier
Dernier (20)
The Three Things You Need to Know to Transform Any Size Organization Into an Agile Enterprise
- 1. THE THREE THINGS You Need to Know to Transform Any Sized Organization into an Agile Enterprise
- 3. Brief Agenda • Discuss why adopting agile isn’t ‘one size fits all’ • Explore the fundamentals of agile transformation • How to craft an agile transformation roadmap
- 4. Brief Agenda • Discuss why adopting agile isn’t ‘one size fits all’ • Explore the fundamentals of agile transformation • How to craft an agile transformation roadmap
- 5. Brief Agenda • Discuss why adopting agile isn’t ‘one size fits all’ • Explore the fundamentals of agile transformation • How to craft an agile transformation roadmap
- 6. Brief Agenda • Discuss why adopting agile isn’t ‘one size fits all’ • Explore the fundamentals of agile transformation • How to craft an agile transformation roadmap
- 7. ONE SIZE DOES NOT FIT ALL
- 13. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Quadrant One • Predictive Emergent
- 14. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Traditional Quadrant Two • Predictive Convergent
- 15. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Traditional Agile Quadrant Three • Adaptive Convergent
- 16. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Traditional Agile Lean Startup Quadrant Four • Adaptive Emergent
- 17. THE THREE THINGS
- 21. Teams Backlog Backlog Backlog Backlog Working Tested Software Backlogs Teams Working Tested Software
- 22. Teams Backlog Backlog Backlog Backlog Working Tested Software • INVEST • CCC • Small enough for the team to develop in a day or so • Everything and everyone necessary to deliver • Meets acceptance criteria • No known defects • No technical debt What Do I Mean? Backlogs Teams Working Tested Software
- 23. Teams Backlog Backlog Backlog Backlog Working Tested Software • INVEST • CCC • Small enough for the team to develop in a day or so • Everything and everyone necessary to deliver • Meets acceptance criteria • No known defects • No technical debt What Do I Mean? Backlogs Teams Working Tested Software
- 24. Teams Backlog Backlog Backlog Backlog Working Tested Software • INVEST • CCC • Small enough for the team to develop in a day or so • Everything and everyone necessary to deliver • Meets acceptance criteria • No known defects • No technical debt What Do I Mean? Backlogs Teams Working Tested Software
- 25. Teams Backlog Backlog Backlog Backlog Working Tested Software • INVEST • CCC • Small enough for the team to develop in a day or so • Everything and everyone necessary to deliver • Meets acceptance criteria • No known defects • No technical debt What Do I Mean? Backlogs Teams Working Tested Software
- 26. Teams Backlog Backlog Backlog Backlog Working Tested Software Why Are They Important? Clarity Accountability Measureable Progress • People have clarity around what to build • People understand how it maps to the big picture • Teams can be held accountable for delivery • No indeterminate work piling up at the end of the project • 90% done, 90% left to do
- 27. Teams Backlog Backlog Backlog Backlog Working Tested Software Why Are They Important? Clarity Accountability Measureable Progress • People have clarity around what to build • People understand how it maps to the big picture • Teams can be held accountable for delivery • No indeterminate work piling up at the end of the project • 90% done, 90% left to do
- 28. Teams Backlog Backlog Backlog Backlog Working Tested Software Why Are They Important? Clarity Accountability Measureable Progress • People have clarity around what to build • People understand how it maps to the big picture • Teams can be held accountable for delivery • No indeterminate work piling up at the end of the project • 90% done, 90% left to do
- 29. Teams Backlog Backlog Backlog Backlog Working Tested Software Why Are They Important? Clarity Accountability Measureable Progress • People have clarity around what to build • People understand how it maps to the big picture • Teams can be held accountable for delivery • No indeterminate work piling up at the end of the project • 90% done, 90% left to do
- 30. Teams Backlog Backlog Backlog Backlog Working Tested Software Why Are They Important? Purpose Autonomy Mastery • Understanding the backlog gives meaning to work • Local decision making gives people a sense of power and control over their work • People can demonstrate that they are good at what they do
- 31. Teams Backlog Backlog Backlog Backlog Working Tested Software Why Are They Important? Purpose Autonomy Mastery • Understanding the backlog gives meaning to work • Local decision making gives people a sense of power and control over their work • People can demonstrate that they are good at what they do
- 32. Teams Backlog Backlog Backlog Backlog Working Tested Software Why Are They Important? Purpose Autonomy Mastery • Understanding the backlog gives meaning to work • Local decision making gives people a sense of power and control over their work • People can demonstrate that they are good at what they do
- 33. Teams Backlog Backlog Backlog Backlog Working Tested Software Why Are They Important? Purpose Autonomy Mastery • Understanding the backlog gives meaning to work • Local decision making gives people a sense of power and control over their work • People can demonstrate that they are good at what they do
- 34. Teams Backlog Backlog Backlog Backlog Working Tested Software What Do They Look Like at Scale? Governance Structure Metrics & Tools • Governance is the way we make economic tradeoffs in the face of constraints • They way we form teams and foster collaboration at all levels of the organization • What do we measure, how do we baseline performance and show improvement?
- 35. Teams Backlog Backlog Backlog Backlog Working Tested Software What Do They Look Like at Scale? Governance Structure Metrics & Tools • Governance is the way we make economic tradeoffs in the face of constraints • They way we form teams and foster collaboration at all levels of the organization • What do we measure, how do we baseline performance and show improvement?
- 36. Teams Backlog Backlog Backlog Backlog Working Tested Software What Do They Look Like at Scale? Governance Structure Metrics & Tools • Governance is the way we make economic tradeoffs in the face of constraints • They way we form teams and foster collaboration at all levels of the organization • What do we measure, how do we baseline performance and show improvement?
- 37. Teams Backlog Backlog Backlog Backlog Working Tested Software What Do They Look Like at Scale? Governance Structure Metrics & Tools • Governance is the way we make economic tradeoffs in the face of constraints • They way we form teams and foster collaboration at all levels of the organization • What do we measure, how do we baseline performance and show improvement?
- 38. STRUCTURE
- 39. Team Team Team Team TeamTeamTeam Product & Services Teams
- 40. Team Team Team Team Team Team Team TeamTeamTeam Product & Services Teams Program Teams
- 41. Team Team Team Team Team Team Team Team TeamTeamTeam Product & Services Teams Program Teams Portfolio Teams
- 42. GOVERNANCE
- 43. Team Team Team Team Team Team Team Team TeamTeamTeam Product & Services Teams Program Teams Portfolio Teams
- 44. Product & Services Teams Scrum Team Team Team Team Team Team Team Team TeamTeamTeam Program Teams Portfolio Teams
- 45. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Team Team Team Team Team Team Team Team TeamTeamTeam
- 46. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam
- 47. METRICS
- 48. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam
- 49. 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
- 50. 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
- 51. 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
- 52. Teams Backlog Backlog Backlog Backlog Working Tested Software What Gets in the Way? Business Dependencies Organizational Dependencies Technical Dependencies • Requirements management • Process flow • Value streams • Bottlenecks • Too much in process work • Matrixed Organizations • Non instantly available resources • Lack of SME • Technical Debt • Defects • Loose Coupling • Low Cohesion
- 53. Teams Backlog Backlog Backlog Backlog Working Tested Software What Gets in the Way? Business Dependencies Organizational Dependencies Technical Dependencies • Requirements management • Process flow • Value streams • Bottlenecks • Too much in process work • Matrixed Organizations • Non instantly available resources • Lack of SME • Technical Debt • Defects • Loose Coupling • Low Cohesion
- 54. Teams Backlog Backlog Backlog Backlog Working Tested Software What Gets in the Way? Business Dependencies Organizational Dependencies Technical Dependencies • Requirements management • Process flow • Value streams • Bottlenecks • Too much in process work • Matrixed Organizations • Non instantly available resources • Lack of SME • Technical Debt • Defects • Loose Coupling • Low Cohesion
- 55. Teams Backlog Backlog Backlog Backlog Working Tested Software What Gets in the Way? Business Dependencies Organizational Dependencies Technical Dependencies • Requirements management • Process flow • Value streams • Bottlenecks • Too much in process work • Matrixed Organizations • Non instantly available resources • Lack of SME • Technical Debt • Defects • Loose Coupling • Low Cohesion
- 56. Team
- 59. Matrixed Organizations Limited Access to Subject Matter Expertise Non-instantly Available Resources Team
- 60. Matrixed Organizations Limited Access to Subject Matter Expertise Non-instantly Available Resources Shared Requirements Between Teams Team
- 61. Matrixed Organizations Limited Access to Subject Matter Expertise Non-instantly Available Resources Too Much Work In Process Shared Requirements Between Teams Team
- 62. 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
- 63. 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
- 64. 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
- 65. Teams Backlog Backlog Backlog Backlog Working Tested Software How Do I Need to Change? • Known and knowable requirements • How to deal with unknowns • Estimating • Fungible resources • Individual utilization • Productivity metrics • Activity over outcome Defining Work Allocating People Measuring Progress
- 66. Teams Backlog Backlog Backlog Backlog Working Tested Software How Do I Need to Change? • Known and knowable requirements • How to deal with unknowns • Estimating • Fungible resources • Individual utilization • Productivity metrics • Activity over outcome Defining Work Allocating People Measuring Progress
- 67. Teams Backlog Backlog Backlog Backlog Working Tested Software How Do I Need to Change? • Known and knowable requirements • How to deal with unknowns • Estimating • Fungible resources • Individual utilization • Productivity metrics • Activity over outcome Defining Work Allocating People Measuring Progress
- 68. Teams Backlog Backlog Backlog Backlog Working Tested Software How Do I Need to Change? • Known and knowable requirements • How to deal with unknowns • Estimating • Fungible resources • Individual utilization • Productivity metrics • Activity over outcome Defining Work Allocating People Measuring Progress
- 70. A Theory of Transformation Agile is about forming teams, building backlogs, and regularly producing increments of working tested software
- 71. A Theory of Transformation Agile at scale is about defining structure, establishing governance, and creating a metrics and tooling strategy that supports agility
- 72. A Theory of Transformation Anything that gets in the way of forming teams, building backlogs, and producing working tested software is an impediment to transformation
- 74. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Traditional Agile Lean Startup
- 75. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Traditional Agile Lean Startup Low Trust
- 76. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Traditional Agile Lean Startup Low Trust Become Predictable
- 77. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Traditional Agile Lean Startup Low Trust Become Predictable
- 78. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Lean/Agile Agile Lean Startup Low Trust Become Predictable
- 79. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Lean/Agile Agile Lean Startup Low Trust Become Predictable Reduce Batch Size
- 80. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Lean/Agile Agile Lean Startup Low Trust Become Predictable Reduce Batch Size Fully Decouple
- 81. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Lean/Agile Agile Lean Startup Teams Low Trust Become Predictable Reduce Batch Size Fully Decouple
- 82. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Lean/Agile Agile Lean Startup Teams Low Trust Become Predictable Reduce Batch Size Fully Decouple Phase One Phase One • Stabilize the System
- 83. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Lean/Agile Agile Lean Startup Teams Low Trust Become Predictable Reduce Batch Size Fully Decouple Phase One Phase Two Phase Two • Reduce Batch Size
- 84. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Lean/Agile Agile Lean Startup Teams Low Trust Become Predictable Reduce Batch Size Fully Decouple Phase One Phase Three Phase Two Phase Three • Break Dependencies
- 85. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Lean/Agile Agile Lean Startup Teams Low Trust Become Predictable Reduce Batch Size Fully Decouple Phase One Phase Three Phase Four Phase Two Phase Four • Increase Local Autonomy
- 86. Predictability Adaptability Emergence Convergence AEPE PC AC Ad-Hoc Lean/Agile Agile Lean Startup Teams Low Trust Become Predictable Reduce Batch Size Fully Decouple Phase One Phase Three Phase Four Phase Two Phase Five Phase Five • Invest to Learn
- 88. THE THREE THINGS You Need to Know to Transform Any Sized Organization into an Agile Enterprise
Notes de l'éditeur
- 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.
- 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.