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.
Alan Shalloway
Further info:
How Delays Cause Waste (11 minute YouTube Video)
Comments
Ok, this is really quite good! But...
Sat, 2011-06-25 01:28 — Curtis HibbsThe delay-creates-work meme has been one of my hot buttons, as well.
You've done such a good job of cutting to the heart and summarizing the important points that I really don't want to criticize it at all -- I just want to sit back, repeatedly re-read it and savor the concepts as they wash over my brain (seriously!)...
However, even though I actually do pretty much agree with your final paragraph, I think it omits an important contextual element.
I know you're familiar with the Dreyfus model of skill acquisition. I would assert that people and organizations at the lower end of the model (novices and advanced beginners), may work better with scrum because they may not yet have the skill level necessary to "trust your judgement to improve things." Whereas those at the higher end of the model may very well do better with kanban.
Curt Hibbs
Curt:Good point (although I
Sat, 2011-06-25 07:54 — Al ShallowayCurt:Good point (although I disagree - another short blog needed ;) ). There are two psychological parts to a transition - one regards how we learn (Dreyfus being a good one) the other involves how we deal with change - Satir model being a good one. I would contend that Scrum is at one extreme and people think Kanban is at the other. There is a middle ground I will describe shortly.
I had considered putting this into here, but liked the conciseness of it this blog without it.
The elephant in the room of Agile / Scrum is that Scrum virtually ignores the psychology of folks and is a strongly prescriptive - trust us - model to a larger extent than it needs to be. More later.
Truly, thanks.
Alan Shalloway, CEO Net Objectives
Are you sure that "The other
Tue, 2011-07-19 11:23 — animikhAre you sure that "The other says – trust us and follow these methods until you have success – regardless of the effort it takes you" -- if true may be that is why we have so much differentiation in teams that are trying to follow "pure"scrum?
I don't know of another
Thu, 2011-07-21 09:50 — Al ShallowayI don't know of another interpretation given these facts:
1) a set of principles on which Scrum is based other than it is empirical (which somewhat denies a set of principles) has been forwarded other than me (I've explained Scrum in terms of Lean)..
2) the claim is remove impediments in your way to get it to work - regardless of the size of the impediment or difficulty in removal
So, one is basically left with a do this, I won't explain why, keep at it until success. I think that matches my description.
Alan Shalloway, CEO Net Objectives