Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

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.

DeleteCancel

Commitments and Energies in a Kanban System

Session for Lean Kanban Benelux 2011
by

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
Scrum
Commit to Sprint Scope
(* in Scrum Guide 2011 changed to Forecast...)
Kanban
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
Roadmap
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
http://agilemanagement.net/index.php/Blog/stop_estimating
http://www.agilemanagement.net/index.php/Blog/Agile_Estimating
Recommended Resources on Estimation
http://aaron.sanders.name/agile/naked-planning-explained-kanban-in-the-small
http://epistemologic.com/2007/05/12/estimation-considered-harmful/
http://agiletoolkit.libsyn.com/index.php?post_id=400364
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?
Pull
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?
http://www.flickr.com/photos/chryslergroup/5809560730/sizes/l/in/photostream/
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?
LCD
http://yuvalyeret.com/2011/02/16/the-agile-lowest-common-denominator-avoiding-a-slowdown-due-to-the-weakest-link/
Lowest
Common
Denominator
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
Stateless
Kanban boards are stateless. Snapshots. By default they don't show movement/energy
So how can we visualize movement?
http://14principles.com/visual-management/visual-management-part-5-zombie-cycle-time/
http://yuvalyeret.com/2010/09/19/kanban-early-warning-using-a-predictive-variant-of-spc/
http://www.getkanban.com/
Identifying
Struggling/Slowed Down
Work
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
Gemba
http://www.slideshare.net/inbaroren/whos-afraid-of-the-big-bad-wall
Visualizing Overall Movement
Throughput/Velocity/Average Cycle Times
What do you see here?
Setup explicit process policies that aim to bring struggling work in
http://leansoftwareengineering.com/ksse/scrum-ban/
http://www.flickr.com/photos/czmj/4160014748
Scrumban
Timeboxing
http://www.flickr.com/photos/booleansplit/5874905524
Sliders
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:
MMFs
BDD / ATDD
User Stories
MVP
(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!
http://www.slideshare.net/JoshuaKerievsky/sufficient-design-6194098
Try... Discuss and clarify the treatment for each work item
http://www.slideshare.net/skillsmatter/bdd-introduction
- Software that Matters
Dan North, ThoughtWorks
Also look at
Granularity
Acceptance-Test Driven Development
Behaviour-Driven
“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
http://www.flickr.com/photos/njj4/5044361592
http://www.flickr.com/photos/slidesf/2648616262
http://www.flickr.com/photos/jongales/391648530/
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
BDD / ATDD
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
Time
http://www.mountaingoatsoftware.com/tools/project-success
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
http://www.agilesparks.com
Questions?
Feedback, Suggestions, questions:
Energizing technology delivery organizations in Israel and Worldwide...
So... how do we know what is our energy level?
Subordinate To
Exploit
Identify
Elevate
Prevent Intertia
"F24: The principle of Alternate Routes: Develop and maintain alternate routes around points of congestion."
Reinertsen
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
http://www.flickr.com/photos/zippy/22748510/
Unsustainable Pace
http://www.flickr.com/photos/mark-magnusson/58909454
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
http://www.flickr.com/photos/pagedooley/3995564048/
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
http://damonpoole.blogspot.com/2011/08/scrum-no-commitment-required.html
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
Development+Testing
Customer Requirements Signoff Process
Analysis - Development Gap
Delivering to a non-Agile client,
using Fixed Price signed off Features
And Now?
Quantum
Uber-Slicing Mode
Stop/Continue Forum
Pairing
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
Estimation
Accuracy
Fixed Price Feature
Fixed Date Feature
Roadmap
Production Defect
Fixed Date Project
Dev Env Improvement
IT Support Case
Regulatory Req
Technical Rewrite
http://www.focusedperformance.com/articles/ccrisk6.html
(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
11
11
10min
30min
http://damonpoole.blogspot.com/2011/08/scrum-and-kanban-like-chocolate-and.html
Specification by Example
... an example of Classes of Treatment
Congestion?
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)
Experiment
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
Cadence
Giving the Road Runner the right directions
Bottleneck Routing
Still, it sometimes works...

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

Twitter: @YuvalYeret
Full transcript