THE THREE THINGS. You Must Know to Transform Any Sized Organization into an Agile Enterprise

Transcription

1 THE THREE THINGS You Must Know to Transform Any Sized Organization into an Agile Enterprise

2 MIKE COTTMEYER twitter.com/mcottmeyer facebook.com/leadingagile linkedin.com/in/cottmeyer

3

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 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

8 ONE SIZE DOES NOT FIT ALL

9 Predictability Adaptability

10 Emergence Predictability Adaptability Convergence

11 Emergence Predictability Adaptability Convergence

12 Emergence Predictability PC AE Adaptability Convergence

13 Emergence Predictability PE AE PC AC Adaptability Convergence

14 Quadrant One Predictive Emergent Ad-Hoc Emergence Predictability PE AE PC AC Adaptability Convergence

15 Quadrant Two Predictive Convergent Ad-Hoc Emergence Predictability PE AE PC AC Adaptability Traditional Convergence

16 Quadrant Three Adaptive Convergent Ad-Hoc Emergence Predictability PE AE PC AC Adaptability Traditional Agile Convergence

17 Quadrant Four Adaptive Emergent Ad-Hoc Emergence Lean Startup Predictability PE AE PC AC Adaptability Traditional Agile Convergence

18 THE THREE THINGS

19

20 Backlogs

21 Backlogs Teams Teams

22 Teams Working Tested Software Backlogs Teams Working Tested Software

23 Teams Working Tested Software Backlogs Teams 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?

24 Teams Working Tested Software Backlogs Teams 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?

25 Teams Working Tested Software Backlogs Teams 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?

26 Teams Working Tested Software Backlogs Teams 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?

27 Teams Working Tested Software 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 Why Are They Important?

28 Teams Working Tested Software 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 Why Are They Important?

29 Teams Working Tested Software 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 Why Are They Important?

30 Teams Working Tested Software 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 Why Are They Important?

31 Teams 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?

32 Teams 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?

33 Teams 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?

34 Teams 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?

35 Teams 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?

36 Teams 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?

37 Teams 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?

38 Teams 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?

39 Teams 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?

40 Teams 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?

41 Teams 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?

42 Teams 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?

43 Team

44 Matrixed Organizations Team

45 Matrixed Organizations Non-instantly Available Resources Team

46 Matrixed Organizations Non-instantly Available Resources Limited Access to Subject Matter Expertise Team

47 Matrixed Organizations Non-instantly Available Resources Limited Access to Subject Matter Expertise Team Shared Requirements Between Teams

48 Matrixed Organizations Non-instantly Available Resources Too Much Work In Process Limited Access to Subject Matter Expertise Team Shared Requirements Between Teams

49 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 Teams

50 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 Teams Technical Debt & Defects

51 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 Teams Technical Debt & Defects Low Cohesion & Tight Coupling

52 Teams 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?

53 Teams 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?

54 Teams 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?

55 Teams 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?

56 A THEORY OF TRANSFORMATION

57 A Theory of Transformation Agile is about forming teams, building backlogs, and regularly producing increments of working tested software

58 A Theory of Transformation Agile at scale is about defining structure, establishing governance, and creating a metrics and tooling strategy that supports agility

59 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

60 TRANSFORMATION IS A JOURNEY

61 Emergence Ad-Hoc Lean Startup Predictability PE AE PC AC Adaptability Traditional Agile Convergence

62 Emergence Ad-Hoc Low Trust Lean Startup Predictability PE AE PC AC Adaptability Traditional Agile Convergence

63 Ad-Hoc Low Trust Emergence Lean Startup Predictability PE AE PC AC Adaptability Become Predictable Traditional Agile Convergence

64 Ad-Hoc Low Trust Emergence Lean Startup Predictability PE AE PC AC Adaptability Become Predictable Traditional Agile Convergence

65 Ad-Hoc Low Trust Emergence Lean Startup Predictability PE AE PC AC Adaptability Become Predictable Lean/Agile Agile Convergence

66 Ad-Hoc Low Trust Emergence Lean Startup Predictability PE AE PC AC Adaptability Become Predictable Lean/Agile Reduce Batch Size Agile Convergence

67 Ad-Hoc Low Trust Emergence Lean Startup Fully Decouple Predictability PE AE PC AC Adaptability Become Predictable Lean/Agile Reduce Batch Size Agile Convergence

68 Ad-Hoc Low Trust Emergence Lean Startup Fully Decouple Teams Predictability PE AE PC AC Adaptability Become Predictable Lean/Agile Reduce Batch Size Agile Convergence

69 Phase One Stabilize the System Ad-Hoc Low Trust Emergence Lean Startup Fully Decouple Teams Predictability PE AE PC AC Adaptability Phase One Become Predictable Lean/Agile Reduce Batch Size Agile Convergence

70 Phase Two Reduce Batch Size Ad-Hoc Low Trust Emergence Lean Startup Fully Decouple Teams Predictability PE AE PC AC Adaptability Phase One Phase Two Become Predictable Lean/Agile Reduce Batch Size Agile Convergence

71 Phase Three Break Dependencies Ad-Hoc Low Trust Emergence Lean Startup Fully Decouple Teams Predictability PE AE PC AC Phase Three Adaptability Phase One Phase Two Become Predictable Lean/Agile Reduce Batch Size Agile Convergence

72 Phase Four Increase Local Autonomy Ad-Hoc Low Trust Emergence Lean Startup Fully Decouple Teams Predictability PE AE PC AC Phase Three Phase Four Adaptability Phase One Phase Two Become Predictable Lean/Agile Reduce Batch Size Agile Convergence

73 Phase Five Invest to Learn Teams 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

74 MIKE COTTMEYER twitter.com/mcottmeyer facebook.com/leadingagile linkedin.com/in/cottmeyer

75 THE THREE THINGS You Need to Know to Transform Any Sized Organization into an Agile Enterprise