The Simple, Visual, Iteration Kanban

I remember so vividly one of my first impressions of an effective agile team. It was about 2001, and I walked into a development shop with a team of about 12 people seated at one large table (later abandoned for modest, semi-open cubicles, by the way.) On one side of the room was a large whiteboard with three vertical columns of sticky notes. I don’t remember for sure what the columns were labeled, or even if they were labeled, but they each contained a set of stories the team was working on, with the “state” of the story represented by the column. However, somehow it was clear to me immediately that the states represented were not started, in progress and done. (Over time, I’ve come to think in four basic “states” of a story, “defined”, “in progress”, “complete” and “accepted”.)

 

 

At that time, one of the companies I was working with, Pelion Systems Inc., was developing software to help manufactures “lean” their enterprise. Pioneered by the Japanese, lean flow manufacturing makes extensive use of the kanban card, which loosely translated, means “signal”. In lean manufacturing, each kanban card is a “simple visual signal” that indicates that a manufacturing work cell is ready for more work. On the floor, it pops up as a visual reminder to everyone in eyesight that a particular cell will soon need more raw material to keep it in production.

 

In the software development shop that day, I was struck by a number of insights, including some of the parallels to agile development and lean flow manufacturing (developed further in SSA Chapter 6 – Lean Software) and the power of the simple visual signal. In this particular development shop, any manager, developer, team member, and even the janitor could see immediately what the state of their project was at the point in time – what work was in process (on the floor), what work was completed (in finished goods) and what work had not been started (raw material). And, as that knowledge wasn’t enough for starters, if any stakeholder in the development effort knew the length of the iteration (easy in this case, two weeks standard) and which day of which week (week one or two) it was, it was possible to predict with some reasonable accuracy whether the project (two week iteration) was likely to be landed (completed on time). A manager’s dream; instant at-a-glance status.

I was hooked. Any software process that provided such a simple way for everyone on a project to know where they were, at a moments glance, was a process that needed much more serious investigation. And so my foray into agile and lean software development practices was further accelerated.

–Dean Leffingwell