the product owner must pull (revisited)

In the product owner must pull I described what can happen when there are not enough stories in the pile. Here I want to look at the same problem from a slightly different angle: in terms of the Theory of Constraints.

The development team’s throughput is low. TOC says that the organisation must therefore include a Constraint (a bottleneck). The Constraint is the major factor in causing that poor productivity, and our first step is to IDENTIFY it. In software development, one of the easiest ways to find bottlenecks is to look for stuff piling up. In this case we find that the constraint lies outside the team, in the person/process/team that creates the story pile. There are piles of visions, wishes and capabilities waiting to be analysed, but downstream there’s no work for the developers to do. The constraint is the analysis function.

Our second step must be to EXPLOIT the constraint – to get it functioning on full power. In iterative backlog management I adopted Scrum to help the analysts generate stories and incrementally build a pile of stories for the developers to work on.

Third, we must SUBORDINATE everything else to the constraint. In this case we decided to stop development for one iteration. In lean manufacturing terms the development has no customer pulling features. So instead the development team will carry out some maintenance work: refactoring the codebase (tidying gemba), improving test coverage, installing new tools etc. (As things turned out, analysis generated some high-value stories quite quickly, and so we were able to re-start development on those stories before the end of the current iteration.)

Fourth, we must ELEVATE the constraint. Which means we must look for ways to make the current constraint more productive, or else eliminate it from the production flow. In our example this probably won’t be an issue. As the analysis team settles into being proactively managed it looks to be capable of creating stories faster than they can be developed.

Which leads us to the final step: we must PREVENT INERTIA and re-start the process with step one. Now that analysis is creating a story pile and development is working on it, we need to IDENTIFY the system’s constraint all over again. This time it will be somewhere different, and again we’ll find it by looking where things seem to be piling up…

Advertisements

iterative backlog management

When the Product Owner doesn’t have enough stories to drive development, try running an incremental analysis project that keeps one iteration ahead of the developers. The deliverable from each analysis iteration is a modified Product Backlog, ready for the upcoming development iteration’s planning meeting.

Whatever the reasons, it’s sometimes a fact that the Product Owner just doesn’t have the backlog prepared in time for the next development iteration. This can have a destructive effect on the development team’s morale and productivity, and must not be allowed to continue for too long. So something we’re trying on a current project of mine is to set up a parallel “analysis” project, to be run using the Scrum process. (This is certainly not a new idea; for example, Martin Fowler talks about this technique in Planning and Running an XP Iteration.)

I expect the mechanics of the two projects to work something like this:
Continue reading