THE THREE THINGS You Need to Know to Transform Any Sized Organization into an Agile Enterprise
MIKE COTTMEYER mike@leadingagile.com 404-312-1471 www.leadingagile.com twitter.com/mcottmeyer facebook.com/leadingagile linkedin.com/in/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
Emergence Predictability Adaptability Convergence
Emergence Predictability Adaptability Convergence
Emergence Predictability PC AE Adaptability Convergence
Emergence Predictability PE AE PC AC Adaptability Convergence
Quadrant One Predictive Emergent Ad-Hoc Emergence Predictability PE AE PC AC Adaptability Convergence
Quadrant Two Predictive Convergent Ad-Hoc Emergence Predictability PE AE PC AC Adaptability Traditional Convergence
Quadrant Three Adaptive Convergent Ad-Hoc Emergence Predictability PE AE PC AC Adaptability Traditional Agile Convergence
Quadrant Four Adaptive Emergent Ad-Hoc Emergence Lean Startup Predictability PE AE PC AC Adaptability Traditional Agile Convergence
THE THREE THINGS
s
s
Working Tested Software s Working Tested Software
Working Tested Software s 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?
Working Tested Software s 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?
Working Tested Software s 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?
Working Tested Software s 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?
Working Tested Software Clarity Accountability Measureable Progress People have clarity around what to build People understand how it maps to the big picture can be held accountable for delivery No indeterminate work piling up at the end of the project 90% done, 90% left to do Why Are They Important?
Working Tested Software Clarity Accountability Measureable Progress People have clarity around what to build People understand how it maps to the big picture can be held accountable for delivery No indeterminate work piling up at the end of the project 90% done, 90% left to do Why Are They Important?
Working Tested Software Clarity Accountability Measureable Progress People have clarity around what to build People understand how it maps to the big picture can be held accountable for delivery No indeterminate work piling up at the end of the project 90% done, 90% left to do Why Are They Important?
Working Tested Software Clarity Accountability Measureable Progress People have clarity around what to build People understand how it maps to the big picture can be held accountable for delivery No indeterminate work piling up at the end of the project 90% done, 90% left to do Why Are They Important?
Working Tested Software 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 Why Are They Important?
Working Tested Software 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 Why Are They Important?
Working Tested Software 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 Why Are They Important?
Working Tested Software 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 Why Are They Important?
Working Tested Software 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? What Do They Look Like at Scale?
Working Tested Software 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? What Do They Look Like at Scale?
Working Tested Software 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? What Do They Look Like at Scale?
Working Tested Software 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? What Do They Look Like at Scale?
Team
Matrixed Organizations Team
Matrixed Organizations Non-instantly Available Resources Team
Matrixed Organizations Non-instantly Available Resources Limited Access to Subject Matter Expertise Team
Matrixed Organizations Non-instantly Available Resources Limited Access to Subject Matter Expertise Team Shared Requirements Between
Matrixed Organizations Non-instantly Available Resources Too Much Work In Process Limited Access to Subject Matter Expertise Team Shared Requirements Between
Matrixed Organizations Non-instantly Available Resources Too Much Work In Process Limited Access to Subject Matter Expertise Team Large Products with Diverse Technology Shared Requirements Between
Matrixed Organizations Non-instantly Available Resources Too Much Work In Process Limited Access to Subject Matter Expertise Team Large Products with Diverse Technology Shared Requirements Between Technical Debt & Defects
Matrixed Organizations Non-instantly Available Resources Too Much Work In Process Limited Access to Subject Matter Expertise Team Large Products with Diverse Technology Shared Requirements Between Technical Debt & Defects Low Cohesion & Tight Coupling
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
Emergence Ad-Hoc Lean Startup Predictability PE AE PC AC Adaptability Traditional Agile Convergence
Emergence Ad-Hoc Low Trust Lean Startup Predictability PE AE PC AC Adaptability Traditional Agile Convergence
Ad-Hoc Low Trust Emergence Lean Startup Predictability PE AE PC AC Adaptability Become Predictable Traditional Agile Convergence
Ad-Hoc Low Trust Emergence Lean Startup Predictability PE AE PC AC Adaptability Become Predictable Traditional Agile Convergence
Ad-Hoc Low Trust Emergence Lean Startup Predictability PE AE PC AC Adaptability Become Predictable Lean/Agile Agile Convergence
Ad-Hoc Low Trust Emergence Lean Startup Predictability PE AE PC AC Adaptability Become Predictable Lean/Agile Reduce Batch Size Agile Convergence
Ad-Hoc Low Trust Emergence Lean Startup Fully Decouple Predictability PE AE PC AC Adaptability Become Predictable Lean/Agile Reduce Batch Size Agile Convergence
Ad-Hoc Low Trust Emergence Lean Startup Fully Decouple Predictability PE AE PC AC Adaptability Become Predictable Lean/Agile Reduce Batch Size Agile Convergence
Phase One Stabilize the System Ad-Hoc Low Trust Emergence Lean Startup Fully Decouple Predictability PE AE PC AC Adaptability Phase One Become Predictable Lean/Agile Reduce Batch Size Agile Convergence
Phase Two Reduce Batch Size Ad-Hoc Low Trust Emergence Lean Startup Fully Decouple Predictability PE AE PC AC Adaptability Phase One Phase Two Become Predictable Lean/Agile Reduce Batch Size Agile Convergence
Phase Three Break Dependencies Ad-Hoc Low Trust Emergence Lean Startup Fully Decouple Predictability PE AE PC AC Phase Three Adaptability Phase One Phase Two Become Predictable Lean/Agile Reduce Batch Size Agile Convergence
Phase Four Increase Local Autonomy Ad-Hoc Low Trust Emergence Lean Startup Fully Decouple Predictability PE AE PC AC Phase Three Phase Four Adaptability Phase One Phase Two Become Predictable Lean/Agile Reduce Batch Size Agile Convergence
Phase Five Invest to Learn Ad-Hoc Low Trust Emergence Lean Startup Fully Decouple Phase Five Predictability PE AE PC AC Phase Three Phase Four Adaptability Phase One Phase Two Become Predictable Lean/Agile Reduce Batch Size Agile Convergence
MIKE COTTMEYER mike@leadingagile.com 404-312-1471 www.leadingagile.com twitter.com/mcottmeyer facebook.com/leadingagile linkedin.com/in/cottmeyer
THE THREE THINGS Appendix A
STRUCTURE
Product & Services Team Team Team Team Team Team Team
Program Team Team Team Product & Services Team Team Team Team Team Team Team
Portfolio Team Program Team Team Team Product & Services Team Team Team Team Team Team Team
GOVERNANCE
Portfolio Team Program Team Team Team Product & Services Team Team Team Team Team Team Team
Portfolio Team Program Team Team Team Product & Services Team Team Team Scrum Team Team Team Team
Portfolio Team Program Team Team Team Kanban Product & Services Team Team Team Scrum Team Team Team Team
Portfolio Team Kanban Program Team Team Team Kanban Product & Services Team Team Team Scrum Team Team Team Team
METRICS
Portfolio Team Kanban Program Team Team Team Kanban Product & Services Team Team Team Scrum Team Team Team Team
Portfolio Team Kanban Program Team Team Team Kanban Product & Services Size Velocity Burndown Escaped Defects Commit % Ratio Acceptance % Ratio Scope Change Scrum
Portfolio Team Kanban Program Product & Services Cycle Time Features Blocked Rework/Defects Size Velocity Burndown Escaped Defects Commit % Rate Acceptance % Ratio Scope Change Kanban Scrum
Portfolio Program Product & Services Takt Time/Cycle Time Time/Cost/Scope/Value RIO/Capitalization Cycle Time Features Blocked Rework/Defects Size Velocity Burndown Escaped Defects Commit % Ratio Acceptance % Ratio Scope Change Kanban Kanban Scrum
BELIEFS
Working Tested Software Defining Work Known and knowable requirements How to deal with unknowns Estimating Allocating People Fungible resources Individual utilization Productivity metrics Measuring Progress Activity over outcome How Do I Need to Change?
Working Tested Software Defining Work Known and knowable requirements How to deal with unknowns Estimating Allocating People Fungible resources Individual utilization Productivity metrics Measuring Progress Activity over outcome How Do I Need to Change?
Working Tested Software Defining Work Known and knowable requirements How to deal with unknowns Estimating Allocating People Fungible resources Individual utilization Productivity metrics Measuring Progress Activity over outcome How Do I Need to Change?
Working Tested Software Defining Work Known and knowable requirements How to deal with unknowns Estimating Allocating People Fungible resources Individual utilization Productivity metrics Measuring Progress Activity over outcome How Do I Need to Change?
IMPEDIMENTS
Working Tested Software Business Dependencies Requirements management Process flow Value streams Bottlenecks Too much in process work Organizational Dependencies Matrixed Organizations Non instantly available resources Lack of SME Technical Dependencies Technical Debt Defects Tight Coupling Low Cohesion What Gets in the Way?
Working Tested Software Business Dependencies Requirements management Process flow Value streams Bottlenecks Too much in process work Organizational Dependencies Matrixed Organizations Non instantly available resources Lack of SME Technical Dependencies Technical Debt Defects Tight Coupling Low Cohesion What Gets in the Way?
Working Tested Software Business Dependencies Requirements management Process flow Value streams Bottlenecks Too much in process work Organizational Dependencies Matrixed Organizations Non instantly available resources Lack of SME Technical Dependencies Technical Debt Defects Tight Coupling Low Cohesion What Gets in the Way?
Working Tested Software Business Dependencies Requirements management Process flow Value streams Bottlenecks Too much in process work Organizational Dependencies Matrixed Organizations Non instantly available resources Lack of SME Technical Dependencies Technical Debt Defects Tight Coupling Low Cohesion What Gets in the Way?