I assert the following (please verify with your own evidence from your past):
Three major actions cause delays (which cause additional work to take place):
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:
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.
How Delays Cause Waste (11 minute YouTube Video)