AGILE TRANSFORMATION
EXPLAINED
22
mike@leadingagile.com
404-312-1471
www.leadingagile.com
twitter.com/mcottmeyer
facebook.com/leadingagile
linkedin.com/in/cottmeyer
MIKE COTTMEYER
33
• Deciding the Scope of the Transformation
• Deciding Your Transformation Approach
• Managing Change and Measuring Progress
BRIEF AGENDA
44
• Deciding the Scope of the Transformation
• Deciding Your Transformation Approach
• Managing Change and Measuring Progress
BRIEF AGENDA
55
• Deciding the Scope of the Transformation
• Deciding Your Transformation Approach
• Managing Change and Measuring Progress
BRIEF AGENDA
66
• Deciding the Scope of the Transformation
• Deciding Your Transformation Approach
• Managing Change and Measuring Progress
BRIEF AGENDA
DECIDING THE
SCOPE OF THE
TRANSFORMATION
W H Y A R E W E
T R A N S F O R M I N G ?
99
GOALS OF GOING AGILE
PREDICTABILITY
Agile tends to focus on adaptability but
predictability is most often cited as the reason
for agile transformation
EARLY ROI
Many organizations struggle with 18 month
delivery cycles. Agile helps your team
accelerate time to market value
INNOVATION
As companies grow sometimes they slow down
and loose th ability to innovate. Agile can help
you get back your competitive edge.
QUALITY
As organizations scale, product quality often
suffers. Agile focuses on quality from
requirements through implementation.
LOWER COSTS
Cost savings are tough to promise, but agile can
help make sure you are only spending money
on the features most likely to generate revenue
PRODUCT FIT
Delivering on time is only important if you are
delivering the right product. Agile can help you
get the feedback you need.
W H A T A R E W E
T R A N S F O R M I N G ?
1111
1212
CULTURE FOCUSED
Focused on changing
hearts and minds
Focused on being agile
rather than doing agile
Focused on values and
principles
1313
CULTURE FOCUSED
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
1414
PRACTICES FOCUSED
Focused on the things
that you do
Focused on roles,
ceremonies, and
artifacts
Can be management
driven or technically
driven
1515
PRACTICES FOCUSED
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
1616
SYSTEMS FOCUSED
Focused on forming
teams and governing
the flow of value
Focused on aligning
the organization first
1717
SYSTEMS FOCUSED
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
1818
... all three are essential,
but where you start
is also essential…
W H A T D O W E N E E D
T O O V E R C O M E ?
2020
HOW BIG IS THE ORGANIZATION?
Single Team
Multiple Teams
2121
DO TEAMS HAVE DEPENDENCIES?
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
2222
HOW MUCH RESISTANCE?
DEFINING A
TRANSFORMATION
APPROACH
T H E N O N -
N E G O T I A B L E C O R E
2525
THE 3 THINGS
2626
BACKLOGS
THE 3 THINGS
2727
BACKLOGS TEAMS
THE 3 THINGS
2828
BACKLOGS TEAMS WORKING TESTED
SOFTWARE
THE 3 THINGS
2929
WHAT DO I MEAN?
• 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
3030
WHAT DO I MEAN?
• 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
3131
WHAT DO I MEAN?
• 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
3232
WHY ARE THEY IMPORTANT?
• People have clarity
around what to build
• People understand how
it maps to the big
picture
CLARITY ACCOUNTABILITY MEASURABLE
PROGRESS
• Teams can be held
accountable for delivery
• No indeterminate work
piling up at the end of
the project
• 90% done, 90% left to do
3333
WHY ARE THEY IMPORTANT?
• People have clarity
around what to build
• People understand how
it maps to the big
picture
CLARITY ACCOUNTABILITY MEASURABLE
PROGRESS
• Teams can be held
accountable for delivery
• No indeterminate work
piling up at the end of
the project
• 90% done, 90% left to do
3434
WHY ARE THEY IMPORTANT?
• People have clarity
around what to build
• People understand how
it maps to the big
picture
CLARITY ACCOUNTABILITY MEASURABLE
PROGRESS
• Teams can be held
accountable for delivery
• No indeterminate work
piling up at the end of
the project
• 90% done, 90% left to do
3535
WHY ARE THEY IMPORTANT?
• Understanding the
backlog gives meaning
to work
PURPOSE AUTONOMY MASTERY
• Local decision making
gives people a sense of
power and control over
their work
• People can demonstrate
that they are good at
what they do
3636
WHY ARE THEY IMPORTANT?
• Understanding the
backlog gives meaning
to work
PURPOSE AUTONOMY MASTERY
• Local decision making
gives people a sense of
power and control over
their work
• People can demonstrate
that they are good at
what they do
3737
WHY ARE THEY IMPORTANT?
• Understanding the
backlog gives meaning
to work
PURPOSE AUTONOMY MASTERY
• Local decision making
gives people a sense of
power and control over
their work
• People can demonstrate
that they are good at
what they do
E L E M E N T S O F
O R G A N I Z A T I O N
3939
Services Teams – These teams support
common services across product lines. These
teams support the needs of the product teams.
4040
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.
4141
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.
4242
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.
4343
DELIVERY
TEAMS
4444
PROGRAM
TEAMS
DELIVERY
TEAMS
4545
PROGRAM
TEAMS
PORTFOLIO
TEAMS
DELIVERY
TEAMS
W H E R E A R E W E ?
4747
ADAPTABILITY
PREDICTABILITY
4848
EMERGENCE
CONVERGENCE
ADAPTABILITY
PREDICTABILITY
4949
AE
PC
EMERGENCE
CONVERGENCE
ADAPTABILITY
PREDICTABILITY
5050
AE
AC
PE
PC
EMERGENCE
CONVERGENCE
ADAPTABILITY
PREDICTABILITY
5151
AE
AC
PE
PC
EMERGENCE
CONVERGENCE
ADAPTABILITY
PREDICTABILITY
AD-HOC LEAN
STARTUP
AGILETRADITIONAL
QUADRANT 1
5252
AE
AC
PE
PC
EMERGENCE
CONVERGENCE
ADAPTABILITY
PREDICTABILITY
AD-HOC LEAN
STARTUP
AGILETRADITIONAL
QUADRANT 2
5353
AE
AC
PE
PC
EMERGENCE
CONVERGENCE
ADAPTABILITY
PREDICTABILITY
AD-HOC LEAN
STARTUP
AGILETRADITIONAL
QUADRANT 3
5454
AE
AC
PE
PC
EMERGENCE
CONVERGENCE
ADAPTABILITY
PREDICTABILITY
AD-HOC LEAN
STARTUP
AGILETRADITIONAL
QUADRANT 4
A T H E O R Y O F
T R A N S F O R M A T I O N
THEORY OF TRANSFORMATION //
Adopting agile is about forming
teams, building backlogs, and
regularly producing increments
of working tested software
THEORY OF TRANSFORMATION //
Adopting agile at scale is about
defining structure, establishing
governance, and creating a
metrics and tooling strategy
that supports agility
THEORY OF TRANSFORMATION //
Anything that gets in the way
of forming teams, building
backlogs, and producing
working tested software is an
impediment to transformation
THEORY OF TRANSFORMATION //
Solid agile practices will help
operationalize the system and
encourage a healthy, adaptive,
and empowered culture
emerges over time
T R A N S F O R M A T I O N
I S A J O U R N E Y
6161
AE
AC
PE
PC
EMERGENCE
CONVERGENCE
ADAPTABILITY
PREDICTABILITY
AD-HOC LEAN
STARTUP
AGILETRADITIONAL
6262
AE
AC
PE
PC
EMERGENCE
CONVERGENCE
ADAPTABILITY
PREDICTABILITY
AD-HOC LEAN
STARTUP
AGILETRADITIONAL
LOW TRUST
6363
AE
AC
PE
PC
EMERGENCE
CONVERGENCE
ADAPTABILITY
PREDICTABILITY
AD-HOC LEAN
STARTUP
AGILETRADITIONAL
LOW TRUST
BECOME PREDICTABLE
6464
AE
AC
PE
PC
EMERGENCE
CONVERGENCE
ADAPTABILITY
PREDICTABILITY
AD-HOC LEAN
STARTUP
AGILETRADITIONAL
LOW TRUST
BECOME PREDICTABLE
6565
AE
AC
PE
PC
EMERGENCE
CONVERGENCE
ADAPTABILITY
PREDICTABILITY
AD-HOC LEAN
STARTUP
AGILELEAN/
AGILE
LOW TRUST
BECOME PREDICTABLE
6666
AE
AC
PE
PC
EMERGENCE
CONVERGENCE
ADAPTABILITY
PREDICTABILITY
AD-HOC LEAN
STARTUP
AGILELEAN/
AGILE
LOW TRUST
REDUCE BATCH SIZEBECOME PREDICTABLE
6767
AE
AC
PE
PC
EMERGENCE
CONVERGENCE
ADAPTABILITY
PREDICTABILITY
AD-HOC LEAN
STARTUP
AGILELEAN/
AGILE
LOW TRUST
FULLY DECOUPLE
REDUCE BATCH SIZEBECOME PREDICTABLE
6868
AE
AC
PE
PC
EMERGENCE
CONVERGENCE
ADAPTABILITY
PREDICTABILITY
AD-HOC LEAN
STARTUP
AGILELEAN/
AGILE
LOW TRUST
FULLY DECOUPLE
REDUCE BATCH SIZEBECOME PREDICTABLE
TEAMS
6969
AE
AC
PE
PC
EMERGENCE
CONVERGENCE
ADAPTABILITY
PREDICTABILITY
PHASE 1
AD-HOC LEAN
STARTUP
AGILELEAN/
AGILE
LOW TRUST
FULLY DECOUPLE
REDUCE BATCH SIZEBECOME PREDICTABLE
TEAMS
P1
7070
AE
AC
PE
PC
EMERGENCE
CONVERGENCE
ADAPTABILITY
PREDICTABILITY
PHASE 2
AD-HOC LEAN
STARTUP
AGILELEAN/
AGILE
LOW TRUST
FULLY DECOUPLE
REDUCE BATCH SIZEBECOME PREDICTABLE
TEAMS
P1
P2
7171
AE
AC
PE
PC
EMERGENCE
CONVERGENCE
ADAPTABILITY
PREDICTABILITY
PHASE 3
AD-HOC LEAN
STARTUP
AGILELEAN/
AGILE
LOW TRUST
FULLY DECOUPLE
REDUCE BATCH SIZEBECOME PREDICTABLE
TEAMS
P1
P2
P3
7272
AE
AC
PE
PC
EMERGENCE
CONVERGENCE
ADAPTABILITY
PREDICTABILITY
PHASE 4
AD-HOC LEAN
STARTUP
AGILELEAN/
AGILE
LOW TRUST
FULLY DECOUPLE
REDUCE BATCH SIZEBECOME PREDICTABLE
TEAMS
P1
P2
P3
P4
7373
AE
AC
PE
PC
EMERGENCE
CONVERGENCE
ADAPTABILITY
PREDICTABILITY
PHASE 5
AD-HOC LEAN
STARTUP
AGILELEAN/
AGILE
LOW TRUST
FULLY DECOUPLE
REDUCE BATCH SIZEBECOME PREDICTABLE
TEAMS
P1
P2
P3
P4
P5
W H E R E A R E W E
G O I N G ?
7575
METHODOLOGIES & FRAMEWORKS
Waterfall
Rational Unified Process (RUP)
DSDM
FDD
SAFe
DAD
LeSS
Nexus
Scrum
XP
Kanban
Crystal
Lean
Lean Startup
7676
LEAN/
AGILE
Waterfall
RUP
SAFe
DSDM
FDD
DAD
Nexus
LeSS
Scrum
XP
Crystal
LeanAE
AC
PE
PC
EMERGENCE
CONVERGENCE
ADAPTABILITY
PREDICTABILITY
AD-HOC LEAN
STARTUP
AGILE
H O W D O W E G E T
T H E R E ?
7878
DELIVERY
TEAMS
Scr um
7979
PROGRAM
TEAMS
DELIVERY
TEAMS
Scr um
Kanban
8080
PROGRAM
TEAMS
PORTFOLIO
TEAMS
DELIVERY
TEAMS
Scr um
Kanban
Kanban
I N C R E M E N T A L
T R A N S F O R M A T I O N
( E X P E D I T I O N S )
8282
PROGRAM
TEAMS
PORTFOLIO
TEAMS
DELIVERY
TEAMS
Scr um
Kanban
Kanban
AGILE PILOT
Increment One
8383
PROGRAM
TEAMS
PORTFOLIO
TEAMS
DELIVERY
TEAMS
Scr um
Kanban
Kanban
AGILE PILOT
Increment One
AGILE ROLLOUT
Increment Two
8484
PROGRAM
TEAMS
PORTFOLIO
TEAMS
DELIVERY
TEAMS
Scr um
Kanban
Kanban
AGILE PILOT
Increment One
AGILE ROLLOUT
Three - N
I T E R A T I V E
T R A N S F O R M A T I O N
( B A S E C A M P S )
8686
PROGRAM
TEAMS
PORTFOLIO
TEAMS
DELIVERY
TEAMS
Scr um
Kanban
Kanban
AGILE PILOT
Iteration One
8787
PROGRAM
TEAMS
PORTFOLIO
TEAMS
DELIVERY
TEAMS
Scr um
Kanban
Kanban
AGILE PILOT
Iteration Two
8888
PROGRAM
TEAMS
PORTFOLIO
TEAMS
DELIVERY
TEAMS
Scr um
Kanban
Kanban
AGILE PILOT
Iteration Three
8989
PROGRAM
TEAMS
PORTFOLIO
TEAMS
DELIVERY
TEAMS
Scr um
Kanban
Kanban
AGILE PILOT
Iteration Four
9090
PROGRAM
TEAMS
PORTFOLIO
TEAMS
DELIVERY
TEAMS
Scr um
Kanban
Kanban
AGILE PILOT
Iteration Five
E X P E D I T I O N S &
B A S E C A M P S
9292
PROGRAM
TEAMS
PORTFOLIO
TEAMS
DELIVERY
TEAMS
Scr um
Kanban
Kanban
AGILE PILOT
Iteration One
9393
PROGRAM
TEAMS
PORTFOLIO
TEAMS
DELIVERY
TEAMS
Scr um
Kanban
Kanban
AGILE PILOT
Iteration Two
9494
PROGRAM
TEAMS
PORTFOLIO
TEAMS
DELIVERY
TEAMS
Scr um
Kanban
Kanban
AGILE PILOT
Iteration Three
AGILE ROLLOUT
Iteration One
9595
PROGRAM
TEAMS
PORTFOLIO
TEAMS
DELIVERY
TEAMS
Scr um
Kanban
Kanban
AGILE PILOT
Iteration Four
AGILE ROLLOUT
Iteration Two
9696
PROGRAM
TEAMS
PORTFOLIO
TEAMS
DELIVERY
TEAMS
Scr um
Kanban
Kanban
AGILE PILOT
Iteration Five
AGILE ROLLOUT
Iteration Three
MANAGING CHANGE
AND MEASURING
PROGRESS
P L A N N I N G A N D
E X E C U T I O N
99
STEP ONE
WHY HOW WHAT
Agile transformation
isn’t something that can
be done to an
organization.
They have to be full
participants
Executive Steering
Committee
Transformation
Leadership Team
Holding the
organization
accountable
Remove Impediments
Plan the work
Review Progress
Inspect and Adapt
100
STEP TWO
WHY HOW WHAT
We have to have some
idea of where we are
going before we start
We will accept the plan
will change
Create a working
hypothesis for
structure, governance,
and metrics
Plan to progressively
elaborate
Transformation
Workshop
Pilot
Broad Organization
Rollout
Create Feedback Loops
101
STEP THREE
WHY HOW WHAT
We have to be able to
give the organization
some idea of what we
are doing, when, and
how long
Expeditions
Basecamps
Sequenced in Time
What teams are going
to be formed?
What training do they
need?
What coaching do they
need?
When will this all
happen?
102
STEP FOUR
WHY HOW WHAT
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.
103
STEP FIVE
WHY HOW WHAT
Very similar to a 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
104
STEP SIX
WHY HOW WHAT
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
105
STEP SEVEN
WHY HOW WHAT
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
106
STEP EIGHT
WHY HOW WHAT
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
107
STEP NINE
WHY HOW WHAT
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
108
STEP TEN
WHY HOW WHAT
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
M E A S U R I N G
P R O G R E S S
110110
PERFORMANCE METRICS
111111
DELIVERY
TEAMS
Scr um
Backlog Size
Velocity
Burndown
Escaped Defects
Commit %
Acceptance % Ratio
Scope Change
PERFORMANCE METRICS
112112
PROGRAM
TEAMS
DELIVERY
TEAMS
Scr um
Kanban
Backlog Size
Velocity
Burndown
Escaped Defects
Commit %
Acceptance % Ratio
Scope Change
Cycle Time
Features Blocked
Rework/Defects
PERFORMANCE METRICS
113113
PROGRAM
TEAMS
PORTFOLIO
TEAMS
DELIVERY
TEAMS
Scr um
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
PERFORMANCE METRICS
114114
TRANSFORMATION METRICS
Capabilities
Performance
115115
TRANSFORMATION METRICS
Capabilities
Performance
Metrics
Performance
116116
TRANSFORMATION METRICS
Capabilities
Performance
Metrics
Performance
Operations
Performance
A T A L E O F T W O
T R A N S F O R M A T I O N S
118118
TRANSFORMATIONS ARE UNIQUE
COMPAN Y ON E
• 3 Teams
• No Dependencies
• Low Resistance
• Team Level
• Adaptive-Emergent
• Single Expedition
• Lean Startup
• Low Coordination
• Low Metrics and Control
COMPAN Y TWO
• 800 Teams
• Tightly Coupled
• High Resistance
• Enterprise
• Predictive-Convergent
• Many Expeditions
• SAFe
• High Coordination
• High Metrics and Control
119119
mike@leadingagile.com
404-312-1471
www.leadingagile.com
twitter.com/mcottmeyer
facebook.com/leadingagile
linkedin.com/in/cottmeyer
MIKE COTTMEYER

Agile Transformation Explained