'Agile' F-35 fighter software dev techniques failed to speed up jet deliveries(theregister.com)
theregister.com
'Agile' F-35 fighter software dev techniques failed to speed up jet deliveries
https://www.theregister.com/2021/03/25/f35_gao_report_fy2020_software_woes/
5 comments
Agile destroys any software project it’s allowed to touch by sabotaging development of early architecture through the “it must fit into two weeks” mandate and other assorted short-termist practices.
But the F-35 was already a shitshow, because the aircraft itself was designed using agile, though the Pentagon called it “concurrency” instead of calling it “agile”. Concurrency (agile) was also used for the Littoral Combat Ship (LCS), which produced a similarly disasterous, unreliable four-assed monkey that neither the Chinese nor the Russians would ever take seriously.
But the F-35 was already a shitshow, because the aircraft itself was designed using agile, though the Pentagon called it “concurrency” instead of calling it “agile”. Concurrency (agile) was also used for the Littoral Combat Ship (LCS), which produced a similarly disasterous, unreliable four-assed monkey that neither the Chinese nor the Russians would ever take seriously.
Of course they didn't.
Agile is not about speed, it's about predictability.
Slow is predictable.
Agile is not about speed, it's about predictability.
Slow is predictable.
Don't confuse agile with 'agile', the headline uses the latter.
Agile (the real thing, no pretend-lookalike) provides speed, or not, depending on how you measure. It often provides something quickly, and you get to choose whether that's a speedup. If you want to write a report emphasising your own success, agile development provided a working simulator/airplane/whatever with great speed, if you want to write a report denigrating your rival, agile didn't finish the ticklist in the specification any quicker than one imagines that waterfall might have done.
But the F35 wasn't agile, it was 'agile', the worst of both worlds.
Agile (the real thing, no pretend-lookalike) provides speed, or not, depending on how you measure. It often provides something quickly, and you get to choose whether that's a speedup. If you want to write a report emphasising your own success, agile development provided a working simulator/airplane/whatever with great speed, if you want to write a report denigrating your rival, agile didn't finish the ticklist in the specification any quicker than one imagines that waterfall might have done.
But the F35 wasn't agile, it was 'agile', the worst of both worlds.
Agile often gets better speed, but it does this in two ways that don't always apply. First by focusing on what is important first you completely skip some nice to haves that nobody actually needs. Second, by focusing on getting something working early you discover missing requirements early, saving a lot of time/rework in the end when it is more expensive to add those things.
With well understood problems these are not important. Airplanes are not new, so we can look at the requirements of previous software. This being government they probably have those in detail from previous fighters, so there is less new things to figure out from scratch.
With well understood problems these are not important. Airplanes are not new, so we can look at the requirements of previous software. This being government they probably have those in detail from previous fighters, so there is less new things to figure out from scratch.
I don't think it's a good idea to use pure Agile for mission-critical SW. It should be at least partially waterfall - i.e. more formal specs and designs upfront.
--
Five Worlds
https://www.joelonsoftware.com/2002/05/06/five-worlds/