Kanban in a Nutshell

June 25, 2011 — Posted by Al Shalloway

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)

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.


Comments

The 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 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 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 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

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban