Karl Scotland on Kanban, Flow & Cadence
Bob H
Kanban, Flow & Cadence
http://availagility.co.uk/2008/10/28/kanban-flow-and-cadence/Intro
There has been some noticeable increase in interest in Kanban recently, with a number of people asking for more basic info, and more people writing new blogs and articles. This is my attempt to describe in more detail my take on it all, which I refer to as Kanban, Flow and Cadence.
- Kanban – Controlled Work
- Flow – Effective Work
- Cadence – Reliable Work
Kanban
A Kanban system is a mechanism for controlling the work in the software development system. Kanban can be defined as “visual card”, as shown below – kindly written for me by Kenji Hiranabe [?] at Agile 2008.
The origin of kanban is the Toyota Production System. Taiichi Ohno, in his book Toyota Production System, wrote:
“The two pillars of the Toyota production system are just-in-time and automation with a human touch, or autonomation. The tool used to operate the system is kanban.”
Kanban is what enables a pull system for just-in-time work.
What does a Kanban System look like for software development? Very simply, there is a queue of work, which goes through a number of stages of development until its done. When work is completed in a stage, it goes into a downstream queue for the next stage. When someone needs new work to do, they pull it from their upstream queue. This can be depicted as below.
That looks very like a typical Agile Task Board, with maybe a few more steps, although there is nothing to say there can’t be a single development stage. However, there is one more important element which really defines a kanban system – limits. There are two basic limits – Queue limits and WIP limits.
Queue limits are designed to avoid premature work. This how just-in-time is achieved. The limit should be large enough to keep the team busy (i.e. there is always something in it for the team to start work on), but small enough to avoid premature prioritisation (i.e. having things sitting in the queue for too long before they are begun). Ideally the queue should be FIFO, although this is a guideline rather than a hard rule, as sometimes available skills or other resources mean that it is not always possible.
Work In Progress limits are designed to reduce multi-tasking, maximise throughput, and enhance teamwork.
Reducing multitasking is beneficial for two primary reasons.
1) 20% time is lost to context switching per ‘task’, so fewer tasks means less time lost (from Gerald Weinberg, Quality Software Management: Systems Thinking)
2) Performing tasks sequentially yields results sooner. As the diagram below shows, multi-tasking A, B and C (on the top), delivers A much later, and even C slightly later, than sequentially (on the bottom).
A great exercise to demonstrate the effects of multi-tasking was described by Clarke Ching.
Throughput is also maximised by decreasing WIP. Simple examples of this effect are traffic jams, where traffic speed reduces as more traffic builds up, and CPU load, where application performance goes down as CPU load increases. The effect can be be explained by looking at Little’s Law for Queuing Theory:
Total Cycle Time = Number of Things in Progress / Average Completion Rate
Therefore, to improve cycle time there are two options; reduce the number of things in process or improve the average completion rate. Of the two, reducing the number of things in progress is the easier, and once that is under control, then the more challenging changes to improve completion rate can be applied.
Finally, by having fewer work items in progress, then the team is able to focus more on the larger goals, and less on individual tasks, thus encouraging a swarming effect, and enhancing teamwork.
Limiting Work In Progress like this can seem unusual for teams, and there is often a worry that team members will be idle because they having no work to do, but are unable to pull any new work. The following guidelines can be useful to help in this situation.
- Can you help progress an existing kanban? Work on that.
- Don’t have the right skills? Find the bottleneck and work to release it.
- Don’t have the right skills? Pull in work from the queue.
- Can’t start anything in the queue? Is there any lower priority to start investigating?
- There is nothing lower priority? Find other interesting work.
They key question here are what constitutes lower priority investigative work or other interesting work. Essentially it is work which won’t create any work downstream, will improve future throughput and can be paused as soon as existing kanban related work is available. Lower priority work could be spikes or analysis for known impending work. Other interesting work could be refactoring, tool automation, personal development or innovation.
WIP limit sizes can depend on type of work and size of team and should be adjusted to achieve maximum flow. One approach is to start small (e.g. a limit of 1) and increase as necessary. Another is to start larger (e.g. a limit of half the team size) and reduce until the sweetspot is achieved.
The consequences of using a kanban system are that the Product Backlog can be eliminated, because the immediate queue is the only work of interest, timeboxed iterations (i.e.Sprints) can be eliminated, because work is pulled as necessary, and estimation can be eliminated, because work is not planned into iterations.
Flow
Flow describes how the work in the system can delivery maximum value. As Mary and Tom Poppendieck write,
“In lean enterprises, traditional organizational structures give way to new team-oriented organizations which are centred on the flow of value, not on functional expertise.”
In particular, Lean emphasises ‘One Piece Flow’. This means moving one piece at a time between stages in a workflow as opposed to moving batches of work between stages in a workflow. The ‘One Piece’ in a Kanban system for software development can be thought as the Minimal Marketable Feature, as described by M Denne & H Cleland-Huang in Software by Numbers.
“A minimal marketable feature is a chunk of functionality that delivers a subset of the customer’s requirements, and that is capable of returning value to the customer when released as an independent entity”.
The kanbans should be minimal so that they are as small as possible in order to enable progressive delivery to realise the product sooner, reduce feature bloat and focus on the the core features which are the most important, and minimise complexity because each feature has a cost to a user.
The kanbans should be marketable in a number of ways.
- Table Stakes – these delivery parity to the competition and are the minimum needed to be in the game
- Differentiators – these differentiate the product from the competition and delight the user
- Spoilers – these nullify a competitors differentiator and raise the bar for parity
- Cost Reducers – these reduce cost and improves the profit margin
A useful guideline is that an MMF is marketable if it is something that could be written about on a product blog.
The kanbans should be features which are distinct, deliverable and observable. The INVEST acronym (Independent, Negotiable, Valuable, Estimable, Small, Testable) as described by Bill Wake, can also be useful for applying to MMFs.
The Marketable element of MMFs means that they may sometimes be larger than typical User Stories, which often break work down such that while they can be incrementally delivered, and show some element of value, they are not marketable in their own right. Therefore, it is important to understand an MMFs Value Stream in order to deliver the whole MMF as quickly as possible. A value stream describes the steps, delays and information required to deliver a product, and can often be used to decide the steps in an initial kanban system. With large MMFs, the User Stories become more of an analysis technique in order to enable incremental delivery of an MMF, without losing sight of the overarching MMF. I describe how a continuous flow can be achieved with MMFs in The Anatomy of an MMF.
A number of techniques can help manage the relationships between MMFs and User Stories in order to realise the benefits of both. One is User Story Mapping, as descried by Jeff Patton.
I have also recently been working in a regulated environment where User Case Goals and Sub Goals have provided the MMFs, with the detailed scenario paths and steps providing the additional details.
A further enhancement is to use two-tier Kanbans, with one tier for the MMFs, and another for the User Stories.
The consequence of applying the concept of Flow is that emphasis is placed on using larger, value-focussed MMFs, rather than smaller, more incremental Stories.
Cadence
Cadence is the approach to achieving commitment and reliability with a kanban system. I often get a question something along the lines of,
“If the team isn’t estimating or planning with fixed time-boxes, how can it make reliable commitments?”
To quote Mary and Tom Poppendieck again,
“A regular cadence, or ‘heartbeat,’ establishes the capability of a team to reliably deliver working software at a dependable velocity. An organization that delivers at a regular cadence has established its process capability and can easily measure its capacity.”
The time-boxed iteration is one form of cadence, which couples planning, review and release together. A kanban system de-couples these events and allows them to have separate cadences, as well as adding two additional ones. Throughput is the amount of output of a process in a given period of time, and Cycle Time is the length of time to complete a process. The relationship between the two is:
Throughput = WIP / Cycle Time
Throughput allows forecasting of future capability, without needing to specify what might be delivered. Cycle Time allows commitment by becoming an SLA with the business (see Kanban Commitment). Where the size of work varies, from large new features to small fixes and change requests, then a classification of MMFs can enable a range of cycle-times. Both Throughput and Cycle Time can be charted and trended, in a similar way to XP’s Velocity, as a means to encourage the team to improve. A Cumulative Flow Diagram can also make visible how the work is flowing through the system and highlight bottlenecks.
For longer term forecasting, a quarterly planning cadence focusses on quarterly goals and objectives. MMFs can subsequently prioritised to meet those goals and objectives. A regular release cadence will build up trust that the team will work to its full capacity and throughput.
Other cadences, are daily stand-up meetings, and regular retrospectives and Operations Reviews as described by David Anderson. Some teams are using a Retrospective Kanban to signal when a retrospective is necessary, and I have already blogged briefly about Kanban and Retrospectives.
The consequence of Cadence is that commitment and reliability is achieved though measurement as opposed to planning.
Summary
They key points of Kanban, Flow and Cadence are:
- A Kanban System manages the workflow in a way which allows the Product Backlog, Timeboxed Iterations and Estimations to be eliminated.
- Flow is about effectively delivering maximum value by focussing on optimising the value stream of larger MMFs
- Cadence allows iteration input and output to be de-coupled and achieves commitment and reliability via measurement rather than planning.
Further resources and information can be on my Kanban Page, including most of the material which has influenced and directed my thinking.
http://availagility.co.uk/2008/10/28/kanban-flow-and-cadence/
reposted from Karl Scotland’s AvailAgility blog.
Top 10 Reasons for Kanban
While this short video has nothing to do with software development, it is a great overview of the benefits of implementing a kanban system.
Related articles
- Top Kanban Software (from AgileScout) (bobsleanlearning.wordpress.com)
- Opining On Kanban (bobsleanlearning.wordpress.com)
- Visualizing Book Club Activities With Personal Kanban (learningagileandlean.wordpress.com)
- Kanban Leadership Workshop with David Anderson (kurthaeusler.wordpress.com)
- New Version of my Simple Kanban Board Application (codemonkeyism.com)
Top Kanban Software (from AgileScout)
As I was looking for kanban software I came across this post from the pros as the Agile Scout. It seemed very “un-lean” to do anything but repost the info here!
reposted by Bob H
Top Agile Tools – Best Kanban Tools
http://agilescout.com/best-kanban-tools/
Kanban is growing like wildfire. Many organizations are finding value in this simple process via a “pull” system: The production of work is determined by the demand from the customer.You have a choice:
1. You can build a Kanban board.
2. You can use a tool and an actual board!
Here is a list of the best Kanban tools out there today.
Stay tuned for Tool Reviews from your very own Agile Scout!
Flow:
JAM Circle: *Open Source
Lino:
Scrumy: *AGILE SCOUT REVIEWED!
Simple Kanban: *Open Source
Got a cool tool to add to the list? Let us know. We review stuff.
Related articles
- Opining On Kanban (bobsleanlearning.wordpress.com)
- Karl Scotland on Kanban, Flow & Cadence (bobsleanlearning.wordpress.com)
- New Version of my Simple Kanban Board Application (codemonkeyism.com)
Opining On Kanban
I became a kanban advocate after implementing a kanban system for our instructional design team during my time at Delta. Before implementing the kanban, leaders assigned work to team members. As is the case in most organizations, we rewarded our top performers by giving them more work. With the kanban in place, the entire team was responsible for moving work through the process. Not surprisingly, our top performers still did more work, but since the work process was now transparent, all the instructional designers improved their performance.
As I work to discover how kanbans can work in the software development process, I found the follow blog posts helpful. I hope you enjoy them and I encourage you to visit both sites for more info on how lean works in software development.
Bob Hubbard April 2011
This post is from Dan Ackerson & Matthias Marschall’s “Agile Web Development & Operations website @: http://www.agileweboperations.com/scrum-vs-kanban
Scrum vs. Kanban
by Matthias Marschall on August 10, 2010 · 9 comments
When inflexible and wasteful processes are making your organization inefficient, it’s time to introduce agile methodologies. Scrum vs. Kanban then becomes an essential question: Which one is better suited for my own situation?Scrum – A Fundamental Shift
Scrum is a well defined process framework for structuring your organization. Introducing Scrum is quite a change for a team not used to agile methodologies: They have to start working in iterations, build cross-functional teams, appoint a product owner and a scrum master, as well as introducing regular meetings for iteration planning, daily status updates and sprint reviews. The benefits are well understood: Less superfluous specifications and less hand overs due to cross-functional teams, more flexibility in roadmap planning due to short sprints, etc. Switching your organization to use Scrum is a fundamental shift which will shake-up old habbits and transform them into more effective ones.
Scrum Leverages Commitment As Change Agent
The initial introduction of Scrum is not an end in itself of course. Working with Scrum you want to change habits inside your team: Take more responsibility, raise code quality, increase speed. As your teams commit to sprint goals, they are intrinsically motiviated to get better and faster in order to deliver what they promised. Scrum leverages team commitment as change agent. It’s amazing to see how much teams demand from themselves – often way more you as a manager ever dared ask for.
Kanban – Incremental Improvements
Kanban is way less structured than Scrum. It’s no process framework at all, but a model for introducing change through incremental improvements. You can apply Kanban principles to any process you are already running (even to Scrum
. In Kanban, you organize your work on a Kanban Board. There you have states which every work item passes through from left to right. You pull your work items along through the in progress, testing, ready for release, and released columns starting from the right hand side based on the allocated capacity of each of the columns. And you may have various swim lanes – horizontal “pipelines” for different types of work. The only management criteria introduced by Kanban is the so called “Work In Progress (WIP)”. Nothing else needs to be changed to get started with Kanban.
Kanban Leverages Work In Progress (WIP) Limits as Change Agent
For every column (state) on your Kanban board you should define a “Work In Progress”-Limit (WIP Limit). The WIP limit tells you how much work items are allowed to stay in a certain state. If the state is “full”, no new work can enter that state. The whole team has to help clear the filled up state first. That way your team will find out about bottlenecks in the progress simply by looking at the Kanban Board and is challenged to change the way they work to avoid such bottlenecks in the future. In that way, the WIP limit acts as change agent in Kanban.
Scrum vs. Kanban
Looking at both agile methodologies it should be more clear what to introduce when: If your organization is really stuck and needs a fundamental shift towards a more efficient process, Scrum seems to be more appropiate. If you already have working processes, which you want to improve over time without shaking up the whole system, Kanban should be your tool of choice.
This post from Tobias Mayer at the”Agile Anarchy” blog.
Scrum and Kanban — different animals
On my last blog post Simple Scrum, Karl Scotland commented:
“Nice description. It also gives me a nice way of contrasting a Scrum and Kanban. Kanban says nothing about Roles, Artefacts or Ceremonies, but leaves the team to self-organise what works best. Instead, Kanban (as I describe it) suggests focussing on understanding the value stream, visualising it, limiting work in progress, establishing a cadence, and continuously improving [...]“
Karl’s comment helped me to see clearly that any comparison between Scrum and Kanban is utterly pointless. It is like comparing a hammer with a screw driver, or an soufflé with a kangaroo. Which is better?
It was that phrase “value stream” that did it. It has always made me vaguely uncomfortable when I have heard it spoken in relation to software, and I wasn’t sure why. I have been thinking more about it, and I think I understand. There are two things.
This is a kanban (from kanbandistilled.com)
Firstly, I fundamentally disbelieve that there is any such thing as a “value stream” when you are working in a complex environment, in a creative process, building new products or generating new ideas. Once you have mastered something, and go into building variations of it (e.g. web sites, or hand-crafted wedding dresses) then perhaps value-stream mapping comes into its own (there would need to be more similarities than differences). But before such time of repetition I suggest that to focus on a value stream is specious, and misleads people into believing that the creative process is mappable and repeatable. It is not.
Secondly, and more importantly, Scrum is a framework for organizational change It is people-centric. The focus of Kanban —as described here by Karl— is on business value. It is profit-focused. Focusing on profit will rarely transform an organization. Focusing on people and culture stands a better chance. The goal of Scrum —or at least, the goal of the Scrum Alliance, of which I am a member— is to transform the world of work. To do that, we must start with the individual, and we must focus on human values, not business values.
It has become clear to me that Scrum and Kanban are in place for different reasons. Sure, using Scrum you may increase your productivity and build better products (one would hope so!) and using Kanban may make people happier at work, but these are secondary concerns.
And lastly, a word for XP. If you are working with a software team, regardless of the process, and they are not using the principles of software craftsmanship suggested by XP, then please start there. Anything else will be a facade.
Mapping a Value Stream to a Kanban Board
Lean Leaders: I’ve attached a link to a video from Alan Shalloway at NetObjectives. In this video, Alan Shalloway describes the process of mapping a value stream to a Kanban board and why both are important in improving business-driven software development… and he accomplishes all that in 15 minutes.
The Amazing Adventures of Kanban
By Jon Miller | Post Date: June 17, 2009 12:57 PM (http://www.gembapantarei.com/2009/06/the_amazing_adventures_of_kanban.html)
Kanban was born nearly 60 years ago. It’s creator, Taiichi Ohno, intended kanban to combat the evil overlord Overproduction, Mother of All Wastes and her Minions of WIP. The battle is far from won. During those six decades kanban has been through some amazing adventures.
Kanban Gains Superpowers
Pokayoke has the power to prevent mistakes. Jiodka frees people to run machines intelligently, rather than be run by them. Heijunka has the power to take choppy demand and smooth it out. Kaizen has the power to make infinite small improvements. All of these players and their many friends bring order and harmony to a production system. Yet one stands above them all: kanban.
Kanban was endowed with three major powers. First is the the power to instruct the production of goods. Within the Toyota Production System and its imitators, only the kanban has the power to cause things to be made. Second is the power to instruct the movement of goods. Like its first power, kanban can cause things to be moved. Third and perhaps most important, kanban can motivate people towards continuous improvement by reducing its own size. Within a kanban system, the less kanban there is, the more improvement is needed. Like a true hero, the power of kanban increases as it diminishes its own presence. Amazing.
Kanban vs. the Communists
From the beginning, the powers of kanban were awesome. Overproduction was stopped in its tracks, Work In Process (WIP) was slashed, and various hidden wastes were exposed and removed through continuous improvement. Almost immediately kanban extended its reach outside of Toyota, the enterprise within which it was born, to its suppliers.
But there was no way that such drastic action would go unnoticed in Japan, the Land of Wa (harmony). A Japanese communist party member accused Toyota of using kanban to make unreasonable demands on suppliers to deliver products right away. Taiichi Ohno was summoned to the Japanese parliament to testify in defense of Toyota’s use of the cards to order suppliers to make deliveries of parts. In the end, the Japanese equivalent of the Fair Trade Commission instructed OEMs to limit the fluctuation of actual monthly orders to suppliers by no more than 10% from the firm monthly orders placed in advance.
Perhaps kanban was becoming too powerful. The government needed step in to curb kanban’s powers, or at least insure they were always used for good. It was a lesson learned. None of the others, not pokayoke, not jidoka, no tkaizen have been called to testify in front of the government, or to face down the communists.
Kanban: the Fickle Hero
But for all its powers kanban was at times fickle. To kanban, jidoka, SMED and pokayoke were just sidekicks, enablers. Kanban treated both 5S and Visual Controls as givens rather than equals. Kaizen may be an equal partner to kanban, but in private kanban lorded over kaizen because of its power to motivate others to improve. While these various players toiled away at making improvements and building systems, kanban expected that their work was all foundation building for the kanban system. Kanban never said a word of thanks, nor asked for one.
Like a temperamental artist who wants just the right type of bottled water and sandwiches in his dressing room, kanban said “I will only work for you if once the workplace is clean and visually organized, quality is reliable, lot sizes are small and a logistics system is in place to support me.” Kanban would not do the heavy lifting for you. Kanban would let you know when you’re failing, but may not always come to the rescue. Kanban is a powerful but fickle hero, relied on at your own risk.
Kanban on the Global Stage
In the 1980s Taiichi Ohno was invited to the USA to speak about the Toyota Production System. Unfortunately the organizers confused kanban, the most noticeable feature of TPS, for the system itself. Kanban stole the show, overshadowing the shadowing even the system it was designed to enable. This was not what its creator Taiichi Ohno intended.
As kanban took the global stage with hubris, inevitably its powers were misunderstood or misdirected. Without the protection of the limits on demand signal fluctuation, OEMs abused suppliers with what can be best described as quasi-kanban. Kanban saw its name sullied by impostors and imitators. Even when kanban was called to use its powers, too often it was pressed into service without the support of its friends pokayoke, SMED, heijunka, visual controls and 5S. Even when they were nearby, they were prevented from working as a team.
Kanban of 1,000 Disguises
Kanban’s powers were weakened as much was lost in translation. In order to effectively combat overproduction in its new and vastly diverging environments, kanban adopted a thousand disguises. Some were more effective than others. Each time kanban answered the call to battle overproduction, it seemed it was in a different form: a lamp, a card, a square on the floor, a box, a cart.
Kanban continues to be misunderstood even today, with many unsure of which is the true face of kanban. But the battles rages on against the evils of overproduction.
Kanban and the Builders of Invisible WIP
Early in the 21st century, kanban found an unexpected band of allies. These people were prolific builders of invisible but deadly WIP. They were software developers. Appearing not as information traveling with the manufactured work product itself but rather represented on a task board, kanban works tirelessly to control even the invisible WIP of lines of code.
Once again, kanban added a new form to its one thousand disguises in order to combat overproduction in on a new battlefield.
Yes We Kanban
Today Kanban finds itself in an uneasy but increasingly important alliance with the Coders through the Limited WIP Society. Flying the banner of kanban’s creator and genius production system designer Taiichi Ohno, kanban has found a common aim with this league of mad scientists: to ultimately defeat WIP and it’s overlord Overproduction.
How much progress will kanban’s alter-ego of Agile Kanban make in exercising its three superpowers across the software development world? Only time will tell.
Kanban Meets Dr. Bahri the Lean Dentist
Kanban may have met its match in Dr. Bahri, the pioneering practitioner of lean dentistry. Dr. Bahri has applied the powers of kanban to instruct the work that dentists and dental hygienists do, to instruct the movement of patients, and to motivate continuous improvement. Wouldn’t it be ironic if six decades into an amazing career, kanban goes for some dental work and finds the power of kanban applied to fixing its teeth?
The villains of overproduction, push and WIP never sleep. The amazing adventures of kanban continue…
Related Articles
- Calculating Kanban Signal Points (brighthub.com)
- Kanban Tool – empower yor personal and team productivity with online kanban boards (kanbantool.com)
- Daniel Root’s Blog: How To: Create a Kanban Board in SharePoint 2010 with Zero Code (danielroot.info)
- 10 kanban boards and their context (crisp.se)
- Announcing the Launch of iKan, the Personal Kanban iPhone App | Personal Kanban (personalkanban.com)
- Guest Post: My Current Personal Kanban System (personalkanban.com)
- Lean/Kanban – Crisp AB (crisp.se)
- Personal Kanban 101 | Personal Kanban (personalkanban.com)
Some Lean Terms Visually
Communicating Lean principles, concepts, and terminology can be tricky. Many Lean terms originate in Japanese, introducing a barrier to understanding. In an effort to sidestep the language barrier, Stappan Noteberg posted this presentation on Slideshare.com. I think it’s an innovative way to show some Lean ideas and hope you think it’s worth a look.
Bob Hubbard, Sept 2010
A Stapffan Noteberg presentation on Slideshare.com
Kanban Distilled for Managers
Kanban is a technique for managing a software development process in a highly efficient way. Kanban underpins Toyota’s “just-in-time” (JIT) production system. Although producing software is a creative activity and therefore different to mass-producing cars, the underlying mechanism for managing the production line can still be applied.A software development process can be thought of as a pipeline with feature requests entering one end and improved software emerging from the other end.
Inside the pipeline, there will be some kind of process which could range from an informal ad hoc process to a highly formal phased process. In this article, we’ll assume a simple phased process of: (1) analyse the requirements, (2) develop the code, and (3) test it works.
The Effect of Bottlenecks
A bottleneck in a pipeline restricts flow. The throughput of the pipeline as a whole is limited to the throughput of the bottleneck.
Using our development pipeline as an example: if the testers are only able to test 5 features per week whereas the developers and analysts have the capacity to produce 10 features per week, the throughput of the pipeline as a whole will only be 5 features per week because the testers are acting as a bottleneck.
If the analysts and developers aren’t aware that the testers are the bottleneck, then a backlog of work will begin to pile up in front of the testers.
The effect is that lead times go up. And, like warehouse stock, work sitting in the pipeline ties up investment, creates distance from the market, and drops in value as time goes by.
Inevitably, quality suffers. To keep up, the testers start to cut corners. The resulting bugs released into production cause problems for the users and waste future pipeline capacity.
If, on the other hand, we knew where the bottleneck was, we could redeploy resources to help relieve it. For example, the analysts could help with testing and the developers could work on test automation.
But how do we know where the bottleneck is in any given process? And what happens when it moves?
Kanban reveals bottlenecks dynamically
Kanban is incredibly simple, but at the same time incredibly powerful. In its simplest incarnation, a kanban system consists of a big board on the wall with cards or sticky notes placed in columns with numbers at the top.
Limiting work-in-progress reveals the bottlenecks so you can address them.
The cards represent work items as they flow through the development process represented by the columns. The numbers at the top of each column are limits on the number of cards allowed in each column.
The limits are the critical difference between a kanban board and any other visual storyboard. Limiting the amount of work-in-progress (WIP), at each step in the process, prevents overproduction and reveals bottlenecks dynamically so that you can address them before they get out of hand.
Worked Example
The board below shows a situation where the developers and analysts are being prevented from taking on any more work until the testers free up a slot and pull in the next work item. At this point the developers and analysts should be looking at ways they can help relieve the burden on the testers.
Notice that we’ve split some of the columns in two, to indicate items being worked on and those finished and ready to be pulled by the downsteam process. There are several different ways you can layout out the board. This is a fairly simple way. The limits at the top of the split columns cover both the “doing” and “done” columns.
Once the testers have finished testing a feature, they move the card and free up a slot in the “Test” column.
Now the empty slot in the “Test” column can be filled by one of the cards in the development “done” column. That frees up a slot under “Development” and the next card can be pulled from the “Analysis” column and so on.
Next steps
How to get started with Kanban…
- Map your value stream (your development process).
Where do feature ideas come from? What are all the steps that the idea goes through until it’s sitting in the hands of the end-user? - Define the start and end points for the Kanban system.
These should preferably be where you have political control. Don’t worry too much about starting with a narrow focus, as people outside the span will soon ask to join in. - Agree:
- Initial WIP limits and policies for changing or temporarily breaking them
- Process for prioritising and selecting features
- Policies for different classes of service (e.g. “standard”, “expedite”, “fixed delivery date”). Are estimates needed? When choosing work, which will be selected first?
- Frequency of reviews
- Draw up a Kanban board.
All you need is a whiteboard and some Post-It™ notes. Don’t spend too much time making it look beautiful because it will almost certainly evolve. - Start using it.
- Empirically adjust.
from kanbandistilled.com/
Related articles
- Top Kanban Software (from AgileScout) (bobsleanlearning.wordpress.com)
- Kanban Leadership Workshop with David Anderson (kurthaeusler.wordpress.com)
Kanban Explained
One Day in Kanban Land
some kanban humor from Henrik Kniberg
http://blog.crisp.se/henrikkniberg/2009/06/26/1246053060000.html
1 comment