The most startling result coming out of this year’s just-released Study of Product Team Performance came in response to two questions we asked:
- what methodology does your team use?
- what method do you associate with increased profits?
The cross-correlation of responses to those two questions revealed the startling result:
- each self-identified methodology group – with the exception of those using waterfall – associated increased profits with the method their group currently uses
In fact, the data showed that those groups using waterfall believe that any of the methods other than waterfall would make their product more profitable.
If it were just that those of us who teach or lead agile and lean transformations were associating the methods we advocate with increased profits, that would not be startling.
In fact, the data is quite gratifying – to this agile coach, at least – that members of teams using agile and lean and blends of waterfall with agile and lean, across the board, associate their methods with increased profits. As challenging as agile transformations can be, agile users are not opting to return to waterfall.
What’s startling is that among teams still using waterfall, they just don’t believe in it. Doubly startling given users of every other methodology rate their own method most highly.
You can take a look at the data yourself: the census (who is using what) is summarized in Table 2 on p.16 of this year’s study. If you compare with last year’s 2012 Study of Product Team Performance, you’ll see a strong surge in agile adoption, year over year. (While our book, Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams, is not specific to agile or blended methodologies, we didn’t hesitate to call out the value of agile practices.)
The data that surprised me is in Table 3 on p. 17: the correlation between methodology use and association with profit.
No one (on product teams) believes in waterfall!
The question, of course, is why waterfall is still in use. I would surmise that the answer in some organizations has to do with desire by management to command-and-control (regardless of its lack of effectiveness) – I’ve seen that firsthand – perhaps most of us have – combined with how hard it is to overcome inertia – the effort required to change a long-lived waterfall pattern of behavior that has been passed along for millennia from directing manual laborers. Whether from managers used to giving orders, or developers used to taking them, the habit is hard to change.
But clearly, no one on product teams thinks waterfall is effective.
Thanks for another intriguing blog, Ron! I was deeply involved in product development for about a decade while at HP, and also startups, and can tell you that we NEVER used pure waterfall. We didn’t have a fancy name for it like people do today, but our approach was flexible, adaptable, and . . . well, scrappy! Waterfall is an extreme model in the same way that a “point mass” is an extreme model i physics. It’s a useful mental concept, but not practical in real life of the kinds of products and services that I’m familiar with in Silicon Valley. Of course if I were leading a project where it was impossible to iterate, then waterfall might make sense. I’ve often thought that it would have made more sense to thoroughly spec, test, and fix the Hubble telescope before it was launched into orbit, for example.
Stay Scrappy! – Kimberly