-
THE THREE THINGS You Need
to Know to Transform Any Sized Organization into an Agile Enterprise
-
mike@leadingagile.com 404-312-1471 www.leadingagile.com twitter.com/mcottmeyer facebook.com/leadingagile
linkedin.com/in/cottmeyer MIKE COTTMEYER
-
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
-
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
-
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
-
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
-
ONE SIZE DOES NOT FIT
ALL
-
Predictability
Adaptability
-
Predictability
Adaptability
Emergence
Convergence
-
Predictability
Adaptability
Emergence
Convergence
-
Predictability Adaptability Emergence Convergence AE
PC
-
Predictability Adaptability Emergence Convergence AEPE
PC AC
-
Predictability Adaptability Emergence Convergence AEPE
PC AC Ad-Hoc Quadrant One • Predictive Emergent
-
Predictability Adaptability Emergence Convergence AEPE
PC AC Ad-Hoc Traditional Quadrant Two • Predictive Convergent
-
Predictability Adaptability Emergence Convergence AEPE
PC AC Ad-Hoc Traditional Agile Quadrant Three • Adaptive Convergent
-
Predictability Adaptability Emergence Convergence AEPE
PC AC Ad-Hoc Traditional Agile Lean Startup Quadrant Four • Adaptive Emergent
-
THE THREE THINGS
-
Backlog
Backlog
Backlog
Backlog
Backlogs
-
Teams Backlog Backlog Backlog Backlog
Backlogs Teams
-
Teams Backlog Backlog Backlog Backlog
Working Tested Software Backlogs Teams Working Tested Software
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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?
-
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?
-
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?
-
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?
-
STRUCTURE
-
Team Team Team Team TeamTeamTeam
Product & Services Teams
-
Team Team Team Team Team
Team Team TeamTeamTeam Product & Services Teams Program Teams
-
Team Team Team Team Team
Team Team Team TeamTeamTeam Product & Services Teams Program Teams Portfolio Teams
-
GOVERNANCE
-
Team Team Team Team Team
Team Team Team TeamTeamTeam Product & Services Teams Program Teams Portfolio Teams
-
Product & Services Teams Scrum
Team Team Team Team Team Team Team Team TeamTeamTeam Program Teams Portfolio Teams
-
Product & Services Teams Program
Teams Portfolio Teams Scrum Kanban Team Team Team Team Team Team Team Team TeamTeamTeam
-
Product & Services Teams Program
Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam
-
METRICS
-
Product & Services Teams Program
Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
Team
-
Matrixed
Organizations
Team
-
Matrixed Organizations Non-instantly Available Resources
Team
-
Matrixed Organizations Limited Access to
Subject Matter Expertise Non-instantly Available Resources Team
-
Matrixed Organizations Limited Access to
Subject Matter Expertise Non-instantly Available Resources Shared Requirements Between Teams Team
-
Matrixed Organizations Limited Access to
Subject Matter Expertise Non-instantly Available Resources Too Much Work In Process Shared Requirements Between Teams Team
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
A THEORY OF
TRANSFORMATION
-
A Theory of Transformation Agile
is about forming teams, building backlogs, and regularly producing increments of working tested software
-
A Theory of Transformation Agile
at scale is about defining structure, establishing governance, and creating a metrics and tooling strategy that supports agility
-
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
-
TRANSFORMATION
IS A JOURNEY
-
Predictability Adaptability Emergence Convergence AEPE
PC AC Ad-Hoc Traditional Agile Lean Startup
-
Predictability Adaptability Emergence Convergence AEPE
PC AC Ad-Hoc Traditional Agile Lean Startup Low Trust
-
Predictability Adaptability Emergence Convergence AEPE
PC AC Ad-Hoc Traditional Agile Lean Startup Low Trust Become Predictable
-
Predictability Adaptability Emergence Convergence AEPE
PC AC Ad-Hoc Traditional Agile Lean Startup Low Trust Become Predictable
-
Predictability Adaptability Emergence Convergence AEPE
PC AC Ad-Hoc Lean/Agile Agile Lean Startup Low Trust Become Predictable
-
Predictability Adaptability Emergence Convergence AEPE
PC AC Ad-Hoc Lean/Agile Agile Lean Startup Low Trust Become Predictable Reduce Batch Size
-
Predictability Adaptability Emergence Convergence AEPE
PC AC Ad-Hoc Lean/Agile Agile Lean Startup Low Trust Become Predictable Reduce Batch Size Fully Decouple
-
Predictability Adaptability Emergence Convergence AEPE
PC AC Ad-Hoc Lean/Agile Agile Lean Startup Teams Low Trust Become Predictable Reduce Batch Size Fully Decouple
-
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
-
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
-
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
-
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
-
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
-
mike@leadingagile.com 404-312-1471 www.leadingagile.com twitter.com/mcottmeyer facebook.com/leadingagile
linkedin.com/in/cottmeyer MIKE COTTMEYER
-
THE THREE THINGS You Need
to Know to Transform Any Sized Organization into an Agile Enterprise
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.