Bad things can happen to a project if the Product Owner doesn’t manage the story pile. And consequently bad things can happen to the software development team that is cast adrift in the doldrums.
There are many reasons why a software development team might lose productivity. One that is often overlooked – especially in discussions of extreme programming – is when the Product Owner fails to drive product from the team. Maybe the market research hasn’t been completed. Or maybe the project stakeholders can’t agree. Maybe there is no clear vision. Or maybe this is a research project with a “let’s see what turns out” approach. Whatever the cause, the effect is a Backlog with too few stories in it. Or worse, a Backlog with conflicting stories, and stakeholders who bicker at the iteration review meeting.
Textbooks and training courses tend to give developers the impression that the Backlog just appears, manna from heaven, perfect and always in just the right amounts. No-one told them what to do when that isn’t the case. Most teams will fail to notice the situation for some time, and will fall into destructive behaviour. The developers with a strong technical sense will push for the addition of ‘obvious and essential’ architectural stories to fill the gaps in the Backlog. At the same time those with a domain background will just ‘know’ what is the right direction, and will push for new stories to support their own personal hobby-horses. Those who need strong leadership will fall into despond, and the more vocal of these will cast a cloud over the team room and everyone in it.
If the story pile continues to be under-managed, the team’s worsening morale will inevitably affect productivity. (I attended an iteration review meeting recently in which the developers demonstrated no new features and the Product Owner came to the table with no new stories – and yet everyone knew there was loads to be done and very little time in which to do it! In order to fill the vacuum some of the developers began tabling their pet stories for consideration. Chaos ensued and, unnoticed, morale slipped another notch.)
Look at the problem from a slightly different perspective. All of the agile software development methods share their underlying principles with lean manufacturing. Productivity is based on short cycles and interlocking feedback loops. And the pace of development is set by the arrival rate of kanban – story cards in our case. The whole basis of agile software development relies on the Customer pulling features from the production team. And the rate of pull must be sufficient to drive the cycles and feedback loops. The supply process will disintegrate when there is insufficent demand.
Update, 18 Apr 05
For a ‘theory of constraints’ take on this story see the product owner must pull (revisited).
6 Replies
[...] When the bottleneck is outside of development, it often seems as if we have a sportscar being pulled along by a donkey. And the message from Rittal is clear: as long as we retain functional divisions, the [...]
[...] manufacturing concepts – such as pull, jidoka, gemba etc – can be applied to software development with positive effect (see Lean Software [...]
[...] the product owner must pull (revisited) [...]
[...] productivity are going to follow. (I mused about the very same thing for software development in the product owner must pull and the product owner must pull (revisited) last [...]
[...] make some changes for the iteration review meeting. One month ago the day had gone very badly (see the product owner must pull), so today we needed to recover a great deal of lost trust, credibility and morale. Here’s [...]
[...] one comment 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 [...]