Karl Scotland – Using Agile to Deliver Value
The Fifth Primary Practice of Kanban
I recently wrote what I considered to be the four primary practices of a Kanban System for Software Development:
- Map the Value Stream
- Visualise the Value Stream
- Limit the Work in Progress
- Establish a Cadence
During subsequent discussions on the aspect of Continuous Improvement in a Kanban System, I decided that there was a missing fifth primary practice:
- Reduce the Kanban Tokens
I originally named this practice “Eliminate Kanban”, but was persuaded that this was probably overly sensational, and as a result potentially confusing or misleading. Its intent is that once a Kanban System is in place, the team should be constantly looking to improve it by creating an environment where the work flows naturally. There is a quote that I believe comes from Rother and Shook which says “flow where you can, pull where you must”. By striving to reduce the number of kanban tokens in the system, a team will move towards an environment where they are more self organising and the work can flow. This can be achieved by either lowering the WIP limits or by collapsing the number of distinct stages.
| Print article | This entry was posted by Karl on June 30, 2009 at 8:19 pm, and is filed under Agile. Follow any responses to this post through RSS 2.0. You can leave a response or trackback from your own site. |
A Pattern for Using Scrum and Kanban
about 1 month ago - 5 comments
I’ve noticed a pattern that I’ve found myself using recently when I’ve worked with new teams that makes use of both Scrum and Kanban ideas. I’ve already said that I believe the two are complimentary, and this should help show how. I’ll often begin with a “Canonical Scrum” implementation. This gives a relatively simple introduction More >
The Flow Experiment
about 1 month ago - 2 comments
I put together a small simulation for the SPA Conference this year which seemed to go well, and which I re-ran at the London Limited WIP Society, and hope to run again. You can download the materials, and this is a short write-up of how it works so people can run it and experiment with More >
Does A Kanban System Eschew Estimation?
about 1 month ago - 5 comments
I was recently involved in a brief twitter conversation which started when Mike Sutton tweeted: estimation is not about the number that pops out. It is about exploring effort and discovering that you don’t know stuff. Paul Dyson responded: spot on! This is fundamentally what I don’t like about the kanban “if people find estimation More >
Aspects of Kanban in Methods and Tools
about 2 months ago - 1 comment
I wrote an article on “Aspects of Kanban” which has just been published in the Summer 2010 issue of Methods and Tools magazine. Download it, have read, and let me know what you think! Alternatively, there is now an html version available.
Kanban and Scrum – Intention and Implementation
about 2 months ago - 3 comments
In my last post I introduced the idea of a PVC System – one which exemplifies Pull, Value and Capability – and closed by posing the question as to whether Scrum could be considered to be a PVC System. In answering that question myself, I realised that there is another distinction which I will describe More >
Facilitating A Kanban Konversation
about 5 months ago - 2 comments
As I mentioned in my Scrum Gathering Musings, I came up with a twist on the Goldfish Bowl format which I used during the Kanban Exploration Deep Dive. Here are some more details. The Goldfish Bowl format works really well for facilitating a focussed discussion with a large number of people. It keeps the active More >
Process Safeguards and Ski Slopes
about 7 months ago - 11 comments
One of the joys of working as a coach for EMC Consulting are the regular opportunities to have deep conversations on various topics with my colleagues when we are in the office together. For example, earlier this week myself and Simon Bennett began to discuss way of talking to our clients about process such that More >
Kanban Trail Markers
about 9 months ago - 2 comments
When talking about Kanban Systems for Software Development, I always try to emphasis that the Kanban System is more than the tool, and is a System that should be owned by the team, rather than being imposed upon it. By owning it, and being part of creating it, a team are more likely to evolve More >
Outcomes and Sync Steps
about 10 months ago - 4 comments
I met up with Jean Tabaka last week for a coffee and we chatted over various things, including Lean, Kanban, “The Don”, Tufte, and Systems Thinking. One of the other areas was around the origins and original intents of Scrum. Jean mentioned an early paper(*) by Jeff Sutherland, written before the current terminology became standard, More >
Is Kanban A Relabeling of Scrum?
about 10 months ago - 17 comments
Firstly, this post is not an attempt to be divisive or competitive. Instead it is meant to be exploratory. What would it mean for the statement in the title to be true? Actually, the full statement was “People have so misunderstood Scrum, that they’ve reinvented it and called it Kanban”. It was made by Jim More >
about 1 year ago
Sharing tokens across states can reduce tokens due to the ‘sum of squares’ phenomenon, which is sort of like collapsing states, except you get to keep the visual control, the standards, and the statistics.
about 1 year ago
Go on Karl, after recent discussions how about:
0. Respect those doing the work
It can’t hurt and may just help readers remember where all this comes from.
I truly believe that this is a deeply held belief in the existing Kanban community, we need to work to ensure that as popularity increases we don’t loose this in favour of tools, limits and index cards.
Cheers
Dave.
about 1 year ago
Corollas were fairly popular and selling well. We started with a plan to make 5000 cars. I instructed the head of the engine section to make 5000 units and use under 100 workers. After two or three months, he reported, “We can make 5000 units with 80 workers.”
After that, the Corolla kept selling well. So I asked him, “How many workers can make 10000 units?”
He instantly answered, “160 workers.”
So I yelled at him, “In grade school I was taught that two times eight equals sixteen. After all these years, do you think I should learn that from you? Do you think I’m a fool?”
Before long, 100 workers were making over 10000 units.
–Taiichi Ohno
about 1 year ago
The publisher’s page for Learning to See (Rother and Shook) is here, and lists related resources:
http://www.lean.org/Bookstore/ProductDetails.cfm?SelectedProductID=9
about 1 year ago
Hi David,
That is going to be my next blog post
I needed to get this one out first though! Watch this space…
Karl
about 1 year ago
C’mon, if we follow this road, we may add “energized work” and other common sense agile values. Kanban should be kept as lean as possible
about 1 year ago
Thanks Corey.
That sounds like moving to more of a CONWIP system?
Karl
about 1 year ago
I like hybrids where there are pooled segments chained together e.g. fuzzy-front-end -> engineering -> operations.
about 1 year ago
Nice quote. So did Toyota achieve that improvement by reducing kanban, or improving throughput with the same kanban?
about 1 year ago
Probably some of both, depending on where the improvement opportunities were. The more trained people you have, the easier it should be to find people to perform multiskill operations. It could be that all of the new workers were applied to new flow processes that reduced both cycle time and kanban.