InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Agile Kanban: Visual Tracking Beyond the Team Room

Posted by Deborah Hartmann Preuss on Jan 16, 2008

Sections
Process & Practices,
Architecture & Design,
Development
Topics
Artifacts & Tools ,
Methodologies ,
Agile
Tags
Kanban ,
Kaizen ,
Continuous Improvement ,
Toyota Production System ,
Lean ,
Complementary Practices

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.

  • This article is part of a featured topic series on Agile
Great article, minor typo by Jason Yip Posted
Kanbans work great for agile teams by Nicholas Cancelliere Posted
Re: Kanbans work great for agile teams by Joshua Ewer Posted
Re: Kanbans work great for agile teams by David David Posted
Online Kanban Tools by Sergei Podbereschi Posted
Re: Online Kanban Tools by Morgan James Posted
Lean Project Management & Realtime Analytics by Thomas Schranz Posted
  1. Back to top

    Great article, minor typo

    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

    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.

  3. Back to top

    Re: Kanbans work great for agile teams

    by Joshua Ewer

    Completely agree. I had issues introducing Scrum to a team that had "done agile" (i.e. they had standup meetings). We have MS Team Foundation Server holding all of our work items and scenarios, which is nice, but that tooling completely abstracted how items should flow through a process and ended up being a detriment.


    A physical board, while seeming really low-tech, is the perfect way to illustrate the health of a project and keep people on task. I don't know how I'd do it w/ a team that wasn't co-located, but once we saw it done once physically, then we re-introduced tooling which much more success.

  4. Back to top

    Re: Kanbans work great for agile teams

    by David David

    Good article, thanks.
    I started using kanbantool.com after I first heard about Kanban for personal use. Then my manager decided to test it within our company. People were delighted at first, productivity increased but after 2 weeks started problems with task limits. Some people were overloaded. Our managed decided to the same limit for everyone-and now everything works smoothly.

  5. Back to top

    Online Kanban Tools

    by Sergei Podbereschi

    For an online Kanban app, I would recommend checking smartQ - www.getsmartQ.com.

    Kanban has a potential to be applied not only to software development, but to many other industries - from marketing and HR to service shops.

  6. Back to top

    Lean Project Management & Realtime Analytics

    by Thomas Schranz

    We're currently working on a new tool for lean project management: www.blossom.io It combines lean software development methodologies with realtime analytics of KPI.

  7. Back to top

    Re: Online Kanban Tools

    by Morgan James

    I work in a company with diversified staff in terms of IT skills. The tool we use - KanbanTool - is simple and intuitive for employees of lower level. On the other hand it is also an advanced and flexible support for managers. This is what we needed to organize our work.

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.