Scrum has proven to be a successful framework for many companies in complex delivery domains to transition to Agility from more traditional delivery methods.
At some point during these transitions many companies have experienced a stall to what have previously been ongoing and exponential improvements. While team-level performance might have seen a substantial improvement, end-to-end delivery as perceived by customers and other stakeholders may not bit fit enough. In other cases, no matter how much teams work within the Scrum framework to improve their work, recurring “impediments” cause the Scrum implementation to plateau, or even regress.
We have learnt that complexity brings with it challenges in the "white spaces" that exist between teams where local improvements become disconnected from the delivery of customer value. In essence, Scrum is good, but doesn't provide enough to meet the needs of the whole system.
This talk will summarize key lessons distilled from that realization. We will highlight some of the limitations of team-centric Agile approaches and discuss Lean & Systems Thinking concepts to improve the system as a whole and bring your organization back to a place of continuous improvement that is connected to customer value.
Strategies for Landing an Oracle DBA Job as a Fresher
Amp up your agile tac 2017
1. Amp up your Agile implementation in complex
environments with Systems Thinking
@martinaziz@fer_cuenca
Fernando A. Cuenca Martin Aziz
fernando.a.cuenca@gmail.com martinaziz@gmail.com
Toronto Agile
Conference
2017
8. Teams and the local agenda
Number
of Teams
Tribal
Behaviour
+
Local
Improvement
Effort
Complexity
of Problem
+
+
Causal
Loop
Part 3
9. Where is my
stuff?
What am I
going to get
at the end?
Why does it
take this long?
Seems to work
for me….
6
End to End Measurement for
Fitness
The
Company
10. How does this impact Lead Time and Fitness
for Customer Purpose?
Lead Time
Fit for
Purpose
-
Number
of Teams
Tribal
Behaviour
+
Local
Improvement
Effort
Complexity
of Problem
+
+
?
Causal
Loop
Part 4
t
11. Comes from
different sources
Comes in different types,
requiring different
processing
It has different
frequencies of
arrival
It has different
levels of urgency,
Importance, and
cost of delay It has different
perceived value
Cost of Delay and Heterogeneous
demand
The
Company
15. The impact of Teams & Overburdening on
Flow Efficiency
Number
of
Teams
Tribal
Behavio
ur
+
+
Flow
Efficiency
-
Local
Improvement
Effort
Lead
Time
Fit for
Purpose
-
Implicitness of
Commitment
Point
Distance
between Teams &
Commitment
Point
Overburdening
+
Complexity
of Problem
Coordination
effort +
White Space
+
+
+
-
-
Causal
Loop
Part 6
Wait Wait Wait WaitWork Work Work Work
Flow Efficiency =
work time
work time + wait time
x 100%
17. Some stay the
same
Some are re-
aggregated and
batchedSome describe
business
functionality
Some are purely
technical tasks
Some have
internal
dependencies
Some are sent
to other team’s
backlogs
11
Recognizability and Transaction
Costs
The
Company
18. The impact of batch size on lead time
Number of
Teams
Tribal
Behaviour
+
+
Flow
Efficiency
-
Local
Improvement
Effort
Lead Time
Fit for
Purpose
-
Implicitness of
Commitment
Point
Distance
between Teams &
Commitment
Point
Overburdening
+
Complexity
of Problem
Coordination
effort +
White Space
+
+
+
-
-
Batch Size
+
+
Transaction
Cost
+
Causal
Loop
Part 7
20. Decomposition and Customer Recognizability, the final links
Number
of Teams
Tribal
Behaviour
+
+
Decomposition
+
Customer
Recognizability
Flow
Efficiency
-
Batch Size
Local
Improvement
Effort
+
+
Lead
Time
Fit for
Purpose
-
Implicitness of
Commitment
Point
Distance
between Teams &
Commitment
Point
+
Overburdening
-
+
Complexity
of Problem
Coordination
effort +
White Space
+
-
-
+
+
+
+
+
+
-
+
Transaction
Cost
-
Causal
Loop
Part 8
22. Constraining the work
Number
of Teams
Tribal
Behaviour
+
+
Decomposition
+
Customer
Recognizability
Flow
Efficiency
-
Batch Size
Local
Improvement
Effort
+
+
Lead
Time
Fit for
Purpose
-
Implicitness of
Commitment
Point
Distance
between Teams &
Commitment
Point
+
Overburdening
-
+
Complexity
of Problem
Coordination
effort +
White Space
+
-
-
+
+
+
+
+
+
-
+
Transaction
Cost
-
Constraints
- -
Breaking
the loop
23. Making commitments explicit
Number
of Teams
Tribal
Behaviour
+
+
Decomposition
+
Customer
Recognizability
Flow
Efficiency
-
Batch Size
Local
Improvement
Effort
+
+
Lead
Time
Fit for
Purpose
-
Implicitness of
Commitment
Point
Distance
between Teams &
Commitment
Point
+
Overburdening
-
+
Complexity
of Problem
Coordination
effort +
White Space
+
-
-
+
+
+
+
+
-
+
Transaction
Cost
-
Constraints
- -
Explicit
Commitment
-
Breaking
the loop
24. Know your delivery capability and implement Pull
Number
of Teams
Tribal
Behaviour
+
+
Decomposition
+
Customer
Recognizability
Flow
Efficiency
-
Batch Size
Local
Improvement
Effort
+
+
Lead
Time
Fit for
Purpose
-
Implicitness of
Commitment
Point
Distance
between Teams &
Commitment
Point
+
Overburdening
-
+
Complexity
of Problem
Coordination
effort +
White Space
+
-
-
+
+
+
+
+
-
+
Transaction
Cost
-
Constraints
- -
Explicit
Commitment
-
Pull
Policies
Measurement
-
-
Breaking
the loop
25. See your world as a service to a customer. Maintain customer
recognizability at all times.
Number
of Teams
Tribal
Behaviour
+
+
Decomposition
+
Customer
Recognizability
Flow
Efficiency
-
Batch Size
Local
Improvement
Effort
+
+
Lead
Time
Fit for
Purpose
-
Implicitness of
Commitment
Point
Distance
between Teams &
Commitment
Point
+
Overburdening
-
+
Complexity
of Problem
Coordination
effort +
White Space
+
-
-
+
+
+
+
+
-
+
Transaction
Cost
-
Constraints
- -
Explicit
Commitment
-
Pull
Policies
Measurement
-
-
Service
Orientation
+
Breaking
the loop
26. Flow – getting to a system that is in control
Sense
Pull
Features
Features
Do Next
Ideas
CustomersDelivery
Customers
Features
Do
Features
Good Constrained delivery
pipeline
Upstream Downstream
Progress Customer
Recognizable
Delivery Improvements
aligned to optimize for
value delivery
Work is pulled into delivery
pipe automatically as
capacity becomes
available. Push is avoided
to prevent overburdening.
A new
system
27. 0. Understand the purpose of the System and identify Services
1. Understand Sources of Dissatisfaction
2. Analyze Demand and Capability
3. Model the Knowledge Discovery Knowledge
4. Discover Classes of Service
5 . Design Kanban Systems
6. Roll-out
One way to get there: STATIK
the Systems Thinking Approach to Introducing Kanban
A new
system
1. Who are my
customers?
2. What do they
expect?
3. How do I meet those
expectations?
28. Kanban at the System Level
A new
system
Service 1
Service 2
Service 3
Discovery
(N)
Construction
(N)
Deployment
(N)
Commitment
Points
Upstream Flow
Downstream
Flows
Constraints to
enable PULL
Validation
(N)
Different
visualization
fidelity
29. Learning
More Some resources that have influenced us
Antifragile: Things That
Gain from Disorder
Nassim Nicholas Taleb
Kanban from the Inside
Mike Burrows
The Principles of Product
Development Flow
Donald G. Reinersten
Lessons in Agile
Management: On the
Road to Kanban
David J. Anderson
Goal: A Process of
Continuous
Improvement
Eli Goldratt
Management 3.0
Jurgen Appelo
Toyota KATA
Mike Rother
Actionable Agile Metrics
for Predictability
Daniel S. Vacanti
30. Learning
More Some people that have influenced us
David J. Anderson (LKU,
Kanban)
leankanban.com/blog
Alexei Zheglov (Kanban)
connected-knowledge.com
Patrick Steyaert (Flow)
www.okaloa.com
Chris Chapman
(#SystemsThinkingTO)
@DerailleurAgile
Esther Derby (Agile
Management)
www.estherderby.com/category
/insights
Dave Snowden (Cynefin)
cognitive-edge.com/blog
31. About us How to reach us to keep the conversation going