The Executives Step-by-Step Guide to Leading a Large-Scale Agile Transformation
•
25 likes•8,792 views
This talk explores a safe, pragmatic, and repeatable formula for leading change in large organizations. The Holy Grail for an executive is to tie dollars spent and activities performed, to internal improvement metrics and ultimately improved business performance. We’ll start by discussing the elements of an agile transformation business case and how to identify a meaningful value proposition for change. Next we’ll consider how to assess the organization and build an agile transformation strategy and roadmap that encourages an iterative and incremental approach to change. Finally we’ll explore the metrics and controls that help you know if you’re on the right track. Throughout the presentation, we’ll explore the change management and engagement techniques necessary to make sure you are building meaningful organizational support as you engage the enterprise. We’ll discuss how to build and execute a change management strategy to keep everyone safe and informed throughout the transformation. We’ll show how to sustain and improve the changes over time, ultimately creating an organizational ecosystem where business agility is part of the fundamental DNA of the company. The goal of this talk is to take the magic out of agile transformation and show you how to systematically and planfully introduce agile into your organization.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (14)
Similar to The Executives Step-by-Step Guide to Leading a Large-Scale Agile Transformation
Similar to The Executives Step-by-Step Guide to Leading a Large-Scale Agile Transformation (20)
More from LeadingAgile
More from LeadingAgile (20)
Recently uploaded
Recently uploaded (20)
The Executives Step-by-Step Guide to Leading a Large-Scale Agile Transformation
- 1. THE EXECUTIVES GUIDE To Leading Large Scale Agile Transformation
- 3. Brief Agenda • Understand How to Think About Transformation • Discuss How to Organize Transformation Work • Explore How to Plan, Manage, and Track Progress
- 4. Brief Agenda • Understand How to Think About Transformation • Discuss How to Organize Transformation Work • Explore How to Plan, Manage, and Track Progress
- 5. Brief Agenda • Understand How to Think About Transformation • Discuss How to Organize Transformation Work • Explore How to Plan, Manage, and Track Progress
- 6. Brief Agenda • Understand How to Think About Transformation • Discuss How to Organize Transformation Work • Explore How to Plan, Manage, and Track Progress
- 7. THE GAME HAS CHANGED
- 8. EXECUTIVES CARE… • Executives want to adopt agile but don’t know how • They need line of sight to how the transformation is going to unfold • Have to be able to continuously justify the economics of the transformation to key stakeholders
- 9. EXECUTIVES CARE… • Executives want to adopt agile but don’t know how • They need line of sight to how the transformation is going to unfold • Have to be able to continuously justify the economics of the transformation to key stakeholders
- 10. EXECUTIVES CARE… • Executives want to adopt agile but don’t know how • They need line of sight to how the transformation is going to unfold • Have to be able to continuously justify the economics of the transformation to key stakeholders
- 11. EXECUTIVES CARE… • Executives want to adopt agile but don’t know how • They need line of sight to how the transformation is going to unfold • Have to be able to continuously justify the economics of the transformation to key stakeholders
- 12. Key Point Even if we believe in self- organization, many executives will not buy into an unplanned, emergent style of agile transformation…
- 13. WHAT DO YOU BELIEVE ABOUT TRANSFORMATION?
- 15. Culture PracticesSystems • Focused on changing hearts and minds • Focused on being agile rather than doing agile • Focused on values and principles CULTURE DRIVEN
- 16. Culture PracticesSystems • Focused on changing hearts and minds • Focused on being agile rather than doing agile • Focused on values and principles • Belief that delivery systems will emerge based on new thinking CULTURE DRIVEN
- 17. Practices SystemsCulture • Focused on the things that you do • Focused on roles, ceremonies, and artifacts • Can be management driven or technically driven PRACTICES DRIVEN
- 18. Practices SystemsCulture • Focused on the things that you do • Focused on roles, ceremonies, and artifacts • Can be management driven or technically driven • Belief that agile is a process or way to work PRACTICES DRIVEN
- 19. Systems CulturePractices • Focused on forming teams and governing the flow of value • Focused on aligning the organization first SYSTEMS DRIVEN
- 20. Systems CulturePractices • Focused on forming teams and governing the flow of value • Focused on aligning the organization first • Belief that culture and practices only emerge within a rational structural and planning framework SYSTEMS DRIVEN
- 21. Systems CulturePractices ... all three are essential, but where you start is also essential… WHERE TO START?
- 22. WHAT DO I MEAN BY SYSTEMS?
- 26. Teams Backlog Backlog Backlog Backlog Working Tested Software Backlogs Teams Working Tested Software
- 27. 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
- 28. 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
- 29. 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
- 30. 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
- 31. 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?
- 32. 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?
- 33. 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?
- 34. 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?
- 35. WHAT GETS IN THE WAY?
- 36. Team
- 39. Matrixed Organizations Limited Access to Subject Matter Expertise Non-instantly Available Resources Team
- 40. Matrixed Organizations Limited Access to Subject Matter Expertise Non-instantly Available Resources Shared Requirements Between Teams Team
- 41. Matrixed Organizations Limited Access to Subject Matter Expertise Non-instantly Available Resources Too Much Work In Process Shared Requirements Between Teams Team
- 42. 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
- 43. 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
- 44. 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
- 46. Theory of Transformation Adopting agile is about forming teams, building backlogs, and regularly producing increments of working tested software
- 47. Theory of Transformation Adopting agile at scale is about defining structure, establishing governance, and creating a metrics and tooling strategy that supports agility
- 48. Theory of Transformation Anything that gets in the way of forming teams, building backlogs, and producing working tested software is an impediment to transformation
- 49. Theory of Transformation Solid agile practices will help operationalize the system and encourage a healthy, adaptive, and empowered culture emerge over time
- 51. Services Teams – These teams support common services across product lines. These teams support the needs of the product teams. Team
- 52. 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. Team Team
- 53. 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. Team Team Team
- 54. 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. Team Team Team Team
- 55. Team Team Team Team TeamTeamTeam Product & Services Teams
- 56. Team Team Team Team Team Team Team TeamTeamTeam Product & Services Teams Program Teams
- 57. Team Team Team Team Team Team Team Team TeamTeamTeam Product & Services Teams Program Teams Portfolio Teams
- 58. Product & Services Teams Scrum Team Team Team Team Team Team Team Team TeamTeamTeam Program Teams Portfolio Teams
- 59. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Team Team Team Team Team Team Team Team TeamTeamTeam
- 60. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam
- 61. 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
- 62. 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
- 63. 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
- 65. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam Agile Pilot Increment One
- 66. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam Agile Pilot Increment One Agile Rollout Increment Two
- 67. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam Agile Pilot Increment One Agile Rollout Three - N
- 69. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam Agile Pilot Iteration One
- 70. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam Agile Pilot Iteration Two
- 71. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Team Team Team Team Team Team Team Team TeamTeamTeam Agile Pilot Iteration Three
- 72. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Agile Pilot Iteration Four Team Team Team Team Team Team Team Team TeamTeamTeam
- 73. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Agile Pilot Iteration Five Team Team Team Team Team TeamTeamTeam Team Team Team
- 75. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Agile Pilot Iteration One Team Team Team Team Team TeamTeamTeam Team Team Team
- 76. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Agile Pilot Team Team Team Team Team TeamTeamTeam Team Team Team Iteration Two
- 77. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Agile Pilot Iteration Three Agile Rollout Iteration One Team Team Team Team Team TeamTeamTeam Team Team Team
- 78. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Agile Pilot Iteration Four Agile Rollout Iteration Two Team Team Team Team Team TeamTeamTeam Team Team Team
- 79. Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Agile Pilot Iteration Five Agile Rollout Iteration Three Team Team Team Team Team TeamTeamTeam Team Team Team
- 81. STEP ONE • Agile transformation isn’t something that can be done to the organization • They have to be full participants • Executive Steering Committee • Transformation Leadership Team • Hold the organization accountable • Remove impediments • Plan the work • Review progress • Inspect and adapt Build a Leadership Coalition Why How What
- 82. STEP TWO • We have to have some idea of where we are going before we start • We accept the plan will change • Create a working hypothesis for structure, governance, and metrics • Plan to Progressively Elaborate • Transformation Workshop • Pilot • Broad Organizational Rollout • Create feedback loops Define an End-State Vision Why How What
- 83. STEP THREE • We have to be able to give the organization some idea of what we are doing, when, and for how long • Expeditions • Basecamps • Sequenced in Time • What teams are going to formed • What training do they need • What coaching do they need • When will all this happen? Build a Roadmap Why How What
- 84. STEP FOUR • Very similar to an agile release plan, we want a rolling 90 day, fairly specific view of what is going to take place • Transformation leadership team meets periodically to plan forward, assess progress, and adjust as necessary • Week by week training and coaching plans • Detailed resource planning • Expected activities and outcomes Maintain a Rolling 90-Day Plan Why How What
- 85. STEP FIVE • Very similar to the sprint cycle in Scrum • We want to periodically assess progress, retrospect, and adjust • ELT reviews progress against strategy and outcomes • TLT focuses on how well the plan is moving along • Scheduled recurring meetings • Review planning artifacts • Review metrics • Improvement plans Conduct 30-Day Checkpoints Why How What
- 86. STEP SIX • The whole reason we are doing this is to get better business outcomes • This is where we begin justifying the investment • Create hypotheses • Conduct experiments • Demonstrate outcomes • Pivot based on what we learn • Assessments • Status Reports • Coaching Plans Connect Activity to Outcomes Why How What
- 87. STEP SEVEN • We want to be able to trace improvements in the system to tangible business benefits • Business metric baselines • Regularly show progress • Update coaching plans as necessary • Assessment Outcomes • Transformation metrics • Business Metrics Connect Outcomes to Business Objectives Why How What
- 88. STEP EIGHT • Our understanding will evolve throughout the transformation • Re-assess the End-State Vision based on the evolving understanding • Refine the End-State Vision and the Roadmap Incorporate Feedback Why How What
- 89. STEP NINE • Letting everyone know what is going on and the success of the program will create excitement and energy • Regular communication from leadership • Be transparent about progress and impediments • Town Halls • Executive roundtables • Signage • Information Radiators • Cadence of Accountability Manage Communication Why How What
- 90. STEP TEN • Understand what’s in it for everyone involved and help them see where they fit in the new organization • Clarity • Accountability • Measureable progress • Team assignments • Staffing plans • Job descriptions • Job aids • Communities of Practice Create Safety For Everyone Involved Why How What
- 91. IN CONCLUSION…
- 92. In Conclusion… • Adopting agile is a systems problem, especially at scale • Performant organizations are the unit of value • Change can be planned, measured, and controlled
- 93. In Conclusion… • Adopting agile is a systems problem, especially at scale • Performant organizations are the unit of value • Change can be planned, measured, and controlled
- 94. In Conclusion… • Adopting agile is a systems problem, especially at scale • Performant organizations are the unit of value • Change can be planned, measured, and controlled
- 95. In Conclusion… • Adopting agile is a systems problem, especially at scale • Performant organizations are the unit of value • Change can be planned, measured, and controlled