A Simple Definition of Kanban Leads to Agile Productivity

By Brian Lucas

“If you seek the kernel, then you must break the shell…” – Meister Eckhart

I was discussing Kanban the other day with several people who were very confused by the concepts.  One viewed it as Kanban vs. Agile, another felt it was just a way of flowing work better and the third had not even heard the term.  Hence it has become a topic in Keeping Agile.  Lean[1] gets a lot of play along with agile,  I discount lean as a term for software development and generally do not believe it applies.  As far as Kanban is concerned; I could go into a long dissertation here about the history of Kanban and discuss the Japanese terms of “muda” “mura” and muri”, but that would put you to sleep and since it is something you are not interested in from an agile perspective a waste[2] of time.

So straight to the heart of the matter! First, a definition, Kanban is a Japanese word that means sign.  Kanban is used to control work in progress (WIP) in a manufacturing line.  The concept has been applied to software development in several different ways.  I am going to cover how Kanban concepts should be applied to agile methodologies like Scrum.  Kanban is sometimes erroneously contrasted with Scrum.  Although many refer to the term in the context of its origins in the Toyota Way[3], its popular use misconstrues much of its original intent.

The problem most people make is one of strict interpretation of the process and not understanding Kanban in terms of the needs of an agile effort.  Flipping over to agile for a second; the fact is that agile by its very nature places an emphasis on the goal and not the means to achieve that goal.  “Agile is at its root – adaptation in furtherance of accomplishment.”  If you are dogmatically following a process, even a specific agile process, instead of adapting your activity to successfully achieve the goal; you are NOT agile!  As I said in my webinar, “Is Agile a Fad or an Evolution”, available on the ITMPI web site, too often we are dogmatically transcribing physical product manufacturing concepts over onto software development.  They don’t work because at their basic operational level; the two concepts have too much at variance.  Software is meant to change and adapt; manufactured products items are based on standardized replicability.

For Kanban, to define its intent as buffering parts or work, whether as semaphores or actual items, is worthless in a comparison to an agile endeavor.  It is the visibility and analysis that results in optimizing activity with respect to the end goal that’s important.  This goal generically stated is usually an in demand, high quality, low cost product or service produced in a healthy and sustainable fashion.  I disagree with people who say Scrum has no need for Kanban.  Agile is an eclectic method that picks and chooses the good of any concept as needed depending on the circumstances.  Without doubt, Scrum, in particular, is ideally suited to limiting WIP in a fashion similar to one-piece continuous flow so that aspect of Kanban is not something we need to discuss.

What we will focus on is that every agile effort needs a lot of ubiquitous visibility of information and relies on effective, frequent and easy communications.  Posting burn down charts and product backlog item lists are a start at this.  And, from a purely “sign” aspect (remember Kanban means sign in Japanese) Kanban is a great way to understand where items are in the agile work flow.  Using a Kanban concept to post solid status information as it relates directly to the state of artifacts from user stories to acceptance criteria to wireframes to test cases to test scripts and code closes the communication loop nicely.  So if you think of a Kanban as a “sign” or information board showing the up to the minute status of all PBIs in the sprint it’s a helpful agile tool.

What should a work-in-process billboard look like?  Well the first thing to remember is one of the first lessons of agile and that is keep-it-simple!  I like to track artifact status  rather than process per se.  Since a user story is an actual precursor to code and acceptance criteria is derived from user stories and test cases are derived from acceptance criteria and UI designs along with business rules all the artifacts are of a similar genre[4] which limits intrepretation error.  The following example shows a simple Kanban you can use as a start:

