27. Teams
Backlog
Backlog
Backlog
Backlog
Working
Tested
Software
Why Are They Important?
Clarity Accountability Measureable
Progress
• People have
clarity around
what to build
• People
understand
how it maps to
the big picture
• Teams can be
held
accountable
for delivery
• No
indeterminate
work piling up
at the end of
the project
• 90% done,
90% left to do
28. Teams
Backlog
Backlog
Backlog
Backlog
Working
Tested
Software
Why Are They Important?
Clarity Accountability Measureable
Progress
• People have
clarity around
what to build
• People
understand
how it maps to
the big picture
• Teams can be
held
accountable
for delivery
• No
indeterminate
work piling up
at the end of
the project
• 90% done,
90% left to do
29. Teams
Backlog
Backlog
Backlog
Backlog
Working
Tested
Software
Why Are They Important?
Clarity Accountability Measureable
Progress
• People have
clarity around
what to build
• People
understand
how it maps to
the big picture
• Teams can be
held
accountable
for delivery
• No
indeterminate
work piling up
at the end of
the project
• 90% done,
90% left to do
30. Teams
Backlog
Backlog
Backlog
Backlog
Working
Tested
Software
Why Are They Important?
Clarity Accountability Measureable
Progress
• People have
clarity around
what to build
• People
understand
how it maps to
the big picture
• Teams can be
held
accountable
for delivery
• No
indeterminate
work piling up
at the end of
the project
• 90% done,
90% left to do
31. Teams
Backlog
Backlog
Backlog
Backlog
Working
Tested
Software
Why Are They Important?
Purpose Autonomy Mastery
• Understanding
the backlog
gives meaning
to work
• 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
32. Teams
Backlog
Backlog
Backlog
Backlog
Working
Tested
Software
Why Are They Important?
Purpose Autonomy Mastery
• Understanding
the backlog
gives meaning
to work
• 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
33. Teams
Backlog
Backlog
Backlog
Backlog
Working
Tested
Software
Why Are They Important?
Purpose Autonomy Mastery
• Understanding
the backlog
gives meaning
to work
• 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
34. Teams
Backlog
Backlog
Backlog
Backlog
Working
Tested
Software
Why Are They Important?
Purpose Autonomy Mastery
• Understanding
the backlog
gives meaning
to work
• 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
35. 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?
36. 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?
37. 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?
38. 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?
39. Teams
Backlog
Backlog
Backlog
Backlog
Working
Tested
Software
What Gets in the Way?
Business
Dependencies
Organizational
Dependencies
Technical
Dependencies
• Requirements
management
• Process flow
• Value streams
• Bottlenecks
• Too much in
process work
• Matrixed
Organizations
• Non instantly
available
resources
• Lack of SME
• Technical
Debt
• Defects
• Tight Coupling
• Low Cohesion
40. Teams
Backlog
Backlog
Backlog
Backlog
Working
Tested
Software
What Gets in the Way?
Business
Dependencies
Organizational
Dependencies
Technical
Dependencies
• Requirements
management
• Process flow
• Value streams
• Bottlenecks
• Too much in
process work
• Matrixed
Organizations
• Non instantly
available
resources
• Lack of SME
• Technical
Debt
• Defects
• Tight Coupling
• Low Cohesion
41. Teams
Backlog
Backlog
Backlog
Backlog
Working
Tested
Software
What Gets in the Way?
Business
Dependencies
Organizational
Dependencies
Technical
Dependencies
• Requirements
management
• Process flow
• Value streams
• Bottlenecks
• Too much in
process work
• Matrixed
Organizations
• Non instantly
available
resources
• Lack of SME
• Technical
Debt
• Defects
• Tight Coupling
• Low Cohesion
42. Teams
Backlog
Backlog
Backlog
Backlog
Working
Tested
Software
What Gets in the Way?
Business
Dependencies
Organizational
Dependencies
Technical
Dependencies
• Requirements
management
• Process flow
• Value streams
• Bottlenecks
• Too much in
process work
• Matrixed
Organizations
• Non instantly
available
resources
• Lack of SME
• Technical
Debt
• Defects
• Tight Coupling
• Low Cohesion
49. 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
50. 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
51. 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
52. Teams
Backlog
Backlog
Backlog
Backlog
Working
Tested
Software
How Do I Need to Change?
• Known and
knowable
requirements
• How to deal
with
unknowns
• Estimating
• Fungible
resources
• Individual
utilization
• Productivity
metrics
• Activity over
outcome
Defining
Work
Allocating
People
Measuring
Progress
53. Teams
Backlog
Backlog
Backlog
Backlog
Working
Tested
Software
How Do I Need to Change?
• Known and
knowable
requirements
• How to deal
with
unknowns
• Estimating
• Fungible
resources
• Individual
utilization
• Productivity
metrics
• Activity over
outcome
Defining
Work
Allocating
People
Measuring
Progress
54. Teams
Backlog
Backlog
Backlog
Backlog
Working
Tested
Software
How Do I Need to Change?
• Known and
knowable
requirements
• How to deal
with
unknowns
• Estimating
• Fungible
resources
• Individual
utilization
• Productivity
metrics
• Activity over
outcome
Defining
Work
Allocating
People
Measuring
Progress
55. Teams
Backlog
Backlog
Backlog
Backlog
Working
Tested
Software
How Do I Need to Change?
• Known and
knowable
requirements
• How to deal
with
unknowns
• Estimating
• Fungible
resources
• Individual
utilization
• Productivity
metrics
• Activity over
outcome
Defining
Work
Allocating
People
Measuring
Progress
57. A Theory of Transformation
Agile is about forming teams,
building backlogs, and
regularly producing
increments of working tested
software
58. A Theory of Transformation
Agile at scale is about
defining structure,
establishing governance, and
creating a metrics and tooling
strategy that supports agility
59. A Theory of Transformation
Anything that gets in the way
of forming teams, building
backlogs, and producing
working tested software is an
impediment to transformation
75. THE THREE THINGS
You Need to Know to Transform Any Sized
Organization into an Agile Enterprise
Editor's Notes
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.
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
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.
