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

Transcription

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

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

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

8 Predictability Adaptability

9 Emergence Predictability Adaptability Convergence

10 Emergence Predictability Adaptability Convergence

11 Emergence Predictability PC AE Adaptability Convergence

12 Emergence Predictability PE AE PC AC Adaptability Convergence

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

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

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

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

17 THE THREE THINGS

18

19 s

20 s

21 Working Tested Software s Working Tested Software

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

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

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

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

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

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

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

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

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

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

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

39 Matrixed Organizations Team

40 Matrixed Organizations Non-instantly Available Resources Team

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

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

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

44 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

45 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

46 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

47 A THEORY OF TRANSFORMATION

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

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

50 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

51 TRANSFORMATION IS A JOURNEY

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

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

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

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

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

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

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

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

60 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

61 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

62 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

63 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

64 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

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

66 THE THREE THINGS Appendix A

67 STRUCTURE

68 Product & Services Team Team Team Team Team Team Team

69 Program Team Team Team Product & Services Team Team Team Team Team Team Team

70 Portfolio Team Program Team Team Team Product & Services Team Team Team Team Team Team Team

71 GOVERNANCE

72 Portfolio Team Program Team Team Team Product & Services Team Team Team Team Team Team Team

73 Portfolio Team Program Team Team Team Product & Services Team Team Team Scrum Team Team Team Team

74 Portfolio Team Program Team Team Team Kanban Product & Services Team Team Team Scrum Team Team Team Team

75 Portfolio Team Kanban Program Team Team Team Kanban Product & Services Team Team Team Scrum Team Team Team Team

76 METRICS

77 Portfolio Team Kanban Program Team Team Team Kanban Product & Services Team Team Team Scrum Team Team Team Team

78 Portfolio Team Kanban Program Team Team Team Kanban Product & Services Size Velocity Burndown Escaped Defects Commit % Ratio Acceptance % Ratio Scope Change Scrum

79 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

80 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

81 BELIEFS

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

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

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

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

86 IMPEDIMENTS

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

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

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

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