There are several things to note:

  1. It refers to the release by its theme name, “ATM Processing” rather than a release name like, “ATM R1.1.0.1”.  This gets everyone on board with the intent of the release and provides a language that you can communicate with the customer or the end user.  IT people for years have shoveled out ridiculously non-meaningful names for software releases and yelled at the user community when they couldn’t get the numbers straight.
  2. It uses an at-a-glance technique to identify the positive or negative aspect of an element in the matrix (in this case color[5]).
  3. It uses a name/title for each artifact that is descriptive and everyone who reads it can understand to what it refers.
  4. It deals with work required in terms of % remaining and not hours expended and remaining.  People are far more accurate in estimating what % of the effort is already done and what remains than estimating how many hours are left.  Just like people are far more accurate at identifying which effort between two user stories will be greater.
  5. It tells you who the go-to person is for that artifact.
  6. It shows status of work-in-process by artifact, rather than by a calendar Gantt completion of a process.  The former is far more objective the latter is generally more subjective.
  7. Note that the Kanban does a great job of showing backlog as do other complementary agile reporting charts.

Having a Kanban of this nature is helpful to the entire team as well as many of the peripheral players.  It can be posted on a bulletin board or as I prefer available in an application or posted daily to a portal or sent in “poor-man” fashion in a daily email.  It is vital it be accurately kept up-to-date.   So, Sayonara to all you agilists out there and remember till next time, keep agile!

[1] Usually it is meant to be a surface application of the Toyota Way and in that context I generally don’t discuss or use the term “Lean”.

[2] Muda means waste, forgive the pun.

[3] The Toyota Way is a set of principles and behaviors that underlie the Toyota Motor Corporation’s managerial approach and production system. Toyota first summed up its philosophy, values and manufacturing ideals in 2001, calling it “The Toyota Way 2001.” It consists of principles in two key areas: continuous improvement, and respect for people.  “Environmental & Social Report 2003”.

[4] The link between user stories and code is becoming a tighter loop all the time.  The concept of a “steel thread” is one I heartily espouse.  Simply put it is a direct linkage that runs from a user story through all the system artifacts directly to a piece of code or in a non-software development effort an implemented activity, product or service.  I always recommend that developers use verbose naming standards to make the code self-documenting.  They should also take advantage of the user stories, acceptance criteria and test case documentation to be the basis of their descriptive code comments.  I will cover the concept of a “steel thread” in a later posting.

[5] Before you challenge me on not supporting color challenged individuals let me remind you this is only an example and color is in fact often used to communicate go/no go situations like in traffic lights.

About Brian Lucas

In his life, Brian Lucas has been a coach, farm worker, forester, health care advocate, life guard, general contractor, mechanic, mixologist, musician/singer (in a rock group), salesman and teacher. Brian has worked as a project manager, technical marketer, methodologist, manager, software architect, systems designer, data modeler, business analyst, systems programmer, software developer and creative writer. These efforts include over a hundred hi-tech initiatives in almost every business and industrial sector as well as government and military projects. Among them, he designed and developed a quality assurance system for the first transatlantic fiber optic communications network, a manufacturing system for a large computer manufacture’s seven manufacturing centers, a data mining system for steel production, an instrumentation system for cable systems, defined requirements for government’s information systems and designed and developed human performance management systems. Brian has educated and mentored many over the years, designing programs to discover and develop talent. He has also lectured extensively to a variety of audiences. Brian is currently devoting as much time as possible to the innovation of business agility and human capital management along with the next generation of agile software development. As an amateur theoretical physicist he is working on joining general relativity and quantum mechanics through a multidimensional time corollary on string theory and negating the uncertainty principle with Louis de Broglie’s wave/particle hypothesis. He is also an avid blue-water sailor and wilderness backpacker. He enjoys billiards, boxing, chess, cooking, famous battle reenactments and war gaming, fencing, flying, gardening, horseback riding, martial arts (particularly Ninjutsu), philosophy and psychology, playing musical instruments (7 so far), poker, rapid-fire target shooting, reading (he tries to read a new book every night), painting with oils, scuba diving, skiing and recently writing novels.
This entry was posted in Agile for Software Development, Agile in the Enterprise and tagged , , , , . Bookmark the permalink.

