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