Leading a large-scale agile transformation isn’t about adopting a new set of attitudes, processes, and behaviors at the team level… it’s about helping your company deliver faster to market, and developing the ability to respond to a rapidly changing competitive landscape. First and foremost, it’s about achieving business agility. Business agility comes from people having clarity of purpose, a willingness to be held accountable, and the ability to achieve measurable outcomes. Unfortunately, almost everything in modern organizations gets in the way of teams acting with any sort of autonomy. In most companies, achieving business agility requires significant organizational change.
Agile transformation necessitates a fundamental rethinking of how your company organizes for delivery, how it delivers value to its customers, and how it plans and measures outcomes. Agile transformation is about building enabling structures, aligning the flow of work, and measuring for outcomes-based progress. It’s about breaking dependencies. The reality is that this kind of change can only be led from the top. This talk will explore how executives can define an idealized end-state for the transformation, build a fiscally responsible iterative and incremental plan to realize that end-state, as well as techniques for tracking progress and managing change.
5. 5
GOALS OF GOING AGILE
PREDICTABILITY
Agile tends to focus on adaptability but
predictability is most often cited as the reason for
agile transformation
6. 6
GOALS OF GOING AGILE
PREDICTABILITY
Agile tends to focus on adaptability but
predictability is most often cited as the reason for
agile transformation
QUALITY
As organizations scale, product quality often suffers.
Agile focuses on quality from requirements through
implementation.
7. 7
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
QUALITY
As organizations scale, product quality often suffers.
Agile focuses on quality from requirements through
implementation.
8. 8
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
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
9. 9
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 the 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
10. 10
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 the 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.
13. 13
CULTURE FOCUSED
Focused on changing hearts
and minds
Focused on being agile rather
than doing agile
Focused on values and
principles
14. 14
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
15. 15
PRACTICES FOCUSED
Focused on the things
that you do
Focused on roles,
ceremonies, and artifacts
Can be management
driven or technically
driven
16. 16
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
17. 17
SYSTEMS FOCUSED
Focused on forming
teams and governing the
flow of value
Focused on aligning the
organization first
18. 18
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
19. 19
... all three are essential,
but where you start
is also essential…
22. 22
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
29. 29
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
30. 30
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
31. 31
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
32. 32
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
33. 33
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
34. 34
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
35. 35
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
36. 36
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
37. 37
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
38. 38
WHAT DO THEY LOOK LIKE AT SCALE?
• 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?
Metrics & ToolsStructureGovernance
39. 39
WHAT DO THEY LOOK LIKE AT SCALE?
• 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?
Metrics & ToolsStructureGovernance
40. 40
WHAT DO THEY LOOK LIKE AT SCALE?
• 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?
Metrics & ToolsStructureGovernance
59. THEORY OF TRANSFORMATION //
Adopting agile is about forming
teams, building backlogs, and
regularly producing increments of
working tested software
60. THEORY OF TRANSFORMATION //
Adopting agile at scale is about
defining structure, establishing
governance, and creating a
metrics and tooling strategy that
supports agility
61. THEORY OF TRANSFORMATION //
Anything that gets in the way of
forming teams, building backlogs,
and producing working tested
software is an impediment to
transformation
62. THEORY OF TRANSFORMATION //
Solid agile practices will help
operationalize the system and
encourage a healthy, adaptive,
and empowered culture emerge
over time
91. 91
Services Teams – These teams support common
services across product lines. These teams support
the needs of the product teams.
92. 92
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.
93. 93
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.
94. 94
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.
100. 100
4-TIER GOVERNANCE
MAKE
READY
STORY READY IN PROGRESS
STORY
DONE
STORY
ACCEPTED
EPIC
ALIGNMENT
EPIC
PRIORITIZATION
SOLUTION
VALIDATION
RELEASE
TARGETING
IN PROGRESS EPIC VALIDATION COMPLETED
PORTFOLIO
TEAM
PROGRAM
TEAM
DELIVERY
TEAM
STRATEGIC ALIGNMENT SOLUTION VISION DEMAND PLANNING EXECUTION VALIDATION ACCEPTED
DEMAND PLANNING EXECUTION & ACCOUNTABILITY
FEATURE
DEFINITION
STORY MAPPING
RELEASE
PLANNING
IN PROGRESS
INTEGRATION
VALIDATION
FEATURE
DEPLOYMENT
FEATURE
COMPLETED
INTAKE
INVESTMENT
DECISION
INVESTMENT
TARGETING
IN PROGRESS
INITIATIVE
VALIDATION
COMPLETED
INITIATIVE DEFINITION INITIATIVE ROADMAP MEASUREABLE PROGRESS
INVESTMENT
I n it ia t iv e | K a n b a n
E p ic | K a n b a n
F e a t u r e | K a n b a n
S t o r y | S c r u m
105. 105
Takt Time/ Cycle Time
Time/Cost/Scope/Value
ROI/Capitalization
PROGRAM
TEAMS
PORTFOLIO
TEAMS
DELIVERY
TEAMS
Scrum
Kanban
Kanban
Backlog Size
Velocity
Burndown
Escaped Defects
Commit %
Acceptance % Ratio
Scope Change
Cycle Time
Features Blocked
Rework/Defects
106. 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
123. 123
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
124. 124
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
125. 125
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?
126. 126
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.
127. 127
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
128. 128
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
129. 129
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
130. 130
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
131. 131
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
132. 132
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
133. A T H E O R Y O F
T R A N S F O R M A T I O N
134. THEORY OF TRANSFORMATION //
Adopting agile is about forming
teams, building backlogs, and
regularly producing increments of
working tested software
135. THEORY OF TRANSFORMATION //
Adopting agile at scale is about
defining structure, establishing
governance, and creating a
metrics and tooling strategy that
supports agility
136. THEORY OF TRANSFORMATION //
Anything that gets in the way of
forming teams, building backlogs,
and producing working tested
software is an impediment to
transformation
137. THEORY OF TRANSFORMATION //
Solid agile practices will help
operationalize the system and
encourage a healthy, adaptive,
and empowered culture emerge
over time
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.
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.
This graphic shows an overall delivery and organization structure and approach for an agile enterprise.
Walk through each of these sections with class attendees and discuss the phases and steps involved, starting with the portfolio teams’ decisions around investment prioritization, demand validation, release feasibility analysis and planning, through to development and production.
By starting at the top left and working your way through the graphic, you should be able to hit each of the critical steps along the way that matter to an enterprise.
Since this is a Fundamentals class, you don’t need to dive into each of the steps in detail. Rather, the point to be made here is that there is a way to structure an enterprise to be agile in its’ planning and delivery.
This graphic shows an overall delivery and organization structure and approach for an agile enterprise.
Walk through each of these sections with class attendees and discuss the phases and steps involved, starting with the portfolio teams’ decisions around investment prioritization, demand validation, release feasibility analysis and planning, through to development and production.
By starting at the top left and working your way through the graphic, you should be able to hit each of the critical steps along the way that matter to an enterprise.
Since this is a Fundamentals class, you don’t need to dive into each of the steps in detail. Rather, the point to be made here is that there is a way to structure an enterprise to be agile in its’ planning and delivery.