23 Responses to A Simple Definition of Kanban Leads to Agile Productivity

  1. joe says:

    Good post! Never really understood what Kanban was in agile before.

    • Brian says:

      Joe – too many people get involved in the complexity of something before mastering the basics. If you can’t do the fundamentals well the finer aspects will always escape you. -Brian

  2. Clarisa says:

    thank you for this post

  3. Jack says:

    Brian – This is a simple and great idea having a simple bulletin board that shows where everything is from a project state. I am having our teams create a SharePoint portal that shows exactly what you describe. I am also hanging a flat screen in each meeting room that will have this Kanban display up constantly. We were passing too much paper around previously and the latest status was getting lost in the process. This will address our needs for immediacy. That you again for sharing from your wealth of knowledge! – Jack

    • Brian says:

      Jack – Thank you for sharing your implementation ideas. You are aware I am sure that there are applications that do similar things, but a SharePoint portal as you describe it is a great way to continually publish the very latest and up to date status to a large populous. Your idea of putting a flat screen in each meeting room is actually a return to the basics of agile with a one better twist. Scrum meeting rooms usually had a whiteboard or flip chart with the release’s and iteration’s status clearly displayed. Your implementation will not only show additional information, but also disseminate to everyone involved not just the team members that attended the meeting at any time of the day from any location. That means it supports distributed agile as well. Nicely done Jack! – Brian

  4. Martin says:

    I am a senior developer with a large insurance company and we have had some trouble keeping our various agile efforts coordinated. While agile works well for us the scrum masters seem to have some difficulty coordinating their activities and seeing that complimentary development efforts are smoothly integrated. Some of the scrum masters would like to see a return of old project management practices. Your description of Kanban looks like it would solve the problem. Thanks for posting!!!!

  5. Gene says:

    Brian we have implemented the kanban philosophy as you have outlined it in this post. We have some additional ideas that I was wondering if you were open to hearing and giving us your opinion. I would also like to know of any recommendations that you have on software packages for agile development. GH

    • Brian says:

      Gene – you can email me your ideas I would be happy to dialog on them with you. As a rule, I seldom break, I don’t give out specific software package recommendations. -Brian

  6. Maryann says:

    We use something like this at the hospital for nursing. This seems like a great idea. I am going to recommend that we follow this idea for everything we do since it makes understanding what is going on much easier. I have heard the term Kanban before, but was confused by it. It is facinating how you can explain topics that appear to be complex in simple terms. Have you ever been a teacher?

    • Brian says:

      All my life! I started teaching my parents when I was born and a severely trying lesson it was for them I am sure. I have been a student longer than I have been a teacher though and I still am.

  7. Sam Salvatore says:

    I am a bit confused Brian as to how you described Kanban here versus how I have seen it described at events that offered Lean sessions. I have looked up the definitions you have given and admit you are correct, but I am confused with the big picture of scrum-agile-lean-kanban. They were explaining Kanban as a Lean method that competes with Scrum. Can you help clarify this? I am a developer that is becoming a team leader and feel I should know this. Sam Salvatore

    • Brian says:

      I will try to do a post to clear this up, but to be candid, this post was a not-so-subtle dig at those who think kanban competes with agile or scrum. I laugh or sigh depending on my mood whenever I see agile versus scrum seminars or faceoffs.

  8. j.velekie says:

    You know this seems like simple common sense and basic good project communications, but we weren’t doing it. I guess we were caught up in the scrum craze. Thanks for reminding us once again that process is never a substitute for thinking.

  9. Gerald says:

    I have used your idea here to help coordinate or agile projects and it is popular and working out well. Thanks Brian!!!! You’re the MAN!!!!

  10. Leslie says:

    Simple and easy to understand and implement… and its effective. Nice job Brian…

  11. Rick says:

    Someone finally explained something about kanbans simply and I understood it! Amazing!

  12. JK says:

    Its always amazing at how some of the simplest tips work the best. Thanks Brian.

  13. FergieGirl says:

    This made the subject clear to me. Thanks Brian!

  14. Mike Loomis says:

    Brian, thanks for making this clear and simple! I have read some pretty confusing posts on kanbans and agile. You have a great ability to make the complex easy to understand by cutting to the heart of the matter. Excellent post in a great blog!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s