4. The Problem...
Having lots of agile teams in an
enterprise isn’t enterprise agility
• Sometimes organizations fall into the trap of
thinking that having agile teams means they
have an agile organization
• Enterprise agility is when all the parts of the
organization work together to create Agile
outcomes
• The entire delivery capability of the
enterprise has to be focused on agile
principles and execution
5. The Problem...
Focusing only at the team level can result
in local optima within your organization
• Sometimes a team can perform well at
Scrum, but the business doesn’t see any
incremental value from their investment
• Sometimes a high-performance team can
disrupt other functions in the organization if
the upstream and downstream processes are
not able to work at the same pace
6. The Problem...
Team level Agile practices are different
from Agile practices at scale
• The practices we put in place at the team
level often don’t work when we apply them in
larger organizations
• Practices have to adapted at scale to
accommodate more diverse groups of
stakeholders and more complicated value
streams
7. The Problem...
Agile at scale requires a broader set of
tools and techniques
• Scrum and XP at the team level
• Kanban and Lean at the program and
portfolio level
• RUP and Traditional Project Management at
the Enterprise
8. We are just now starting to
put all the pieces together...
10. The Solution... Part One
First... we do have to get team level agile right. We
are going to talk about some of the things you can
do that will lead to successful team-level Agile
transformations.
• The fundamentals behind why Agile works
• Common challenges that cause Agile to fail
• What does it look like when things are really
going well?
• What is different about an enterprise-level
Agile transformation?
11. The Solution... Part Two
Next we will explore a safe, pragmatic, iterative and
incremental framework for transforming any sized
organization...
• Define the organizational competencies
required at all levels of the enterprise
• How to adapt agile competencies for scale
• How to adapt agile competencies for cadence
12. The Solution... Part Three
We’ll discuss the three major areas you need to pay
attention to in order to execute a safe and
pragmatic enterprise Agile transformation...
• Establishing an agile org structure
• Introducing disciplined Agile practices
• Intentionally addressing people and culture
13. The Solution... Part Four
Finally, as we begin to wrap-up the talk, we’ll explore
a few things that will help you put all of this
together...
• Overview of the model end-to-end
• If we have time... case studies
16. What Makes Agile Work?
Teams stay together and are highly
engaged
• Agile practices are built around cross-
functional teams that have everything
necessary to deliver an increment of value to
the organization
• Teams that stay together over time tend to be
more productive than teams that are
constantly forming and reforming
• Empowered self-directed teams are able to
own the solution and creatively solve
17. What Makes Agile Work?
Teams are focused on a queue of projects
or product enhancements
• Rather than forming teams to deliver
projects, agile methods leave teams together
and funnel project through teams
• The project list is basically a prioritized
backlog of work that a team is responsible for
delivering
18. What Makes Agile Work?
Minimize dependencies and strive for
loose coupling between teams
• The more coupling we have between teams,
the more difficult it is to change direction
when we learn something new about the
emerging product
• Teams that have external dependencies are
not able to make and meet commitments
because they don’t have everything necessary
to own the commitment
19. What Makes Agile Work?
Fully engaged business partners
• Many organizations are guilty of throwing ill-
defined requirements over to the delivery
teams, constantly changing direction through
the life of the project, and holding teams
accountable for on-time delivery
• Agile is geared for change, but requires close
collaboration between stakeholders and
teams to make real-time tradeoffs as the
product is in development
20. What Makes Agile Work?
Attention to getting done and completing
work before new work is started
• Delivering an increment of working, tested,
potentially shippable software on regular time
intervals assures that we can measure
progress against real, measurable product
outcomes
21. What Makes Agile Work?
Technical excellence and continuous
attention to product quality
• The underlying health of the system is a
critical success factor for running successful
agile projects
• Defects and technical debt impact product
delivery in unpredictable ways making it
nearly impossible to reliably make and meet
commitments
23. What Makes Agile Fail?
Agile team is a local optimization and out
of alignment with the rest of the business
• Pilot teams are formed and given everything
they need to be successful at the expense of
the rest of the delivery organization
• Teams can deliver product faster than the
organization can consume it
• Teams starve the requirements queue because
Strategy and Product Management can’t keep
up
24. What Makes Agile Fail?
Project driven organizations or uneven
investment across product lines
• Very difficult to keep cross-functional teams
together over time because the investment
mix is constantly changing
• Organizations tend to want to matrix people
across multiple teams at the same time
25. What Makes Agile Fail?
Value is either too broadly defined or too
narrowly defined
• Overly vague requirements lead the
development team to fill in the gaps based in
their own knowledge and experience
• Overly specified requirements lead to an
activity based mentality rather than a value
based mentality
26. What Makes Agile Fail?
Organizational structures and product
architectures work against establishing
cross functional teams
• Matrix organizations and functional silos make
it very challenging to create high-performing
agile teams
• Tightly coupled legacy architectures make it
difficult to organize teams around feature
groups or components within the solution
framework
27. What Makes Agile Fail?
Overly political cultures and lack of trust
• Command and control leadership
• Micromanagement
• Disempowering language
28. What Makes Agile Fail?
Inability to balance capacity and demand
• Invalid and inaccurate estimates
• Inability to make and meet commitments
• More work than the teams can possibly
deliver in the timeframes expected
29. What Makes Agile Fail?
Looking at agile as a process overlay
rather than a transformative event in
your organization
• Agile is just something that the developers do
• Not recognizing the broad organizational
change necessary to make an agile
transformation sustainable
31. A Well Formed Agile Organization
Cross functional teams aligned directly to
solve business problems
• Products
• Features
• Programs
• Components
• Services
• Business Capabilities
32. A Well Formed Agile Organization
Clear voice of the business and a
willingness to make tradeoffs to meet
time and cost constraints
• Highly engaged product ownership
• Willingness to deal with reality
• Focus on maximizing value and reducing risk
33. A Well Formed Agile Organization
Individual empowerment and shared
accountability for outcomes
• Establish boundaries and ownership but
empower within those boundaries
• Teams own outcomes not activities
34. A Well Formed Agile Organization
Disciplined attention to technical
excellence and product quality
• Technical excellence stabilizes the
requirements delivery function
35. A Well Formed Agile Organization
Predictable, accountable, able to
consistently make and meet
commitments
• Teams have the ability to consistently do what
they say they are going to do
• Predictable agile teams are the foundational
element of a predictable agile enterprise
36. Reinventing Agile
Situationally specific strategies at scale to
solve these problems and maintain
business agility
• How do team level competencies need to be
adapted to take into consideration issues of
scale and the different planning horizons
required in larger enterprises
• How do you build the necessary organization,
introduce new practices, and start shifting the
culture in a way that leads to sustainable
organizational change
44. Product Definition
• Establish the product vision
• Define the product roadmap
• Decompose features
• Estimate size and effort
• Define acceptance criteria
45. Product Definition
• Establish the product vision
• Define the product roadmap
• Decompose features
• Estimate size and effort
• Define acceptance criteria
46. Product Definition
• Establish the product vision
• Define the product roadmap
• Decompose features
• Estimate size and effort
• Define acceptance criteria
47. Product Definition
• Establish the product vision
• Define the product roadmap
• Decompose features
• Estimate size and effort
• Define acceptance criteria
48. Product Definition
• Establish the product vision
• Define the product roadmap
• Decompose features
• Estimate size and effort
• Define acceptance criteria
49. Product Definition
• Establish the product vision
• Define the product roadmap
• Decompose features
• Estimate size and effort
• Define acceptance criteria
50. Delivery Practices
• Define the solution
• Build the solution
• Test the solution
• Establish product quality
• Deploy the solution
51. Delivery Practices
• Define the solution
• Build the solution
• Test the solution
• Establish product quality
• Deploy the solution
52. Delivery Practices
• Define the solution
• Build the solution
• Test the solution
• Establish product quality
• Deploy the solution
53. Delivery Practices
• Define the solution
• Build the solution
• Test the solution
• Establish product quality
• Deploy the solution
54. Delivery Practices
• Define the solution
• Build the solution
• Test the solution
• Establish product quality
• Deploy the solution
55. Delivery Practices
• Define the solution
• Build the solution
• Test the solution
• Establish product quality
• Deploy the solution
56. Planning & Coordination
• Establish a planning cadence
• Perform activity breakdown
• Establish a delivery cadence
• Limit work in process
• Make and meet commitments
57. Planning & Coordination
• Establish a planning cadence
• Perform activity breakdown
• Establish a delivery cadence
• Limit work in process
• Make and meet commitments
58. Planning & Coordination
• Establish a planning cadence
• Perform activity breakdown
• Establish a delivery cadence
• Limit work in process
• Make and meet commitments
59. Planning & Coordination
• Establish a planning cadence
• Perform activity breakdown
• Establish a delivery cadence
• Limit work in process
• Make and meet commitments
60. Planning & Coordination
• Establish a planning cadence
• Perform activity breakdown
• Establish a delivery cadence
• Limit work in process
• Make and meet commitments
61. Planning & Coordination
• Establish a planning cadence
• Perform activity breakdown
• Establish a delivery cadence
• Limit work in process
• Make and meet commitments
62. Continuous Improvement
• Metrics and reporting
• Establish stable velocity
• Conduct retrospectives
• Update the backlog
• Enable process improvement
63. Continuous Improvement
• Metrics and reporting
• Establish stable velocity
• Conduct retrospectives
• Update the backlog
• Enable process improvement
64. Continuous Improvement
• Metrics and reporting
• Establish stable velocity
• Conduct retrospectives
• Update the backlog
• Enable process improvement
65. Continuous Improvement
• Metrics and reporting
• Establish stable velocity
• Conduct retrospectives
• Update the backlog
• Enable process improvement
66. Continuous Improvement
• Metrics and reporting
• Establish stable velocity
• Conduct retrospectives
• Update the backlog
• Enable process improvement
67. Continuous Improvement
• Metrics and reporting
• Establish stable velocity
• Conduct retrospectives
• Update the backlog
• Enable process improvement
68. Organizational Enablement
• Establish teams
• Effective communication
• Effective collaboration
• Empowerment
• Trust
94. Adoption vs. Transformation
First... we want to untangle two words that
sometimes can be used interchangeably
• Agile Adoption is about what you do...
practices, tools, techniques, ceremonies, and
habits
• Agile Transformation is about who you
are... reflected in both the structure of the
organization and who you are as people
Long term results require both adoption and
transformation to be successful
95. Adoption vs. Transformation
Second... we want clearly articulate the three major
focus areas that must be addressed interdependently
• Organizational Structure is about how
you create teams and how you organize them
• Agile Practice is about the methods and
tools you choose to introduce
• People and Culture is about changing
hearts and minds of the individuals in the
organization
All three aspects are essential to sustain agility
96. Incremental vs. Iterative
Third... we want introduce the notion that introducing
Agile is an iterative and incremental process for you
organization
• Iterative is when parts of the system are
developed at different times and integrated as
they are completed
• Incremental is when you go back over parts
of the system making improvements
The strategy is to increment the organization by
building teams and iterate the teams over time
100. Adoption/Transformation Cycle
Incrementing and
Iterating the Agile
Enterprise
•
Organiza(onal+
Change physical Transforma(on+
structures and
introduce teams
• Teach people new
Personal+ Adopt++
practices and ways Transforma(on+ Prac(ces+
of working
• Help people
internalize the
value system
101. Adoption/Transformation Cycle
Organizational
Transformation
• Establish top to
Organiza(onal+
bottom structure Transforma(on+
and roadmap
• Incrementally make
changes and
Personal+ Adopt++
establish teams Transforma(on+ Prac(ces+
• Define policies
and working
agreements
between teams
102. Adoption/Transformation Cycle
Adopting Practices
•Sprint planning,
daily stand-ups,
Organiza(onal+
product reviews, Transforma(on+
and retrospectives
•Identify and train a
Product Owner
Personal+ Adopt++
and ScrumMaster Transforma(on+ Prac(ces+
•Teach TDD, CI,
Story Maps, and
MMF
103. Adoption/Transformation Cycle
Personal
Transformation
• Develop an ability
Organiza(onal+
to deal with Transforma(on+
uncertainty and
adaptation
• Help people work
Personal+ Adopt++
toward common Transforma(on+ Prac(ces+
organizational goals
• Help foster
empathy, trust, and
teamwork
104. Common Anti-Patterns
• Establishing teams without
breaking down the strict
functional silos and rigid role
definitions
• Running daily standup
meetings that devolve into
status updates for the project
manager
• Coming back from CSM
training only to find that there
is no way to form agile teams
and no interest in agile
105. Common Anti-Patterns
• Establishing teams without
breaking down the strict
functional silos and rigid role
definitions
• Running daily standup
meetings that devolve into
status updates for the project
manager
• Coming back from CSM
training only to find that there
is no way to form agile teams
and no interest in agile
106. Common Anti-Patterns
• Establishing teams without
breaking down the strict
functional silos and rigid role
definitions
• Running daily standup
meetings that devolve into
status updates for the project
manager
• Coming back from CSM
training only to find that there
is no way to form agile teams
and no interest in agile
107. Common Anti-Patterns
• Establishing teams without
breaking down the strict
functional silos and rigid role
definitions
• Running daily standup
meetings that devolve into
status updates for the project
manager
• Coming back from CSM
training only to find that there
is no way to form agile teams
and no interest in agile
111. Phase I - Structure
Product
Team
Scrum Scrum
Team Team
112. Phase 2 - Structure
Product
Team
Scrum Scrum Scrum
Team Team Team
113. Phase 2 - Structure
Product
Team
Scrum Scrum Scrum Scrum
Team Team Team Team
114. Phase 2 - Structure
Product Product
Team Team
Scrum Scrum Scrum Scrum
Team Team Team Team
115. Phase 3 - Structure
Portfolio
Team
Product Product
Team Team
Scrum Scrum Scrum Scrum
Team Team Team Team
116. Phase 3 - Structure
Strategy Portfolio
Team Team
Product Product
Team Team
Scrum Scrum Scrum Scrum
Team Team Team Team
117. Phase 3 - Structure
Strategy Portfolio
Support
Team Team
Product Product
Team Team
Scrum Scrum Scrum Scrum
Team Team Team Team
118. Organizationa
l
Transformatio
Value Delivery
Personal
Adopt
Transformatio
Practices
n
Phase I
Product Planning Delivery Continuous
Definition Coordination Practices Improvement
OrganizationalFactors
Cultural Enablement
116
119. Organizationa
l
Transformatio
Value Delivery
Personal
Adopt
Transformatio
Practices
n
Phase I
Product Planning Delivery Continuous
Definition Coordination Practices Improvement
Organizational Enablement
117
120. Organizationa
l
Transformatio
Value Delivery
Personal
Adopt
Transformatio
Practices
n
Phase I
Product Planning Delivery Continuous
Definition Coordination Practices Improvement
Organizational Enablement
118
121. Organizationa
l
Transformatio
Value Delivery
Personal
Adopt
Transformatio
Practices
n
Phase I
Product Planning Delivery Continuous
Definition Coordination Practices Improvement
Organizational Enablement
119
122. Organizationa
l
Transformatio
Value Delivery
Personal
Adopt
Transformatio
Practices
n
Phase 2
Product Planning Delivery Continuous
Definition Coordination Practices Improvement
Organizational Enablement
120
123. Organizationa
l
Transformatio
Value Delivery
Personal
Adopt
Transformatio
Practices
n
Phase 2
Product Planning Delivery Continuous
Definition Coordination Practices Improvement
Organizational Enablement
121
124. Organizationa
l
Transformatio
Value Delivery
Personal
Adopt
Transformatio
Practices
n
Phase 2
Product Planning Delivery Continuous
Definition Coordination Practices Improvement
Organizational Enablement
122
125. Organizationa
l
Transformatio
Value Delivery
Personal
Adopt
Transformatio
Practices
n
Phase 3
Product Planning Delivery Continuous
Definition Coordination Practices Improvement
Organizational Enablement
123
126. Organizationa
l
Transformatio
Value Delivery
Personal
Adopt
Transformatio
Practices
n
Phase 3
Product Planning Delivery Continuous
Definition Coordination Practices Improvement
Organizational Enablement
124
127. Organizationa
l
Transformatio
Value Delivery
Personal
Adopt
Transformatio
Practices
n
Phase 3
Product Planning Delivery Continuous
Definition Coordination Practices Improvement
Organizational Enablement
125
128. Organizationa
l
Transformatio
Value Delivery
Personal
Adopt
Transformatio
Practices
n
Phase 3
Product Planning Delivery Continuous
Definition Coordination Practices Improvement
Organizational Enablement
126
129. Phase I - Cadence
Strategic
Release
Iteration
Daily
Continuous
130. Phase I - Cadence
Strategic
Release
Iteration
Daily
Continuous
131. Phase I - Cadence
Strategic
Release
Iteration
Daily
Continuous
132. Phase I - Cadence
Strategic
Release
Iteration
Daily
Continuous
133. Phase I - Cadence
Strategic
Release
Iteration
Daily
Continuous
140. Single Team/Single Product
Sub 25 person product company and a
start-up
• Started with team level practices
• Lots of attention early to team culture
• Began engaging senior leaders on strategy and
portfolio management
• Currently integrating marketing, sales, and
support
141. Multi-Team/Single Product
Sub-100 person product company. 10
years old and privately owned.
• Program level first.. established a PO team
• 3 tightly integrated Scrum teams
• Defined the portfolio governance layer
• Established the relationship between strategy
and support
• Modeled the overall value stream and wrapped
the Scrum process in a two-tiered Kanban
142. Multi-Team/Multi-Product
Sub-300 person organization. 100 person
development organization. 8 Scrum
teams.
• Big-bang team-level adoption
• Teams aligned by products
• Product ownership by product
• Program and portfolio level views established
• Limiting projects in progress
• Solid release planning
• Integration with upstream and downstream
143. Multi-Team/Multi-Product
Large multi-national organization. Scope
is a 500 person development organization
with 55 Scrum teams.
• Started with a basic view of the portfolio layer
• Portfolio level value stream mapping, RACI
• Built out the program management layer with
PO teams to develop a requirements
management capability
• Program level value stream mapping, RACI,
introduced agile tooling
• Introduced Scrum at the team level
144. Products of Products
Large multi-national company.
Geographically dispersed. Products of
products.
• Scrum teams by product/component
• Product Owner teams established
• Portfolio level governance model
• Lean/TOC planning model
• Integration with a traditional PMO for metrics
and reporting
A little about me... my background.. why Agile is important\nStudied computer science... spent first 10 years doing infrastructure\nInfrastructure PM to software PM... close the loop\nStarting seeing a lot of organizational dysfunction... things that just didn’t make sense\nStarted consulting with V1... saw similar patterns repeated across the world\nLeft V1 to start developing my approach to transformation and help companies make lasting sustainable change\n\n\n
I want to explore a little the problem that I’m seeing. People get agile... to a large extent agile has gone mainstream. When I’m doing business development with a client, I don’t usually have to explain agile or convince people that agile is the way to do things. Often what I’m selling against is an oversimplification of agile... or a belief that the stuff we are doing with team level Scrum is sufficient for Agile at scale or agile in the enterprise\n
\n
\n
Examples:\n\n\n\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Talk about scales\n1 bad 5 good\n1 non-existent 5 sustainable\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Better Estimation & Release Planning\n
Better Estimation & Release Planning\n
Better Estimation & Release Planning\n
Better Estimation & Release Planning\n
Better Estimation & Release Planning\n
Better Estimation & Release Planning\n
Better Estimation & Release Planning\n
Better Estimation & Release Planning\n
Better Estimation & Release Planning\n
Better Estimation & Release Planning\n
Better Estimation & Release Planning\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Mobile Labs\n
Lancope\n\n
Surescripts & nCircle\n\n
Verint\n\n
CheckFree/Fiserv\n
\n
\n
A little about me... my background.. why Agile is important\nStudied computer science... spent first 10 years doing infrastructure\nInfrastructure PM to software PM... close the loop\nStarting seeing a lot of organizational dysfunction... things that just didn’t make sense\nStarted consulting with V1... saw similar patterns repeated across the world\nLeft V1 to start developing my approach to transformation and help companies make lasting sustainable change\n\n\n