Finding and Releasing a Product Development Bottleneck

With iterative software, we talk about doing all the necessary functions, such as Design, Develop, Inspect, and Release, within each cycle to increment the value of available software to the customer. Our team divides the things in progress in to these categories, and has a finite amount of slots available to each category.

Friday after the daily stand-up found me, the Product Owner (PO) and the Lead Developer discussing a constraint to work. The Design category is done with its work, but the ready slot for Development is full. The team cannot pull any work in to this area.

The Product Owner wants to give more work to the Designers. I point out this is a push and we really want to refrain from dispatching work out to individuals. Staying focused in on the Designer area, the PO wants to know why we cannot just add more ready slots for Design to put finished work in to, and allow more work to be pulled in. We discuss how the system is designed at limiting the amount of things in process, and this may not be the best idea.

Suggesting we pull back and look at the whole board, we noticed that it is Development that cannot pull more work in to their area, because they are completely filled up with work that is not finished. There is one gnarly task to fix all high-priority defects. It is a worthwhile goal, but perhaps too costly to try and battle them all.

The Lead Developer is watching our discussion and chimes in with something another senior developer has brought up before, batching up the top 5 and parking the rest. These are lower priority than other queued-up feature work. It is pointed out that really, not everybody is working at fixing defects as wanted. There is other work in progress in the Development area.

This is completely agreeable to the PO and so the work is now to enumerate those top 5, which will also help with the Inspection and Release areas to deal with a manageable batch size, too. Soon this should relieve the constraint and allow Development to pull in the Design ready work, freeing Design to concentrate on pulling in new features to work on.

It was so easy then to point out local optimization. Now with some humor and looks relieved of their tension we can chuckle about optimizing one person in Design, instead of dealing with what is really slowing things down at the moment. We part ways with a better understanding of what is going on. Happy to help in making an improvement, we know throughput will soon be on the rise.

This entry was posted in #agile explained and tagged , , . Bookmark the permalink.

One Response to Finding and Releasing a Product Development Bottleneck

  1. tobias says:

    On the other hand, if you had a time-boxed iteration, with a set of stories committed, a clear separation between the What and the How, and a team of designers, developers and testers who worked together in a collaborative fashion then isn’t the problem already solved?

    I can see why this appears to be a good thing, and indeed in the circumstances the conversation and the result were indeed good, it still has a ring of micromanagement to me. The PO and the Scrum Master shouldn’t have their hands that deeply (or at all) into the How of development.

    I am reading your blogs and trying to understand this approach, but I am not (yet) getting it. I am most certainly not seeing this as “advanced Agile” as it is currently being touted. I look forward to talking with you at Agile2008.