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:
- 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.
- 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]).
- It uses a name/title for each artifact that is descriptive and everyone who reads it can understand to what it refers.
- 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.
- It tells you who the go-to person is for that artifact.
- 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.
- 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.
Keeping Agile™ with Brian Lucas 
Good post! Never really understood what Kanban was in agile before.
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
thank you for this post
thank you for reading it!
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
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
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!!!!
Martin – Let me know how things work out for you! -Brian
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
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
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?
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.
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
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.
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.
EXACTLY!
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!!!!
Great to hear you are being successful!
Simple and easy to understand and implement… and its effective. Nice job Brian…
Someone finally explained something about kanbans simply and I understood it! Amazing!
Its always amazing at how some of the simplest tips work the best. Thanks Brian.
This made the subject clear to me. Thanks Brian!
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!