Agile Kanban Journal Day 200: Small is Beautiful

Last June I began using what the progressive folks in the software development community are calling an agile kanban board to track, and ideally to speed up, work on my various projects. The biggest benefit from this so far has been to keep the problems visible and in front of me always. I still haven’t found good measures for tracking productivity using the agile kanban board. One of the reasons for this is that instead of tracking a particular type of work that behaves in same or similar ways, I was tracking anything on my radar that wasn’t either client-specific solution delivery or a just-do-it task, for which I have other boards. This particular agile kanban board is now used exclusively for product development. Tasks that can be found on the “day 30” agile board included marketing and general business management projects, which are now tracked separately as their work flow, iterations and review cycles are quite different and not wholly compatible with product development.
It may be hard to see from the photo but this magnetic white board is less than a quarter of the original one that I started with 200 days ago. That one was hardly “agile” – it was a monument. That I thought I needed one that was 48 inches by 48 inches… I laugh at myself and such delusions of grandeur. Luckily that “warehouse of knowledge WIP” has now been freed up to act as a mad scientist’s laboratory-whiteboard where ideas are kept until they are mature enough to move to the agile kanban board Plan section, or until they are eaten up by new, madder ideas. These ideas fight it out within the 48×48 ring, not within the product development flow.
My agile kanban board has been cleaned up quite a bit. Instead of the blue electrical tape to make lines on the board I found a board that comes with a convenient grid of dots spaced 1 inch part. It is nearly impossible to see on the photo above. These grey dots are sufficient to align the tiles under their respective Plan, Do, Check and Act headings. This removes the waste of needing to peel and move the tape each time I adjust spacing, as well as the writing space occupied and wasted by the blue tape.
The red and green magnets are a new addition that will allow me to show progress to plan for each item more discretely. The idea is to use up to 5 for each project, with each representing a work increment of 20% for example. A red X would indicate a problem. There will likely be other creative uses for these colored magnets, as the tasks and who is responsible will vary by project. This requires more upfront planning and work package breakdown for each project.
As such, more space has been allocated to the Plan section of the board. This is not so I can have more things in the Plan stage, this is so I can do more thorough planning. The white space is for notes and comments.The number of items in work or in planning is currently limited to 9 (eight shown, with one blank) but this is an arbitrary number and will no doubt change with experience and turning of the PDCA cycle on the use of an agile kanban board.
The five items in the Do column are not a reflection that I am actually getting more done, but an admission that these have been in WIP for some time. Some were in Plan previously, when the very act of planning itself takes time, adds cost and renders them WIP. If something is purely an idea or has involved not much more work than a few brief discussions, it remains in Plan.
In the next stage of development of the agile kanban board there will be more specific checks in the Check column. That space will contain writing of the result and process metrics I will check. The red and green magnets (x and circle) will show OK / not OK status in the Check column. The Act section will be used to jot down problems, lessons learned and feedback / feed forward items to benefit other projects. We will see how it goes once a project gets to that point.
The agile kanban in its latest incarnation is simpler, more colorful, more fun and portable. I highly recommend experimenting with visual management in this way.


  1. Daniel Markovitz

    January 8, 2010 - 3:27 pm

    Jon, thanks for posting this. I’ve enjoyed following your progress through the kanban journal. Question: how do you allocate time to each item? In other words, how do you manage your personal, finite resource — attention — to these tasks? Do you have an idea for linking your production capacity and pace to the visible work?

  2. Jon Miller

    January 8, 2010 - 8:46 pm

    Hi Dan
    This is a great question. Now that I have done basic “demand segmentation” of things that require my attention and have isolated the routine and recurring items, I think it will be easier to allocate time against these R&D-type projects whose time spend tends to be hard to predict.
    My approach right now is basically to spend all available time after the recurring tasks or emergent items have been addressed on these development items. Also, since a good part of the development work is delegated and done by other team members, getting an accurate read on their time resource can be a challenge. I am sure there is a software solution out there that does all of this, but learning that would be another project on my board…
    Suggestions always welcome.

  3. Daniel Markovitz

    January 12, 2010 - 1:13 pm

    A software developer friend of mine is a big fan of Pivotal Tracker ( It enables him to track and manage software development projects w/o the need for a formal project manager. I’ve looked at it briefly, and I’m thinking that it *might* be adaptable to non-software development work.
    What’s especially nice — and congruent with lean — is the “story-based planning,” which allows you to talk about your work in terms of customer value, not in terms of a feature/product/service you’re building. It keeps the focus where it belongs — on the customer experience — and prevents you from getting too wrapped up in your process or methodology.
    Finally, this post inspired me for my latest post on improving flow in knowledge work. You can read it here: