Agile vs. Waterfall
Recently I came across an article on the Dummies.com website comparing the traditional Waterfall method (Phased and Gated) to the Agile method of product development, which I think merits a rebuttal. In my opinion, traditional product development isn’t really "pure Waterfall." And in fact, in most product development initiatives I have observed over the years, traditional product development is already in the grey area between pure Waterfall and pure Agile.
In the final paragraph the author notes:
"Mixing traditional project management methods with agile approaches is like saying, 'I have a Porsche 911 Turbo. However, I'm using a wagon wheel on the front left side and right rear side. How can I make my car as fast as the other Porsches?' The answer, of course, is you can't. If you fully commit to an Agile approach, you have a better chance of project success."
As stated above, traditional product development isn’t really "pure Waterfall." And in our experience, a mix of several product development methods gives us the best results. The right product, delivered quickly, at the right price and with the best quality. This mix of Agile and Waterfall and other methods is what we call Lean product development.
But let's look deeper into Waterfall (Phased and Gated), its limitations, as well as how it gets implemented in a Traditional project.
Waterfall
Waterfall is very linear and restrictive in its purest form. The project moves to the next phase only when the previous one is complete.
1. Requirements
2. Design
3. Development
4. Integration
5. Testing
6. Deployment
Traditional project management for product development
However, Traditional project management in product development looks more like this:
-
1. Requirements
a. Build up big list of requirements, try to make them all correct (what the market will actually love and buy), solid (unchanging), and "must do."
b. Pretty much believe that it’s possible to do such a difficult thing as know, in great detail what our customers really will love. This assumption is often based on the fallacy that the customer actually knows what they want before they actually get to hold and use it. -
Design
a. Conceptual design, architecture development, a few experiments/feasibility tests
b. Adjust requirements some -
Development
a. Design refinement (Complete detail drawings of each component.)
b. (Release)
c. (Order/receive/inspect parts.)
d. Integrate and test Subsystems
e. Integrate and test whole product (not always done on the first time through this loop)
f. (Often too late, but usually here on loop 3+) deploy a little. (Have production try to build a few. Have customers try the beta units and give us feedback.)
g. Adjust requirements when necessary.
h. Repeat 3-7 times
On the last time through, we’ve met our requirements well enough to finally deploy and launch the product. We don’t necessarily know until we get here that we are finally here. -
Deployment (ramp up manufacturing and launch)
a. Really, deployment is another test. This time, the test is of the manufacturability and marketability of the product as well as more "does it work" tests as it hits more real-life conditions. Some products hit these real life conditions for the first time in the process.
b. Often we have to do a few more 3a-g development loops if we didn’t get enough manufacturing or market feedback earlier.
Traditional product development does include iteration
So you see, Traditional Product Development is really more iterative than many give it credit for, whether or not people doing Traditional Product Development want it to be.
Traditional product development tries to do #1, #2, and #4 once, but they can’t, really. This is why there are 3 - 7+ loops inside of Development (usually 2 - 3 planned, 4 - 7 actual), and often a few in Deployment (4b) when the 4a tests tell us we still have stuff to change. It’s largely because they make the assumptions in 1b.
I am not arguing that this approach is ideal, only that there is iteration in the process.
Agile doesn’t try to do any of them once. It recognizes the fallacy of the assumption in 1b, and the best way to combat it is to get to Deployment (4a) faster. In an Agile approach you try to get to each subsequent step as early as possible. However, this is only possible by stripping out a lot of the requirements (debatching requirements). In both cases, the "real world" testing of the complete product doesn't happen until the full product is manufactured and put to the test in the real world. This is one of the reasons why pure Agile doesn't work for hardware manufacturing. I delve into this conversation in this series of posts.
But really in most cases, traditional product development does some Deployment during Development (3f). The trick is to do it earlier, in smaller batches, by not trying to meet too many requirements in the early iterations.
Traditional product development already doesn’t try to meet all of the requirements the first time through the process. For example, requirements such as ensuring the product costs as little as possible, looks great, weighs as little as possible or is as small as possible, usually come in on the 3rd or 4th iteration, after we have met the basic functional requirements.
There is more Agile in traditional product development than some think. Where pure Waterfall is black and pure Agile is white, traditional product development is really kind of a darkish shade of grey. In my opinion, the trick in hardware is to lighten up by becoming more Agile in the right ways for hardware development, but not to strive for pure white – it won’t work. It’s a different kind of system.
We are already a little Agile for good reasons – we don’t know everything and so we have to iterate and learn. Now we can just recognize why it works, and use that knowledge to build faster project development systems that iterate (and learn) faster.
And we absolutely don’t have to pick one or the other. The magic is in the right mix in the middle.
----
The real cause of project delays is not what you think. Find out in this 9-minute video then watch part 2, a demonstration of Playbook where we show you how Playbook solves for these issues.
Related articles
Agile Development
Applying Agile Values to Hardware Development
Agile Principle 1: Early and Continuous Delivery of Value
Agile Principle 2: Welcoming changing requirements
Making Hardware Development More Agile
Early Learning in Hardware Development
Agile Principles 4 - 12 to Hardware Development
