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.
One Response to Finding and Releasing a Product Development Bottleneck