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