A Kanban System for Software Development

November 23, 2007 by Karl Scotland

This post can now be found here.

Posted in Karl's Chaordic Collection | Tagged Kanban | 12 Comments

12 Responses to “A Kanban System for Software Development”

on November 24, 2007 at 4:23 am1 Merlyn Albery-Speyer

Hi Karl, thanks for the post. It’s made for an interesting read.

Our team is using Scrum and haven’t yet reached the point where we could clearly identify the need to switch. I’m curious, how long was your team using Scrum before switching over? Also, how are you measuring Velocity now?

cheers,
merlyn

PS What do you mean by t-shirt sized?
on November 24, 2007 at 9:14 pm2 Chris Sims

I once led a team that built shrink-wrapped software using a modified version of XP. For this team, release planning played an import role in solving the problem Karl describes. The team modified the XP notion of ’stories’ into something they called ‘features’. We didn’t have the ‘Minimum Marketable Feature’ terminology, but that was the idea.

At release planning time, we would discuss each feature until the group seemed satisfied that they understood what was involved. We would then estimate the size of the feature, as a group. Our units were ‘Ideal Hours’ and we limited our granularity to Fibonacci Numbers (…3, 5, 8, 13, 21, 34…). Each developer had a small deck of note cards with a single Fibonacci number on each. At the same time, we would each hold up the card with our estimate. Usually, we quickly had consensus.

When our estimates didn’t agree, we would dig deeper to find out why. Sometimes the feature need to be further clarified. Occasionally, one member knew of a technical hurdle or shortcut that the others did not. Other times the feature was too big to get our heads around and we would ask the product owner if it could be broken down into smaller sub-features, that would still be valuable.

The product owner developed a sense for which features were likely to be difficult for the group to estimate. Before the planning meeting, he would often seek out members of the development team and consult with them to confirm his suspicion and seek ways to better define or perhaps divide the feature. This helped minimize the number of times the team got stuck during release planning. The result was that release planning didn’t take long, and we walked out with a plan that each person understood and believed in.

When we planned a sprint, or an iteration, as we called them. We would have a developer own each feature. That developer would do their own estimate in terms of ideal hours for them. Since the feature had already be defined well enough for the team to make a consensus estimate at release planning, individuals usually felt that they had enough information and understanding to make their own personal estimate at iteration planning time. Letting the person who was going to be responsible to deliver the feature own the estimate allowed us to better plan the iterations by taking into account things like experience level, new information that had come to light, and so forth.

Both release planning and iteration planning went smoothly and produced useful estimates. The team maintained high morale and delivered a series of releases on time, feature-complete, with verifiably high quality.
on November 28, 2007 at 12:16 pm3 Karl Scotland

> What do you mean by t-shirt sized?
Hi Merlyn,
T-shirt sizing is a high level way of estimating the relative size of Features/Stories/MMFs, generally using the range XS, S, M, L, XL. It gives some indication of cost, without having to be too precise.
Karl
on November 28, 2007 at 6:16 pm4 agilesWissen » “A Kanban System for Software Development”

[...] Scotland published a readable article about usage of “Kanban System” in software development: … The goal of a Kanban [...]
on December 9, 2007 at 9:55 pm5 Kanban for Software Explained — blog.mattwynne.net

[...] Scotland has posted a great description of how his team solved some issues they were having within their Scrum team by moving over to using [...]
on December 14, 2007 at 9:03 pm6 Klaus

Hi Karl,
I have dealt with Kanban and eKanban for over 10 years now, and this is the first time to read how it was or could be applied to the software development process. I think it is really worth to think and experiment with this approach.
Greetz, Klaus
on December 15, 2007 at 4:31 pm7 Idetrorce

very interesting, but I don’t agree with you
Idetrorce
on December 19, 2007 at 2:54 pm8 Karl Scotland

Idetrorce - can you say some more about what you don’t agree with?

Karl
on January 2, 2008 at 2:11 pm9 Rob Hathaway

Hi Karl,

I’ve been using Kanban with teams that want to go Agile quite a lot recently. I find the Work In Play limits help teams focus on getting stories fully complete rather than getting everything out of dev and into test and therefore helps the value flow through the system.

The other thing I’ve found is it reduces the vast amount of time teams seem to want to use doing Sprint Planning…the ultimate goal of the meeting is simply to make a commitment to the stories for the next iteration/sprint. The quicker you can reliably do this the sooner you can actually get on with delivering the stories and their value.

Kanban can save teams going Agile a ton of time early on when they don’t have a good idea of velocity but have a pile of work to get on with.

I’ve also found that having teams focus on lean principles (Muda, Mura, Muri - check out Wikipedia for details) can be really useful so that people think about what they’re trying to achieve rather than how they’re going to do it which focussing on Scrum or XP or other specific Agile methodologies can sometimes lead to….it helps people build a more adaptive process.

Rgds

Rob
on January 16, 2008 at 12:55 am10 Kanban For Software Explained… Some More. — blog.mattwynne.net

[...] while back I alerted you to a post Karl Scotland on his implementation of a kanban system for producing software. Kenji Hiranabe has [...]
on January 31, 2008 at 9:54 am11 Johan

Hi Karl,

Thanks for a great post, to me this highlights the impoertance of having a shared goal that the team as a whole understand and is committed to. And also hints at a difference in approach between dealing with new development and maintenance. I am guessing that this project was dealing with a completely new application.

Do you think your situation had been different had you had a ‘mission statement’ published on your information area (wiki | whiteboard | wall | window, whatever you were using)? Or if you’d been involved in enhancing an existing product?

I am currently in a situation where we are shifting to agile, from a situation where (M)MF’s are handed to individual developers, who start their own workstream, which then goes into a (not yet identified) release. Since we are woking on an existing system, and these (M)MF’s can vary from new features, bugfixes to legislation compliance I am leaning to a kanban solution.

Having this flexibility to have a ‘living’ backlog and an ‘override’ slot I think is a good way to handle projects that deal with maintenance of an existing live product. Especially when you, as we do, have reengineering efforts and maintenance running in parallell. In these short cycles it would allow a critical production issue to override a reengineering effort in a way that a monthly release cycle in standard Agile would not. The exception is if you plan for it in advance (which goes gainst the idea in my view), or handle it outside of your project (which steal your resources and affect your release anyway).

For these ‘mixed scope’ efforts, I think I will from now on seriously consider a kanbanesqe approach…

//Johan
on April 2, 2008 at 12:51 pm12 Kanban Experiences « AvailAgility

[...] A Kanban System for Software Development [...]