Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Commitments and Energies in a Kanban System

Session for Lean Kanban Benelux 2011

Yuval Yeret

on 12 October 2017

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Commitments and Energies in a Kanban System

Effective and Energized on time delivery in flow environments
- How can we commit and

- What are the emerging properties of
Meeting Commitments in a Flow Environment
So now... lets talk about Energies
Does Flow mean no commitment?
Commitment Types in the Portfolio
So what does Kanban have to say about Commitments and Predictability?
Differences mainly in
INTERNAL commitment
Commit to Sprint Scope
(* in Scrum Guide 2011 changed to Forecast...)
Commit to deliver in a predictable and
improving throughput and latency
Bigger Projects Commitment
Estimation by Work Type / Class of Service Context
Fixed Price Feature
Fixed Date Feature
Production Defect
Fixed Date Project
Dev Env Improvement
IT Support Case
Regulatory Req
Technical Rewrite
Credit: Henrik Kniberg
Fixed Price deliveries to a banking project
Enterprise Component Released yearly within a Portfolio
New Platform with deliveries and dependencies to/from Legacy
B2B E-Commerce Platform
Recommended Resources on Estimation
Arlo Belshee on Naked Planning
Fixed Date Delivery
Try to limit the amount of fixed date work in your system
Think about your weekly calendar...
Urgent meeting to discuss client impediment
Client wants more time at short notice
Replace sick co-coach in important activity
Non-fixed Date work is slack that buffers variability
without it - you should take more safety time buffers
Never commit early unless you know why - Real Options
Why is this even an issue?
Can have some undesirable effects...
In product development ... we must also control the expansion of work. Some work in product development can behave like the perfect gas of physics. It expands to fill the container, no matter what size of the container.
Reinertsen refering to Parkinson's Law
So what happens when there ISN'T a completion time?
Road Runner
Finish tasks as quickly as possible, keeping local lead times fast
Then look for another task to perform
When does the Runner stop running?
What do you think happens in front of a bottleneck?
credit: http://www.flickr.com/photos/gifake/4741054861/
We overdo things
credit: http://www.flickr.com/photos/slidesf/2648616262
In order to learn a bit more...
Lets look at some environments where
I've seen pull work with great energies
Scrum teams keeping their Cadence
Highly collaborative relationship with those feeding the system, with granular and clear work
Teams under SLA - Support, IT Ops, etc.
Clear Business Goal - Unnegotiable Release Date
When you are highly connected to the business goals - and everyone is thinking max business outcome with min effort
Seeing / Visualizing
Visibility Patterns
Kanban boards are stateless. Snapshots. By default they don't show movement/energy
So how can we visualize movement?
Struggling/Slowed Down
Identifying Blocked work
Flags provide movement info even on a snapshot
In-flight Cycle Time Analysis
Zombie Cycle Times
W20: The Expansion Control Principle: Prevent uncontrolled expansion of work
Reinertsen on Flow
Photo and Video Credit: Yuval Yeret
Visualizing Overall Movement
Throughput/Velocity/Average Cycle Times
What do you see here?
Setup explicit process policies that aim to bring struggling work in
Context-Specific Definition of Done
Granular work benefits:
Clear Small Scope Container
Better testability
Reduce Variability and Complexity of Integration
Risk Mitigation via Earlier awareness to problems
Focus on key issues
So learn to drive more
granular work:
User Stories
(From Lean Startups)
"Implementing an application by describing its behaviour using well-defined outputs ... resulting in the delivery of working, tested
Overdoing it?
Unnecessary tests
Bells and Whistles
Refactoring to death
Not all work requires the same treatment!
Try... Discuss and clarify the treatment for each work item
- Software that Matters
Dan North, ThoughtWorks
Also look at
Acceptance-Test Driven Development
“Testing was always like a pillow it took whatever space was left. We used to have a cap on testing because there was a deadline...

...Now with the new Flow mode the inmates are running the asylum [and we have no cap on how long testing takes]”

