It should be stated that iterative development does come with a cost in that it takes longer to execute than the ideal case sequential development. You trade risk reduction for more work.
The ideal case presumes that everything is known when the sequential development is planned, which is what permits it to be optimized.
But in my n=1 experience, everything is not known, the development team is constantly discovering new information, requirements change, and the ideal plan never works out as originally envisioned, whether we tried to develop sequentially or not.
But the “ideal” plan is often like highly optimized code: Expensive to change. So it has its own cost that cannot be escaped. So I am left extremely cynical about the “ideal sequential development” approach.
It always seems at the outset to be cheaper and faster, but ends up being expensive and inflexible.
JM2C.
——
Now if you want something REALLY expensive, I give you “Scrumfall,” a plan where you combine the costs of iterative development with the inflexibility and attendant costs of fixed date, fixed scope, and attempt to optimize sequential development.
But hey, you get to wear an “agile” badge, even though “inspect and adapt” has no place in the process.
>> So I am left extremely cynical about the “ideal sequential development”
Off course, in development/engineering work that has unknowns. But taking TFA example of building houses, most / all developers would do the foundations of all the houses first before moving on i.e. working sequentially.
In my environment, we “inspect and adapt” every two weeks, and we tend to do marketing launches a couple of times a year.
But SpaceX was not launching rockets into space every two weeks, so their “iterations” from the outside look more like most companies’ product launches, not like sprints or whatever people call their iterations that happen on a fortnightly or monthly scale.
2 important reasons are: 1) the project is around 6 years in total 2) the company has to fix any issues with the house for the first 2 years.
If they did all the foundations first, they’d have exactly the problem described in the article - no money till right at the end. Instead, they get money the entire way along and use that to finance the rest of the project. This isn’t an optimisation, iterative delivery is essential to their viability as a business.
They also eat the support costs on houses they build. That means they are repeatedly changing “features” in the houses to minimise those support costs. Just walking down 1 street you can see the evolution of the houses over time as they fixed various small issues with the original design. The houses look basically the same to a casual observer, but are quite stark to someone who lives in one of the versions. They are very obviously agile, and have a great system for inspecting and adapting. That doesnt happen on 2 week cycles, but it does happen at a pace appropriate for them.
For a lot of things it doesn't matter, but for some it can be very difficult to change later on, especially if you need to maintain backwards compatibility.
That's not true. In the "ideal", they both take the same time. Why? Because in the ideal they both include exactly the same amount of work (assuming your testing story isn't 5 months of manual test execution). If you have a sane system testing setup, they're exactly the same.
But the fact is, you never have the ideal. And that's why you use iterative methods. You will almost always design the wrong thing (at least in part). You will almost always have a section of code that's harder to implement than originally anticipated (or whose initial implementation impedes other work, requiring a partial rewrite).
Iterative methods discover these issues earlier. In a sequential (Waterfall) development model, you only discover these problems in the late stages, far after you've initially designed and developed. This requires you to go back and redo a lot of stuff, or you put in patches and compromise on quality, or you accept that it's a failure but ship it anyways.
========
Now, if your test story isn't sane and it's all manual testing, then sure, iterative methods will by necessity be slower because you take months to test each iteration. So fix the test story so that it's as automatic and fast as possible (without compromising the test quality). At that point, sequential is only best if you have a perfect team that never fucks up, and a perfect customer who never asks for the wrong thing. Since we all know that those things never happen (in large scale projects [0]), don't make that assumption (you do know what assuming does, right?) and stick with iterative methods.
========
[0] A thing that's often forgotten in these discussions is that Royce's paper was about large scale engineering tasks. Not small stuff. I will concede that a Waterfall-esque approach can work fine for a short-run (less than one quarter), small-scale project (especially if it's in a well-understood domain). But in anything past that 3-6 month mark or on any poorly understood domain, sequential is the worst thing you could do to your team and your customer.