Wednesday, June 10, 2009

Kanban Development Methodology

I was introduced this week to a development methodology called Kanban. For those of you who don't know the origin of the word Kanban, it's manifestation is as a physical card as part of the Toyota Production System (TPS) that signals the moving and production of parts in a "pull" system; a system where parts are made available as others are pulled into use downstream. The objective in a manufacturing setting is to control inventory based on the speed of production. The concept is applied to software development through controlling the development of tasks. In Agile, tasks could be user stories (the parts) which are subsequently developed into software features (downstream production).

The control of requirements, design, and development inventory is important to maximize project efficiency. A main focus of Agile is to gather requirements, design solutions, develop objects, and test working code at the moment they are needed. If any of these areas are far ahead or behind the others then a critical principle of Agile is being violated. Implementing Kanban helps to keep production of objects at each stage of the project at the appropriate levels.

Here is how it works. The team has a board that looks very similar to a Scrum board. It has columns for stages of development. The stages can look quite different. The images contained in this article are a few examples courtesy of InfoQ. Some look eerily like Scrum boards, don't they?

Regardless of the column names, cards start out in the far left column and move their way to the far right column. The inventory of cards at any one category is controled by open slots within a category. For example, using the image with the multi-colored postIts, when a card is pulled from the To Do column and placed in the Doing column, it leaves an open slot in the To Do column thus a need for more To Do items to work on. Unlike Agile, Kanban does not bundle work into sprints. The flow is constant.

In my opinion, where Kanban is most effective is on larger projects where there are teams that make up "columns" of work. The image with the Waterfall style stages illustrates this best. A large project will likely have teams that make up Basic Design, Detailed Design, Development, and Validation. With Kanban, each team can set their capacity of work by the number of slots they make available. If the Basic Design team has 10 slots available then they are saying they can work on 10 basic designs at one time. Detailed Design may have only 7 slots, thus their capacity is 7 Detailed Designs at a time.

It isn't hard to imagine Agile teams using Kanban techniques to control the flow of work. A simplistic view is to wrap Kanban into iterations and you now have Kanban Agile. There are additional difference between Agile and Kanban and I provided a couple of links at the bottom of the page if you are interested in learning more.

In a previous article, The Convergence of Continuous Integration and Continuous Release, I discuss the merits of deploying to production immediately after code is checked in and all test are run and are successful. Kanban would work exceptionally well in this type of environment.

Whether it's Agile based on Kanban or another style of Agile, there is a consistent attribute of Agile teams; the Agile team needs to be composed of multi-faceted team members who are adaptive. As production velocity shifts across any or all categories of the project, team members should be able to shift into different roles accordingly, i.e. gathering requirements, designing solutions, developing software, and/or testing working code (or coding automated tests). Personally, I think this makes being a software development professional more interesting but it isn't for everyone.

Click here and here to read two good articles on Kanban as it relates to Agile software development.

I'm interested in your thoughts.

2 comments:

  1. Kanban is a good working model for goods manufacturing. It is interesting, trying to adapt/fit it to software development (software not manufactured, instead developed).
    In Kanban method, when a slot become empty it is always replenished with the same part. But, in software development filling an empty slot will be challenging (note, the article mentions, people should be ready to take different roles so that empty slots at any column in the down stream could be filled efficiently), since it involves people's special skills, working platform, dev. environments and etc. Sometimes even if the person has skills, switching the gears not easy. That is filling the kanban slots in software development may not be as efficient as it is in manufacturing.
    Manufacturing is a sequential process, no iterations needed. Software development unlike to manufacturing goes through several iterations before shaping up as a finished product. Due to this simple reason the people (the roles) need to standby (looking for tasks, just like a fire fighter) in their roles all the time till the product is finished and released.
    By the way, it is a great thought though..

    ReplyDelete
  2. The initiation processes determine the nature and scope of the project. If this stage is not performed well, it is unlikely that the project will be successful in meeting the business’ needs. The key project controls needed here are an understanding of the business environment and making sure that all necessary controls are incorporated into the project.

    ====================
    Project Management Software

    ReplyDelete

Web Analytics