A worried Dev Manager
Effective Routing Policies
Classes of Treatment
What can we do that can help you be more effective?
Improve Dev DoD!
More Unit Testing
Acceptance Tests Automated
Debugging Hooks
Error Reporting Clarity
No DOA builds (run smoke test)
Drive from Testing
Automation Framework
Simulator for complex online integration
Subordination Cards
Use slack on non-bottleneck to improve capacity/capability and reduce variability on bottleneck
No Testing Needed
Dev pull when Test queue full
Taking network congestion into pull preferences - prefer work that can route around congestion
Get better economic results by
You don't have to start with all countermeasures "Just in Case"
How to start?
Challenging your comfort zone
Twitter: @YuvalYeret
Mail: yuval@agilesparks.com
Blog: yuvalyeret.com
Feedback, Suggestions, questions:
Energizing technology delivery organizations in Israel and Worldwide...
So... how do we know what is our energy level?
Subordinate To
Prevent Intertia
"F24: The principle of Alternate Routes: Develop and maintain alternate routes around points of congestion."
Tailored Routing
Who says all work has to take the same route?
When congested, can change routes to reduce iterations and variability on bottleneck
Example: Who goes first?
Testing or Product Demo?
Intelligent Routing
Unsustainable Pace
Don't eliminate "good" Variability
Go read Reinertsen. And then make sure your energizing measures don't kill off more variability than you want it to
Don't assume the worst
Apply energizing countermeasures in case low energies are apparent
Sometimes the side trip is worth more
Tool/Policies help
But remember its all about People
Visualize the work
But don't need to go fancy just yet...
Create granular work containers
Choose Cadence or other soft time containers
Working from Behaviour / Acceptance tests seems to work great!
Have a basic definition of how you work
Explicit Policies / Standard Work
Keep your eyes open and Go See, Learn, Experiment, Adapt
Non Fixed Date Projects can be safety buffers for Fixed Date Projects
But this requires flexibility + versatility...
Estimating is an economic decision. What is the tradeoff between the cost and value of the information you buy. Karl J Scotland
When isn't this "Continuous Roadmap" enough?
What if for some features this is not fast enough?
When release cost is significant, it skews cycle times enough to matter.
Beware the dangers of Timeboxed Commitments
Customer Requirements Signoff Process
Analysis - Development Gap
Delivering to a non-Agile client,
using Fixed Price signed off Features
And Now?
Uber-Slicing Mode
Stop/Continue Forum
Involve the expert
Say we somehow provide focus and clarity...
Production >> Potentially Shippable >> Demo >> Nothing
Reminder: Timeboxes can be dangerous as well...
with timeboxes as opportunities to re-evaluate where you are
What if we need to commit on a large project?
Size Estimate
Dark Matter / Scope Creep
Due Date
Act - Do Something!
OK - Cruise Control
Scope Buffer
Watch and Plan - Defensive Management
Estimation Effort
Fixed Price Feature
Fixed Date Feature
Production Defect
Fixed Date Project
Dev Env Improvement
IT Support Case
Regulatory Req
Technical Rewrite
(optional) project buffer
Anecdote: Demos creating "too much" energy and synchronization
The Hurry-Up-and-Wait Principle
Large queues make it hard to create urgency
D. Reinertsen
Why is seeing it so important?
Focus on late tasks - Counteract the Amplification Principle
The more a task is late, the more we will neglect it / procrastinate
Encourage Whole Team attention/swarming
without visibility each person on his own
Specification by Example
... an example of Classes of Treatment
Main source of feedback?
Note: Pulling more people to late work requires versatility...
What about Mr Brooks?
Within a single team maintaining versatility, most work can be accelerated if necessary while sacrificing efficiency
For long projects, with early warning, there might be time to add even new people...
What about our friend again?
Too late to add new...
Brooks was right...

But swarming can
work assuming
healthy architecture
and eng practices...
Still time to add new people...
(depending on total project length)
not necessarily a cut-off point for all work
Slicing and Dicing
So do we or don't we want a
Time Container
For most work types, we should have some expectation as to the cycle time. Lets use that to create at least a "Soft/Virtual" time container.
and for work where we have no idea - lets use pre-emption to keep checking we are on the way
Energizing the Work
Clear Scope Containers
Giving the Road Runner the right directions
Bottleneck Routing
Still, it sometimes works...

Another example: Local Optimization of Risk Based Testing
Deliver on Time
Energized Kanban/Flow

Twitter: @YuvalYeret
Full transcript