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 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 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, 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 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 R184.108.40.206”. 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).
- 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!
 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”.
 Muda means waste, forgive the pun.
 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”.
 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.
 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.