The way it is described in the article highlights a subtle problem - the ability to change requirements as you go.
To me it seems that it will only really work if agile is about changing how you achieve requirements as you go.
No wonder agile projects often seem to never finish - the old question is "how do we know when we are finished?", with answer "when we have done what we said we would do"
You can't ever do what you said you would do when you never define it and/or change it all the time.
If you are writing software without knowing your requirements (at least at a functional or high level) you are not engineering it, you are researching it.
This aligns wit the paradigm "write one (or more) to throw away", which I have found most useful if for some reason requirements are unclear.
When doing engineering type engineering (as opposed to software type engineering) large projects, sometimes tens of billions of dollars, follow a gating approach where up to 20% of the budget might be spent before FID (Final Investment Decision) is made.
But at FID time budget and schedule uncertainty is expected to be better than +/-5%, typically. (notable failures occur in this space as well, Chevron multiple times for example, but different reasons and another story)
FID may not be granted, but better to waste 10-20% of budget to know now, rather than 200% to find out later.
This is why I feel a lot of "software engineering" is not actually engineering. Engineering means creating a known desired outcome with known quality parameters of cost, budget, performance, safety lifetime etc etc - how many software projects actually engineer to both define and achieve these parameters? Very few it would seem.
How many software projects need to be engineered? Not all. A speculative development like Facebook or Twitter is a race to market and exploration of what works, it's constant research up to a point.
Software to control a satellite launch vehicle, or a train network, that is different and needs to be engineered to achieve meeting societal expectations, significant part because of the possible consequences of some failures.
For such systems a lot of effort is applied up front to understand the problem in great detail, and develop linked requirements which are highly fixed and not changeable without serious effort to align everything, and the rework of much regret engineering.
Research is open ended with uncertain costs and results, engineering is about delivering known expected outcomes achieved with expected and planned resources.
To me it seems that it will only really work if agile is about changing how you achieve requirements as you go.
No wonder agile projects often seem to never finish - the old question is "how do we know when we are finished?", with answer "when we have done what we said we would do"
You can't ever do what you said you would do when you never define it and/or change it all the time.
If you are writing software without knowing your requirements (at least at a functional or high level) you are not engineering it, you are researching it.
This aligns wit the paradigm "write one (or more) to throw away", which I have found most useful if for some reason requirements are unclear.
When doing engineering type engineering (as opposed to software type engineering) large projects, sometimes tens of billions of dollars, follow a gating approach where up to 20% of the budget might be spent before FID (Final Investment Decision) is made.
But at FID time budget and schedule uncertainty is expected to be better than +/-5%, typically. (notable failures occur in this space as well, Chevron multiple times for example, but different reasons and another story)
FID may not be granted, but better to waste 10-20% of budget to know now, rather than 200% to find out later.
This is why I feel a lot of "software engineering" is not actually engineering. Engineering means creating a known desired outcome with known quality parameters of cost, budget, performance, safety lifetime etc etc - how many software projects actually engineer to both define and achieve these parameters? Very few it would seem.
How many software projects need to be engineered? Not all. A speculative development like Facebook or Twitter is a race to market and exploration of what works, it's constant research up to a point.
Software to control a satellite launch vehicle, or a train network, that is different and needs to be engineered to achieve meeting societal expectations, significant part because of the possible consequences of some failures.
For such systems a lot of effort is applied up front to understand the problem in great detail, and develop linked requirements which are highly fixed and not changeable without serious effort to align everything, and the rework of much regret engineering.
Research is open ended with uncertain costs and results, engineering is about delivering known expected outcomes achieved with expected and planned resources.
Which one are you doing?