InfoQ

News

Agile Kanban: Visual Tracking Beyond the Team Room

Posted by Deborah Hartmann on Jan 16, 2008 09:54 AM

Community
Agile
Topics
Artifacts & Tools ,
Methodologies
Tags
Kanban ,
Toyota Production System ,
Kaizen ,
Complementary Practices ,
Lean ,
Continuous Improvement

When it first appeared, Agile was largely a developer-driven initiative. As a result, many teams optimized only a part of the software product's "value stream." Once development got sorted out, many teams discovered they'd sub-optimized, i.e. improved development but still hamstrung by constraints outside their control. Lean emphasizes optimization of key bottlenecks wherever they happen in the value-stream - for software, this could be anywhere between the initial request for a solution and the final delivered solution in the hands of the customer. In this InfoQ article, Kanban Applied to software development: from Agile to Lean, Kenji Hiranabe explores the history of Lean manufacturing's "Kanban" visual tracking tool, and how it differs from the commonly-seen Agile taskboard. He proposes that by moving from our Agile tracking systems to the Lean Kanban approach, we can see more far-reaching improvements happen across the organisation.

Hiranabe suggests that teams can use Kanban to increase visibility beyond the teamroom, to encourage real improvement throughout the value-stream. His solutions include Agile Kanban for research-oriented teams with little repetition in their work, and Sustaining Kanban for production-support work, where tasks are more predictable and repeatitious.


The article includes a detailed analysis of the properties of Kanban, and explains how it fits into a process as a tool for Kaizen and to control Work-in-Progress:

  1. Physical: It is a physical card. It can be held in the hand, moved, and put into or onto something.
  2. Limits WIP: It limits WIP (Work-In-Process), i.e. prevents overproduction.
  3. Continuous Flow: It notifies needs of production before the store runs out of stock.
  4. Pull: The downstream process pulls items from the upstream process.
  5. Self-Directing: It has all information on what to do and makes production autonomous in a non-centralized manner and without micro-management.
  6. Visual: It is stacked or posted to show the current status and progress, visually.
  7. Signal: Its visual status signals the next withdrawal or production actions.
  8. Kaizen: Visual process flow informs and stimulates Kaizen.
  9. Attached: It is attached to and moves with physical parts supplied.

The article concludes with an overview of the Toyota Production System. While most software development is quite different from manufacturing, it's this model, adapted for software, which inspires the Lean Software Development movement.



Read the InfoQ exclusive article Kanban Applied to software development: from Agile to Lean, by Kenji Hiranabe.

Related Sponsor

VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
Great article, minor typo by Jason Yip Posted Jan 15, 2008 2:53 PM
Kanbans work great for agile teams by Nicholas Cancelliere Posted Jan 15, 2008 3:39 PM
  1. Back to top

    Great article, minor typo

    Jan 15, 2008 2:53 PM by Jason Yip

    In the conclusion paragraph, I assume that should be "analysed" (or analyzed). Also, I think in the latest version of The Machine That Changed the World, it claims that Taiichi Ohno learning kanban from an American supermarket is an urban myth. Apparently, he observed this from an American style supermarket in Japan. I'm also thinking that the difference in kanban styles can be more attributed to the levels of specialisation/hand-offs in the system rather than the type of development (50 vs 90%).

  2. Back to top

    Kanbans work great for agile teams

    Jan 15, 2008 3:39 PM by Nicholas Cancelliere

    I have had a problem with teams relying too much on web-based tools and email. Team members would interact with these tools more than one another. At some point you hear comments like "Didn't you see my note on the web site," or "I didn't see your email on that." Information in web-based tools or email is easily lost or ignored. They can provide excuses for not communicating responsibly. Kanbans keep a simple view of what needs to get done in front of the whole team. They are very visible and their tactile nature helps clue you in to changes as the board physically appears different. You can also see where work is piling up in a way you cannot appreciate through most web-based tools or by email. Teams are less apt to have too many in-progress tasks open, it becomes quickly apparent when this happens. The team that has switched off the web-based tools and adopted a kanban has seen improvements in collaboration and has demonstrated better self-control in taking on too many tasks at once. It has worked wonderfully. Not every team can utilize them, especially those with members in different physical locations, but if a team is all in one location I highly recommend them.

Educational Content

Bindings, Platforms, and Innovation

This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.

Orchestrating Long Running Activities with JBoss / JBPM

This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.

Neo4j - The Benefits of Graph Databases

This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.

Realistic about Risk: Software development with Real Options

This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.

Communication Flexibility Using Bindings

This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.

Writing DSLs in Groovy

After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.

Scaling Agile with C/ALM (Collaborative Application Lifecycle Management)

IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.

Concurrent Programming with Microsoft F#

Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.