Agile Transformation | Mike Cottmeyer
•Als PPTX, PDF herunterladen•
12 gefällt mir•6,371 views
Mike Cottmeyer's latest deck. Updated for his 2019 Agile Transformation Talk
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Agile Transformation | Mike Cottmeyer
Ähnlich wie Agile Transformation | Mike Cottmeyer (20)
Mehr von LeadingAgile
Mehr von LeadingAgile (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Agile Transformation | Mike Cottmeyer
- 3. THIS TALK IS ABOUT GETTING PEOPLE TO MOVE...
- 4. AND KEEPING THEM MOVING THIS TALK IS ABOUT GETTING PEOPLE TO MOVE...
- 16. G O A L S O F G O I N G A G I L E
- 17. G O A L S O F G O I N G A G I L E P R E D I C TA B I L I T Y Agile tends to focus on adaptability but predictability is most often cited as the reason for agile transformation
- 18. G O A L S O F G O I N G A G I L E Q U A L I T Y As organizations scale, product quality often suffers. Agile focuses on quality from requirements through implementation.
- 19. G O A L S O F G O I N G A G I L E E A R LY R O I Many organizations struggle with 18 month delivery cycles. Agile helps your team accelerate time to market value
- 20. G O A L S O F G O I N G A G I L E L O W E R C O S T S Cost savings are tough to promise, but agile can help make sure you are spending money on features most likely to generate revenue
- 21. G O A L S O F G O I N G A G I L E I N N O VAT I O N As companies grow sometimes they slow down and loose the ability to innovate. Agile can help you get back your competitive edge.
- 22. G O A L S O F G O I N G A G I L E P R O D U C T F I T Delivering on time is only important if you are delivering the right product. Agile can help you get the feedback you need.
- 25. ... all three are essential, but where you start is also essential…
- 26. H O W B I G I S T H E O R G A N I Z AT I O N ? Single Team Multiple Teams
- 27. D O T E A M S H AV E D E P E N D E N C I E S ? Non-instantly Available Resources Too Much Work in Process Large Products with Diverse Technology Low Cohesion & Tight Coupling Technical Debt & Defects Shared Requirements Between Teams Limited Access to Subject Matter Expertise Matrixed Organizations
- 28. H O W M U C H R E S I S TA N C E ?
- 30. T H E 3 T H I N G S
- 31. T H E 3 T H I N G S BACKLOGS
- 32. T H E 3 T H I N G S BACKLOGS TEAMS
- 33. T H E 3 T H I N G S BACKLOGS TEAMS WORKING TESTED SOFTWARE
- 34. W H AT D O I M E A N ? INVEST CCC Small enough for the team to develop in a day or so BACKLOGS TEAMS WORKING TESTED SOFTWARE Everything and everyone necessary to deliver Meets acceptance criteria No known defects No technical debt
- 35. INVEST CCC Small enough for the team to develop in a day or so BACKLOGS TEAMS Everything and everyone necessary to deliver Meets acceptance criteria No known defects No technical debt W H AT D O I M E A N ? WORKING TESTED SOFTWARE
- 36. W H AT D O I M E A N ? INVEST CCC Small enough for the team to develop in a day or so BACKLOGS TEAMS Everything and everyone necessary to deliver Meets acceptance criteria No known defects No technical debt WORKING TESTED SOFTWARE
- 37. W H AT D O I M E A N ? Investment Decisioning Prioritization GOVERNANCE STRUCTURE METRICS Teaming Strategies at all levels of the organization How do we measure progress across teams How do we hold people accountable
- 38. W H AT D O I M E A N ? Investment Decisioning Prioritization GOVERNANCE STRUCTURE METRICS Teaming Strategies at all levels of the organization How do we measure progress across teams How do we hold people accountable
- 39. W H AT D O I M E A N ? Investment Decisioning Prioritization GOVERNANCE STRUCTURE METRICS Teaming Strategies at all levels of the organization How do we measure progress across teams How do we hold people accountable
- 40. WHE RE ARE WE NOW?
- 49. T RANS F ORM AT I ON I S A JOURNE Y
- 50. AE AC PE PC EMERGENC E CONVERGENCE ADAPTABILITY PREDICTABILIT Y AD-HOC LEAN STARTUP AGILETRADITIONAL
- 55. AE AC PE PC EMERGENC E CONVERGENCE ADAPTABILITY PREDICTABILIT Y AD-HOC LEAN STARTUP AGILELEAN/ AGILE LOW TRUST REDUCE BATCH SIZEBECOME PREDICTABLE
- 56. AE AC PE PC EMERGENC E CONVERGENCE ADAPTABILITY PREDICTABILIT Y AD-HOC LEAN STARTUP AGILELEAN/ AGILE LOW TRUST FULLY DECOUPLE REDUCE BATCH SIZEBECOME PREDICTABLE
- 57. A T HE ORY OF T RANS F ORM AT I ON
- 58. THEORY OF TRANSFORMATION // Adopting agile is about forming teams, building backlogs, and regularly producing increments of working tested software
- 59. THEORY OF TRANSFORMATION // Adopting agile at scale is about defining structure, establishing governance, and creating a metrics and tooling strategy that supports agility
- 60. THEORY OF TRANSFORMATION // Anything that gets in the way of forming teams, building backlogs, and producing working tested software is an impediment to transformation
- 61. THEORY OF TRANSFORMATION // Solid agile practices will help operationalize the system and encourage a healthy, adaptive, and empowered culture emerge over time
- 62. WHE RE ARE WE GOI NG?
- 64. Gartner Mode Two Gartner Mode One AE AC PE PC EMERGENC E CONVERGENCE ADAPTABILITY PREDICTABILIT Y AD-HOC LEAN STARTUP AGILETRADITIONAL
- 65. M AP P I NG T HE JOURNE Y
- 66. AE AC PE PC EMERGENC E CONVERGENCE ADAPTABILITY PREDICTABILIT Y AD-HOC LEAN STARTUP AGILELEAN/ AGILE LOW TRUST FULLY DECOUPLE REDUCE BATCH SIZEBECOME PREDICTABLE T E A MS
- 67. BASECAMP 1 AE AC PE PC EMERGENC E CONVERGENCE ADAPTABILITY PREDICTABILIT Y AD-HOC LEAN STARTUP AGILELEAN/ AGILE LOW TRUST FULLY DECOUPLE REDUCE BATCH SIZEBECOME PREDICTABLE T E A MS B1
- 68. BASECAMP 2 AE AC PE PC EMERGENC E CONVERGENCE ADAPTABILITY PREDICTABILIT Y AD-HOC LEAN STARTUP AGILELEAN/ AGILE LOW TRUST FULLY DECOUPLE REDUCE BATCH SIZEBECOME PREDICTABLE T E A MS B1 B2
- 69. BASECAMP 3 AE AC PE PC EMERGENC E CONVERGENCE ADAPTABILITY PREDICTABILIT Y AD-HOC LEAN STARTUP AGILELEAN/ AGILE LOW TRUST FULLY DECOUPLE REDUCE BATCH SIZEBECOME PREDICTABLE T E A MS B1 B2 B3
- 70. BASECAMP 3 DevOps AE AC PE PC EMERGENC E CONVERGENCE ADAPTABILITY PREDICTABILIT Y AD-HOC LEAN STARTUP AGILELEAN/ AGILE LOW TRUST FULLY DECOUPLE REDUCE BATCH SIZEBECOME PREDICTABLE T E A MS B1 B2 B3
- 71. AE AC PE PC EMERGENC E CONVERGENCE ADAPTABILITY PREDICTABILIT Y AD-HOC LEAN STARTUP AGILELEAN/ AGILE LOW TRUST FULLY DECOUPLE REDUCE BATCH SIZEBECOME PREDICTABLE T E A MS B1 B2 B3 B4 BASECAMP 4
- 72. AE AC PE PC EMERGENC E CONVERGENCE ADAPTABILITY PREDICTABILIT Y AD-HOC LEAN STARTUP AGILELEAN/ AGILE LOW TRUST FULLY DECOUPLE REDUCE BATCH SIZEBECOME PREDICTABLE BASECAMP 5 T E A MS B1 B2 B3 B4 B5
- 74. Services Teams – These teams support common services across product lines. These teams support the needs of the product teams.
- 75. Product Teams – These teams integrate services and write customer facing features. This is the proto-typical Scrum team. Services Teams – These teams support common services across product lines. These teams support the needs of the product teams.
- 76. Programs Teams – These teams define requirements, set technical direction, and provide context and coordination. Product Teams – These teams integrate services and write customer facing features. This is the proto-typical Scrum team. Services Teams – These teams support common services across product lines. These teams support the needs of the product teams.
- 77. Portfolio Teams – These teams govern the portfolio and make sure that work is moving through the system. Programs Teams – These teams define requirements, set technical direction, and provide context and coordination. Product Teams – These teams integrate services and write customer facing features. This is the proto-typical Scrum team. Services Teams – These teams support common services across product lines. These teams support the needs of the product teams.
- 78. DELIVERY TEAMS
- 81. GOV E RNANCE
- 82. 3 - T I E R G O V E R N A N C E EPIC ALIGNMENT MAKE READY EPIC PRIORITIZATION FEATURE DEFINITION STORY READY SOLUTION VALIDATION RELEASE TARGETING STORY MAPPING RELEASE PLANNING IN PROGRESS IN PROGRESS IN PROGRESS EPIC VALIDATION INTEGRATION VALIDATION STORY DONE STORY ACCEPTED FEATURE DEVELOPMENT FEATURE COMPLETED COMPLETED PORTFOLIO TEAM PROGRAM TEAM DELIVERY TEAM STRATEGIC ALIGNMENT SOLUTION VISION DEMAND PLANNING EXECUTION VALIDATION ACCEPTED DEMAND PLANNING EXECUTION & ACCOUNTABILITY INTAKE E p ic | K a n b a n F e a t u r e | K a n b a n S t o r y | S c r u m
- 83. 4 - T I E R G O V E R N A N C E MAKE READY STORY READY IN PROGRESS STORY DONE STORY ACCEPTED EPIC ALIGNMENT EPIC PRIORITIZATION SOLUTION VALIDATION RELEASE TARGETING IN PROGRESS EPIC VALIDATION COMPLETED PORTFOLIO TEAM PROGRAM TEAM DELIVERY TEAM STRATEGIC ALIGNMENT SOLUTION VISION DEMAND PLANNING EXECUTION VALIDATION ACCEPTED DEMAND PLANNING EXECUTION & ACCOUNTABILITY FEATURE DEFINITION STORY MAPPING RELEASE PLANNING IN PROGRESS INTEGRATION VALIDATION FEATURE DEPLOYMENT FEATURE COMPLETED INTAKE INVESTMENT DECISION INVESTMENT TARGETING IN PROGRESS INITIATIVE VALIDATION COMPLETED INITIATIVE DEFINITION INITIATIVE ROADMAP MEASUREABLE PROGRESS INVESTMENT I n it ia t iv e | K a n b a n E p ic | K a n b a n F e a t u r e | K a n b a n S t o r y | S c r u m
- 84. M E T RI CS
- 86. Scrum Kanban Kanban Backlog Size Velocity Burndown Escaped Defects Commit % Acceptance % Ratio Scope Change PORTFOLIO TEAMS DELIVERY TEAMS PROGRAM TEAMS
- 87. Scrum Kanban Kanban Backlog Size Velocity Burndown Escaped Defects Commit % Acceptance % Ratio Scope Change Cycle Time Features Blocked Rework/Defects PORTFOLIO TEAMS DELIVERY TEAMS PROGRAM TEAMS
- 88. Scrum Kanban Kanban Backlog Size Velocity Burndown Escaped Defects Commit % Acceptance % Ratio Scope Change Cycle Time Features Blocked Rework/Defects Takt Time/ Cycle Time Time/Cost/Scope/Value ROI/Capitalization PORTFOLIO TEAMS DELIVERY TEAMS PROGRAM TEAMS
- 90. I NCRE M E NTAL T RANS F ORM AT I ON (E X P E DI T I ONS )
- 91. PROGRAM TEAMS PORTFOLIO TEAMS DELIVERY TEAMS Scrum Kanban Kanban AGILE PILOT Expedition One AGILE ROLLOUT
- 92. PROGRAM TEAMS PORTFOLIO TEAMS DELIVERY TEAMS Scrum Kanban Kanban AGILE PILOT Expedition One AGILE ROLLOUT Expedition Two
- 93. PROGRAM TEAMS PORTFOLIO TEAMS DELIVERY TEAMS Scrum Kanban Kanban AGILE PILOT Expedition One AGILE ROLLOUT Expedition Three ➔ N
- 94. I T E RAT I V E T RANS F ORM AT I ON (BAS E CAM P S )
- 100. E X P E DI T I ONS & BAS E CAM P S
- 104. PROGRAM TEAMS PORTFOLIO TEAMS DELIVERY TEAMS Scrum Kanban Kanban AGILE PILOT Basecamp Four AGILE ROLLOUT Basecamp Two
- 105. PROGRAM TEAMS PORTFOLIO TEAMS DELIVERY TEAMS Scrum Kanban Kanban AGILE PILOT Basecamp Five AGILE ROLLOUT Basecamp Three
- 106. P L AY BOOK & F I E L D GUI DE
- 107. S T E P 1 Agile transformation isn’t something that can be done to an organization. They have to be full participants Holding the organization accountable Remove Impediments Plan the work Review Progress Inspect and Adapt WHY WHAT HOW Executive Steering Committee Transformation Leadership Team
- 108. S T E P 2 We have to have some idea of where we are going before we start We will accept the plan will change Transformation Workshop Pilot Broad Organization Rollout Create Feedback Loops WHY WHAT HOW Create a working hypothesis for structure, governance, and metrics Plan to progressively elaborate
- 109. S T E P 3 We have to be able to give the organization some idea of what we are doing, when, and how long What teams are going to be formed? What training do they need? What coaching do they need? When will this all happen? WHY WHAT HOW Expeditions Basecamps Sequenced in Time
- 110. S T E P 4 Very similar to an agile release plan, we want a rolling 90 day, fairly specific view of what is going to take place Week by week training and coaching plans Detailed resource planning Expected activities and outcomes. WHY WHAT HOW Transformation leadership team meets periodically to plan forward, assess progress, and adjust as necessary
- 111. S T E P 5 Very similar to a sprint cycle in Scrum We want to periodically assess progress, retrospect, and adjust Scheduled recurring meetings Review planning artifacts Review metrics Improvement plans WHY WHAT HOW ELT reviews progress against strategy and outcomes TLT focuses on how well the plan is moving along
- 112. S T E P 6 The whole reason we are doing this is to get better business outcomes This is where we begin justifying the investment Assessments Status Reports Coaching Plans WHY WHAT HOW Create hypotheses Conduct experiments Demonstrate outcomes Pivot based on what we learn
- 113. S T E P 7 We want to be able to trace improvements in the system to tangible business benefits Assessment Outcomes Transformation metrics Business Metrics WHY WHAT HOW Business metric baselines Regularly show progress Update coaching plans as necessary
- 114. S T E P 8 Our understanding will evolve throughout the transformation Refine the End- State Vision and the Roadmap WHY WHAT HOW Re-assess the End- State Vision based on the evolving understanding
- 115. S T E P 9 Letting everyone know what is going on and the success of the program will create excitement and energy Town Halls Executive roundtables Signage Information Radiators Cadence of Accountability WHY WHAT HOW Regular communication from leadership Be transparent about progress and impediments
- 116. S T E P 1 0 Understand what’s in it for everyone involved and help them see where they fit in the new organization Team assignments Staffing plans Job descriptions Job aids Communities of Practice WHY WHAT HOW Clarity Accountability Measurable progress
- 118. T RANS F ORM AT I ON M E T RI CS
- 119. C A PA B I L I T Y I M P R O V E M E N T S
- 120. C A PA B I L I T Y I M P R O V E M E N T S DEFINE THE PRODUCT
- 121. PLAN & COORDINATE C A PA B I L I T Y I M P R O V E M E N T S DEFINE THE PRODUCT
- 122. PLAN & COORDINATE C A PA B I L I T Y I M P R O V E M E N T S DEFINE THE PRODUCT DELIVER THE SOLUTION
- 123. ORGANIZATION ENABLEMENT PLAN & COORDINATE C A PA B I L I T Y I M P R O V E M E N T S DEFINE THE PRODUCT DELIVER THE SOLUTION
- 124. ORGANIZATION ENABLEMENT PLAN & COORDINATE C A PA B I L I T Y I M P R O V E M E N T S DEFINE THE PRODUCT DELIVER THE SOLUTION CONTINUOUS IMPROVEMENT
- 125. M E A S U R I N G P R O G R E S S
- 126. M E A S U R I N G P R O G R E S S ACTIVITIES
- 127. M E A S U R I N G P R O G R E S S ACTIVITIES OUTCOMES
- 128. M E A S U R I N G P R O G R E S S ACTIVITIES OUTCOMES BASECAMPS
- 129. BUS I NE S S M E T RI CS
- 130. G O A L S A N D O B J E C T I V E S
- 131. G O A L S A N D O B J E C T I V E S PREDICTABILITY
- 132. G O A L S A N D O B J E C T I V E S PREDICTABILITY QUALITY
- 133. G O A L S A N D O B J E C T I V E S PREDICTABILITY EARLY ROI QUALITY
- 134. G O A L S A N D O B J E C T I V E S PREDICTABILITY EARLY ROI QUALITY LOWER COSTS
- 135. G O A L S A N D O B J E C T I V E S PREDICTABILITY EARLY ROI INNOVATION QUALITY LOWER COSTS
- 136. G O A L S A N D O B J E C T I V E S PREDICTABILITY EARLY ROI INNOVATION QUALITY LOWER COSTS PRODUCT FIT
- 137. F I N A N C I A L M E A S U R E M E N T
- 138. F I N A N C I A L M E A S U R E M E N T RETURN ON INVESTMENT
- 139. F I N A N C I A L M E A S U R E M E N T RETURN ON INVESTMENT PAYBACK PERIOD
- 140. F I N A N C I A L M E A S U R E M E N T RETURN ON INVESTMENT PAYBACK PERIOD CAPITALIZATION RATE
- 141. F I N A N C I A L M E A S U R E M E N T RETURN ON INVESTMENT PAYBACK PERIOD CAPITALIZATION RATE REVENUE ACCELERATION
- 142. F I N A N C I A L M E A S U R E M E N T RETURN ON INVESTMENT PAYBACK PERIOD CAPITALIZATION RATE REVENUE ACCELERATION PRODUCTIVITY IMPROVEMENTS
- 143. F I N A N C I A L M E A S U R E M E N T RETURN ON INVESTMENT PAYBACK PERIOD CAPITALIZATION RATE REVENUE ACCELERATION PRODUCTIVITY IMPROVEMENTS EMPLOYEE TURNOVER RATIO
- 145. R O L E S
- 146. R O L E S ACCOUNT LEAD
- 147. R O L E S TRANSFORMATION LEAD ACCOUNT LEAD
- 148. R O L E S TRANSFORMATION LEAD EXPEDITION LEAD ACCOUNT LEAD
- 149. R O L E S TRANSFORMATION LEAD EXPEDITION LEAD ENTERPRISE TRANSFORMATION CONSULTANT ACCOUNT LEAD
- 150. R O L E S TRANSFORMATION LEAD EXPEDITION LEAD ENTERPRISE TRANSFORMATION CONSULTANT ANALYST ACCOUNT LEAD
- 151. R O L E S TRANSFORMATION LEAD EXPEDITION LEAD ENTERPRISE TRANSFORMATION CONSULTANT ANALYST SPECIALIST ACCOUNT LEAD
- 153. C O M P E T E N C I E S
- 154. C O M P E T E N C I E S Skills Experience Culture Community
- 155. C O M P E T E N C I E S Skills Experience Culture Community Beliefs Behaviors
- 156. C O M P E T E N C I E S Skills Experience Culture Community Beliefs Behaviors EQ IQ
- 157. C O M P E T E N C I E S Skills Experience Culture Community Beliefs Behaviors EQ IQ Pattern Recognition Systems Thinking
- 158. T I T L E S
- 159. ASSOCIATE CONSULTANT T I T L E S
- 160. ASSOCIATE CONSULTANT STAFF CONSULTANT T I T L E S
- 162. ASSOCIATE CONSULTANT STAFF CONSULTANT SENIOR CONSULTANT T I T L E S MANAGING CONSULTANT
- 163. ASSOCIATE CONSULTANT STAFF CONSULTANT SENIOR CONSULTANT T I T L E S MANAGING CONSULTANT PRINCIPLE CONSULTANT
Hinweis der Redaktion
- 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.
- This graphic shows an overall delivery and organization structure and approach for an agile enterprise. Walk through each of these sections with class attendees and discuss the phases and steps involved, starting with the portfolio teams’ decisions around investment prioritization, demand validation, release feasibility analysis and planning, through to development and production. By starting at the top left and working your way through the graphic, you should be able to hit each of the critical steps along the way that matter to an enterprise. Since this is a Fundamentals class, you don’t need to dive into each of the steps in detail. Rather, the point to be made here is that there is a way to structure an enterprise to be agile in its’ planning and delivery.
- This graphic shows an overall delivery and organization structure and approach for an agile enterprise. Walk through each of these sections with class attendees and discuss the phases and steps involved, starting with the portfolio teams’ decisions around investment prioritization, demand validation, release feasibility analysis and planning, through to development and production. By starting at the top left and working your way through the graphic, you should be able to hit each of the critical steps along the way that matter to an enterprise. Since this is a Fundamentals class, you don’t need to dive into each of the steps in detail. Rather, the point to be made here is that there is a way to structure an enterprise to be agile in its’ planning and delivery.