Also, I fail to understand why one can’t reach the bottom of the waterfall with ALL the water that’s been tumbling down still in play from each step of the process, with an incremental richness being added as the project progresses. If you have a big team, you get nowhere by starting with 25+ people in the room yelling (including the inevitable database guy who’s a frustrated marketing guru) and arguing over who gets to play with the post-it notes.

And what’s to stop you reaching the bottom and (Escher-style) heading back up to the top?

Bitter experience teaches me that if you mix up different colours in a hot wash, you end up with a murky pink that nobody is quite happy with.

But call me an old-timer, but I’m not sure I completely agree. It’s definitely important that everyone be involved, that everyone have a stake in the final product, and that everyone feel responsible for the total finished experience. But I still think that we all benefit from some specialization.

I’ve seen brilliantly bad marketing ideas come from developers, just as often as I’ve seen so-called “product people” try to influence technical decisions. We all have our stories about “engineering UI” or technologists that get “promoted” to managers.

I think what it boils down to – and what I think you’re saying – is that everyone needs context. Product people need to know what’s possible in the technology, so they can use their background and experience to build a great product. Designers, too, need to know what can and can’t be done, and what tradeoffs they can make that will influence downstream (slipstream?) technical decisions. Engineers need to know the goals of what a product is supposed to do, so they can make choices along the way of what and how to use the technology best. And QA and operations people need to have context so that they can test and deploy in a manner that they believe people will actually use the product, not just the way that it’s spec’ed to work.

I believe that’s true whatever your development methodology. There are some great (large) products I’ve worked on that were developed using a waterfall approach, but they succeeded because we knew not just what but also why we were building it. Conversely, I’ve seen other experiences where you can put a bunch of people in a room, put them in the spin cycle, and all that comes out is agitation.

Call it a washing machine, call it a waterfall, but I think that the key is to remember that everyone in the team’s swimming in the same water – connected to the same lifeline. If one guy sinks, the whole team goes down.

What I see happening in software development is akin to the quality revolution in manufacturing. Software development is a process and the state of the art for process improvement is are the techniques spearheaded by Japanese manufacturers.

It follows rather strictly what you are endorsing in your post: get all the stakeholders in the room and discuss ways to improve the process and as a result increase the quality of the delivered product.

Yes, the design-release cycle is dying becuase software is evolving into a continuous process… Google slips new features into their services… Firefox updates frequently…

Getting design, marketing, sales and even users into a discussion about improvements is a natural “quality circle” and is incremental improvement rather than re-design.

Thanks for the writing prompt! I’m saving this for my own blog.
NOTE: All ideas are free. Use, re-use, extend or revise at will.
Check our Six Sigma and any other modern quality methodology for more ideas on software improvement as process.