-
1.
THE EXECUTIVES GUIDE
To Leading Large Scale Agile Transformation
-
2.
mike@leadingagile.com
404-312-1471
www.leadingagile.com
twitter.com/mcottmeyer
facebook.com/leadingagile
linkedin.com/in/cottmeyer
MIKE COTTMEYER
-
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?
-
14.
Culture
PracticesSystems
BELIEFS…
-
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?
-
23.
Backlog
Backlog
Backlog
Backlog
Backlogs
-
24.
Teams
Backlog
Backlog
Backlog
Backlog
Backlogs Teams
-
25.
Teams
Backlog
Backlog
Backlog
Backlog
Working
Tested
Software
Backlogs Teams Working Tested
Software
-
26.
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
-
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
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?
-
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.
WHAT GETS IN THE WAY?
-
35.
Team
-
36.
Matrixed
Organizations
Team
-
37.
Matrixed
Organizations
Non-instantly
Available
Resources
Team
-
38.
Matrixed
Organizations
Limited Access
to Subject Matter
Expertise
Non-instantly
Available
Resources
Team
-
39.
Matrixed
Organizations
Limited Access
to Subject Matter
Expertise
Non-instantly
Available
Resources
Shared
Requirements
Between Teams
Team
-
40.
Matrixed
Organizations
Limited Access
to Subject Matter
Expertise
Non-instantly
Available
Resources
Too Much Work
In Process
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
Large Products
with Diverse
Technology
Team
-
42.
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
-
43.
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
-
44.
A THEORY OF
TRANSFORMATION
-
45.
Theory of Transformation
Adopting agile is about
forming teams, building
backlogs, and regularly
producing increments of
working tested software
-
46.
Theory of Transformation
Adopting agile at scale is
about defining structure,
establishing governance, and
creating a metrics and tooling
strategy that supports agility
-
47.
Theory of Transformation
Anything that gets in the way
of forming teams, building
backlogs, and producing
working tested software is an
impediment to transformation
-
48.
Theory of Transformation
Solid agile practices will help
operationalize the system and
encourage a healthy,
adaptive, and empowered
culture emerge over time
-
49.
ORGANIZING THE WORK
-
50.
Services Teams – These teams
support common services across
product lines. These teams support the
needs of the product teams.
Team
-
51.
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
-
52.
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
-
53.
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
-
54.
Team Team Team Team
TeamTeamTeam
Product &
Services
Teams
-
55.
Team Team Team
Team Team Team Team
TeamTeamTeam
Product &
Services
Teams
Program
Teams
-
56.
Team
Team Team Team
Team Team Team Team
TeamTeamTeam
Product &
Services
Teams
Program
Teams
Portfolio
Teams
-
57.
Product &
Services
Teams
Scrum
Team
Team Team Team
Team Team Team Team
TeamTeamTeam
Program
Teams
Portfolio
Teams
-
58.
Product &
Services
Teams
Program
Teams
Portfolio
Teams
Scrum
Kanban
Team
Team Team Team
Team Team Team Team
TeamTeamTeam
-
59.
Product &
Services
Teams
Program
Teams
Portfolio
Teams
Scrum
Kanban
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
• Backlog Size
• Velocity
• Burndown
• Escaped Defects
• Commit % Ratio
• Acceptance % Ratio
• Scope Change
-
61.
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
-
62.
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
-
63.
INCREMENTAL
TRANSFORMATION
(EXPEDITIONS)
-
64.
Product &
Services
Teams
Program
Teams
Portfolio
Teams
Scrum
Kanban
Kanban
Team
Team Team Team
Team Team Team Team
TeamTeamTeam
Agile Pilot
Increment One
-
65.
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
-
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
Three - N
-
67.
ITERATIVE
TRANSFORMATION
(BASECAMPS)
-
68.
Product &
Services
Teams
Program
Teams
Portfolio
Teams
Scrum
Kanban
Kanban
Team
Team Team Team
Team Team Team Team
TeamTeamTeam
Agile Pilot
Iteration One
-
69.
Product &
Services
Teams
Program
Teams
Portfolio
Teams
Scrum
Kanban
Kanban
Team
Team Team Team
Team Team Team Team
TeamTeamTeam
Agile Pilot
Iteration Two
-
70.
Product &
Services
Teams
Program
Teams
Portfolio
Teams
Scrum
Kanban
Kanban
Team
Team Team Team
Team Team Team Team
TeamTeamTeam
Agile Pilot
Iteration Three
-
71.
Product &
Services
Teams
Program
Teams
Portfolio
Teams
Scrum
Kanban
Kanban
Agile Pilot
Iteration Four
Team
Team Team Team
Team Team Team Team
TeamTeamTeam
-
72.
Product &
Services
Teams
Program
Teams
Portfolio
Teams
Scrum
Kanban
Kanban
Agile Pilot
Iteration Five
Team Team
Team Team Team
TeamTeamTeam
Team
Team
Team
-
73.
EXPEDITIONS &
BASECAMPS
-
74.
Product &
Services
Teams
Program
Teams
Portfolio
Teams
Scrum
Kanban
Kanban
Agile Pilot
Iteration One
Team Team
Team Team Team
TeamTeamTeam
Team
Team
Team
-
75.
Product &
Services
Teams
Program
Teams
Portfolio
Teams
Scrum
Kanban
Kanban
Agile Pilot
Team Team
Team Team Team
TeamTeamTeam
Team
Team
Team
Iteration Two
-
76.
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
-
77.
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
-
78.
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
-
79.
THE EXECUTIVES GUIDE
-
80.
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
-
81.
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
-
82.
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
-
83.
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
-
84.
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
-
85.
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
-
86.
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
-
87.
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
-
88.
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
-
89.
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
-
90.
IN CONCLUSION…
-
91.
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
-
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.
ONE MORE THING…
-
96.
Wednesday, July 27th @ 7:00 PM
collectivesoul.leadingagile.com
Unlock Code: agile2016
-
97.
mike@leadingagile.com
404-312-1471
www.leadingagile.com
twitter.com/mcottmeyer
facebook.com/leadingagile
linkedin.com/in/cottmeyer
MIKE COTTMEYER
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.
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.
Matrixed management
Non-instantly available resources
Project funding models
Limited access to subject matter expertise
Shared requirements between teams
Technical debt
Defects
Tightly coupled architectures
Matrixed management
Non-instantly available resources
Project funding models
Limited access to subject matter expertise
Shared requirements between teams
Technical debt
Defects
Tightly coupled architectures
Matrixed management
Non-instantly available resources
Project funding models
Limited access to subject matter expertise
Shared requirements between teams
Technical debt
Defects
Tightly coupled architectures
Matrixed management
Non-instantly available resources
Project funding models
Limited access to subject matter expertise
Shared requirements between teams
Technical debt
Defects
Tightly coupled architectures
Matrixed management
Non-instantly available resources
Project funding models
Limited access to subject matter expertise
Shared requirements between teams
Technical debt
Defects
Tightly coupled architectures
Matrixed management
Non-instantly available resources
Project funding models
Limited access to subject matter expertise
Shared requirements between teams
Technical debt
Defects
Tightly coupled architectures
Matrixed management
Non-instantly available resources
Project funding models
Limited access to subject matter expertise
Shared requirements between teams
Technical debt
Defects
Tightly coupled architectures
Matrixed management
Non-instantly available resources
Project funding models
Limited access to subject matter expertise
Shared requirements between teams
Technical debt
Defects
Tightly coupled architectures
Matrixed management
Non-instantly available resources
Project funding models
Limited access to subject matter expertise
Shared requirements between teams
Technical debt
Defects
Tightly coupled architectures