How the Kanban method changes software engineering

By Matthew Heusser, CIO |  Software, Kanban method

Analyze > Specify (acceptance test cases) > Write the Code > Exploratory Test > Deploy

Make the work visible in a manner similar to the whiteboard below from a recent consulting client:

This Kanban whiteboard lists the tasks down the side and the steps in the process along the top. There's literally no room for multitasking.

Now limit the work in progress for each step. This eliminates multitasking and what I call the "massively overflowing inbox effect." (Shortly after this picture was taken, the team removed the "ready for QA" column.)

For metrics, stop tracking story points or making estimates. In fact, give up on estimates entirely. Instead, count the number of stories that flow across the board per week. That's the throughput. A second measure is the cycle time-the time from when a card is actually picked up to be worked on the far left side of the board to when it is pulled off the end of the board for deployment.

That's a Kanban.

There's a different way to look at it. Take a basic scrum process, in which the team takes a two-week batch of work called a "sprint," which itself is built out of micro-features called stories. From there, make an entire system state and all associated workflows visible by use of a board. Next, figure out how to deploy each story individually. Get the stories to be about equal size, limit work in progress (to achieve "pull") and drop the sprint boundaries.

Once again, we have a Kanban.

Press Ganey: A Kanban Adoption Story

Shawn Kohn is one of two directors of software development at Press Ganey Associates, with direct leadership over five large development teams. Eighteen months ago, all those teams were using a scrum-like model, complete with fixed time-period sprints over a collection of estimated micro-features. Today, those teams are either using a Kanban process or transitioning to one.

When the subject of Kanban comes up, Kohn is quick to point out that Kanban started with internal IT projects-for a reason. With a large number of very small systems, there is no regression test phase, which makes one-piece flow easy. There are rarely hard deadlines, and the work is generally small.

At Press Ganey, the first team to try Kanban was actually a new team doing a greenfield project, which was similar in that there was no regression-test phase. The work was an internal efficiency project involving a number of new, but small, applications and changes to existing applications, all of which kept regression testing to a minimum.

Originally published on CIO |  Click here to read the original story.
Join us:






Spotlight on ...
Online Training

    Upgrade your skills and earn higher pay

    Readers to share their best tips for maximizing training dollars and getting the most out self-directed learning. Here’s what they said.


    Learn more

SoftwareWhite Papers & Webcasts

See more White Papers | Webcasts

Answers - Powered by ITworld

ITworld Answers helps you solve problems and share expertise. Ask a question or take a crack at answering the new questions below.

Ask a Question