I assert the following (please verify with your own evidence from your past):

1. Time from getting information until using it creates new work (one has to redo the information or one works from old information which results in rework)
2. Time from making an error until detecting it creates new work (e.g., a bug found immediately takes little time to fix compared to a bug found weeks later – that additional work is created by the delay)
3. Shortening the feedback times will shorten these delays and therefore lower the amount of work to be done

Three major actions cause delays (which cause additional work to take place):

1. Working on more things than you have capacity for
2. Working on large batches
3. Working on things in the wrong order.

OK, the above is pretty obvious. We know this. What do we do with it?

Here's another assertion - you can't manage what you can't see. Therefore, if you want to eliminate creating extra work, you must create visibility in how you do your work. Visibility means both where the work is and how the work flows from start to finish. This means you must have how your work is done be explicit. This is one reason why explicit policies are so important.

Applying These 'laws' to do Kanban

It is important to realize that Kanban does not say you can’t do iterations.  You can if you want to.  Many people have been introduced to Kanban through a Scrum/Kanban hybrid known as Scrumban. Scrumban is essentially the Kanban mindset applied to Scrum – keeping iterations, but managing the work by attending to flow.   You could actually start your Agile transition with the equivalent of Scrumban – that is, using flow as your guiding force, but having iterations as well – right from the start.

One of the things I really like about Kanban is that the mindset described above can be applied when you have the following challenges:

1. You have key people who need to work on multiple projects or across several teams
2. You are frequently interrupted and set iterations are difficult to achieve
3. Jumping to iterations would be more than your teams or management can bear (change is usually upsetting)
4. It is difficult to break down your work into stories small enough to fit into 1-2 week iterations
5. Your work is already small (e.g., in support, work items are already 1-2 days or less and batching into iterations is just needless overhead

If you have any of these cases, or if you are in a situation where people don’t want to make a major change, Kanban can be used to start where you are and change at the rate your organization can bear.  Of course you must realize that Kanban will only help you if you actually use my previously stated assertions to make positive adjustments to your methods. Kanban suggests that by making your methods explicit and by seeing how your work is abiding by these ‘laws’ and making corresponding changes, your productivity and quality will go up.  I have seen this many times.

An added benefit is that Kanban often feels better.  One does not have to change roles – and throw out what we’ve known in the past.  Kanban is a smooth extension of where we are – not a discrete jump based on other people’s assertions about which practices will work – leaving us to hope they do.  I have yet to meet a team that can’t validate the above assertions from their own experience – and therefore, they undertake an Agile transition based on their own understanding of principles. In addition, with the exception of small teams that have all the skills it needs to do Agile well (a very rare occurrence in my 10+ years in Agile), I find that the laws of flow that Kanban builds on are an incredible asset for all teams to know and use. 

For large scale transitions (100 people or more) the ability of Kanban to be applied with or without iterations is invaluable.  Since one size does not fit all, Kanban allows different teams or groups of folks to apply Kanban as best fits their own situation.  Even though the teams in an organization may now be doing or not doing iterations, they will have the attention on flow in common. This usually helps create a bigger picture and help in the understanding of how teams affect each other.

Alan Shalloway

Further info:

How Delays Cause Waste (11 minute YouTube Video)