From scancards to “personal kanbans” and Ybry charts

Professionals know that their productivity drops when they take on too many concurrent projects. An engineer whose attention is split across 15 projects doesn’t contribute effectively to any. But it happens because supervisors keep piling on assignments without regard to this phenomenon. Over the years, cures have been proposed under different names, all aiming to cap work in process.

About 1982, a colleague showed me the system he used to manage what he was working on. It was called the Scancard System, and it used the hardware  in Figure 1. The cards were square, with 3 1/4-in sides and borders of different colors. They came with letter-size card pocket plastic boards that you could insert into 3-ring binders, keep on your desk or pin to a wall.

Figure 1. The Scancard System

He used it with one column for his backlog of things to do, one column for work in process, and one column for completed items. It was a paper-based system but, at the time, so was almost everything we did. It gave you visibility, it capped the number of items you were working on at one time, and moving cards from one column to the next was an effective metaphor for the flow of your work. The ads showed smartly dressed managers using their scancard systems in meetings. I went for it and used it for years, until I had a project with a company that used another system and switched to fit in.

Fast forward to 2011. Scancard Systems is out of business, and I hear of a system called “Personal Kanban,” that is focused on providing visibility and limiting work in process, using a white board and Post-Its as in Figure 2:

Figure 2. “Personal Kanban”

I put quotes around the name because I find it to be little more than a feat of vocabulary engineering, leveraging the buzz around a feature of Toyota’s production control system to repackage ideas that have little to do with it, are very simple and have been around for a long time. A software developer visiting a factory may see a similarity with Toyota’s Kanbans, but it escapes me.

Of course, if, as in Figure 2,  it is on a white board, you can’t carry it with you to a meeting or share it in your network. The Personal Kanban website advertizes an iPhone app called iKan, that I can’t find on Apple’s App Store. On the other hand, Leankit Kanban offers a web-based application with an iPhone version that looks very much like a team to-do list management system. It looks most useful if your work can be perceived as a collection of independent activities, which happens if each Post-It is for a whole project or for a prospect in a sales cycle. But it would not fit if each Post-It were for a task within a project, with precedence constraints or iterations between tasks.

Another limitation of such a status board is that is only shows current status, as compared, for example, with the Ybry chart of Figure 3, which shows the complete history of each project by using a line for each project rather than a card. Like the status board, it assumes that all project go through the same sequence of phases.

Figure 3. Ybry chart for projects going through the same sequence of phases

Ybry charts were invented by Charles Ybry in 1846 for railroad scheduling, and are still used for that purpose. See Edward Tufte’s Envisioning Information, pp. 107-110. The work-combination charts used in Lean operator job design are a variation on this method, as explained in Working with Machines, pp. 133-154.

9 comments on “From scancards to “personal kanbans” and Ybry charts

  1. Pingback: The personal kanban: not just “vocabulary engineering.” |

  2. Sadly, this is such a typical industrial engineer’s reaction to use of kanban systems in knowledge work and personal productivity – focused on practices and failing to recognized shared principles.

    Would it surprise you to learn that kanban systems were not, in fact, invented by Toyota, and in fact pre-date industrial manufacturing by several hundred years? Kanban (meaning single (usually wooden) tokens), used to represent and limit quantities of scarce resources, used in sets and circulated in systems have been in use for hundreds of years in Japan. Taiichi Ohno observed just-in-time restocking of shelves in American grocery stores and realized that he could use kanban to signal the restocking. The Toyota kanban systems evolved from that initial insight and the recognition that controlling inventory inside the factory and providing predictable lead times, was desirable.

    If you start from the same principles that control WIP and providing predictable lead time is valuable for personal or knowledge work where do you go from there? Invent something entirely new or take inspiration from hundreds of years of existing knowledge and results?

    When you apply principles to a new domain, new specific practices evolve. These may not look like practices from another domain – this doesn’t make it wrong, or a “feat of vocabulary engineering.” It shows a depth of insight and a recognition of underlying principles.

    • Spoken like a typical… What? I don’t think in those terms. You are an individual. I would not presume to reduce you to just a member of a group, whatever that group may be. If you can use the Kanban label to market the idea of putting a cap on the number of projects a group works on, that’s wonderful for you.

      For me, the loose usage of the term Kanban — in manufacturing and other fields — impairs communication. Likewise, if you consider coins and credit cards to be the same thing because it’s all money, you make it difficult to discuss the specifics of each.

      In contemporary everyday Japanese, a Kanban is a shingle that you hang outside a store, literally a “board you see.” If wooden tokens have been used in Japan for hundreds of years, I would appreciate it if you could tell me by whom, when, for what purpose and in what form.

      I have heard the story of Taiichi Ohno visiting a supermarket in the US as the origin of the Kanban system. Given that supermarkets don’t use Kanbans, I find the story not quite believable. It sounds like the output of a PR department. I have heard another: when Toyota was nearly bankrupt in 1950, it couldn’t pay for full trucks of parts. Allegedly, Kiichiro Toyoda came up with the idea of reordering exactly the quantity of parts that was on cars actually sold, which the company could afford. The circulating cards then became a convenient way of counting that quantity and placing orders. It may not be true either, but it makes more sense to me.

      Best regards.

  3. Comment in the Lean Six Sigma discussion group on LinkedIn:

    No it does not [resemble Toyota’s version] Michel. But it achieves the same results as the manufacturing Kanban; namely limit the work in progress using a signaling mechanism. I am a big fan of it and would advocate its use for any organization that wants to evolve into agile methodologies.

    • There is more to kanbans in manufacturing than limiting WIP. For example, kanbans tell operators exactly what they should be working on and in what sequence. No judgement call required. Move kanbans also replace routing slips, by specifying items, quantities, origins and destinations.

      • Comment in the Lean Six Sigma discussion group on LinkedIn:

        I agree with you Michel. The fundamental use of a Kanban in manufacturing is to limit production to as you said – tell the operators what to work on, when to work on, how many units to produce and where to deliver the items.

        However, in software engineering the same widget is never produced twice. There is significant variation in the work. This variation gives rise to high WIP – call it lack of synchronous pull. This is specially true when the same team does multiple work types. Also, the concept of takt time is ridiculous in software. So, how else would one create a synchronous pull in this chaotic work of software engineering. So David Anderson and a few other folks created Kanban for Software engineering as we know it to enable that synchronous pull based on the teams flow or capacity to do work. And it works. I am chronicling my experiences at

        Joel, while Kanban adheres to agile concepts, it is not Scrum. Scrum contains timeboxed iterations and needs a deliverable at the end of each iteration. Kanban does not timebox. Both Kanban and Scrum limit WIP, but differently. Scrum limits WIP within each iteration while Kanban limits WIP based on flow. Folks using Kanban pull work based on availability. Kanban enforces only two policies:
        1. Visualize work in progress
        2. Limit work in progress

        Adopters of Kanban customize the remaining policies that fit their culture around these two principles.

        Yes – Kanban for software differs from Kanban from manufacturing. However, the core principle remain the same – limit WIP to increase throughput.

  4. Comment in the Lean Six Sigma discussion group on LinkedIn:

    In the software world it is called Agile/Scrum I believe, very big movement started about four years ago here in the silicon valley. Essentially, software and qa resources extract and plan a project down to the smallest task based on the requirements and have daily scrums (10 minute meetings) to share in the progress, blockers, completed and next up.

  5. Pingback: From Ybry charts for railroad scheduling and project management to work-combination charts | Michel Baudin's Blog

Leave a Reply

Your email address will not be published. Required fields are marked *