"Secondly, we write up thorough design documents before breaking ground."
Design documents? Sounds scarily like waterfall to me.
Design documents? Sounds scarily like waterfall to me.
Moving fast and breaking things isn't the only way to write code.
Waterfall assumes you can know too many things at the start and have everything go right. It fails when it encounters the real world but is still pushed by program offices across the DOD despite extreme cost and schedule overruns and quality issues.
I’m out now and on mobile. But I can write in more detail later if you want about the problems of the pervasive waterfall method in DOD projects. Even the DOD systems acquisition documents have endorsed iterative/incremental (a slow motion agile/lean when you dig into it) development models since 1985 but still Waterfall lives on.
There's a lot of options between "moving fast and breaking things" and waterfall. And almost every one of them is better than waterfall.
Let's be clear on terms. True Waterfall is a single sequential pass: Analysis, design, development, testing.
There is no feedback, there is no room for error. Now, you think there being no room for error sounds good until your project is years late and billions overdue. Because no time was allowed for feedback and correcting for errors, they're discovered late (in testing) and either:
1) you loop back then and fix it [0]
2) you "descope" requirements and whittle it down to a functioning, but incomplete, system
3) you push through and finish it on time (because in most Waterfall shops the estimated schedule is a commitment) and deliver a buggy product (that in the USAF and others can, and has, literally meant death).
Implemented waterfall actually allows for a greater degree of feedback. Maybe they even do unit tests on software [1] so they have some degree of effective testing during development. More often, they keep the Waterfall idea of big testing at the end. By this I mean a 1+ month event where a comprehensive test suite is executed. This is preceded by a preliminary execution which also takes 1+ months. So let's say you have a 15 month project, this means they literally schedule 2+ months to executing these tests and this is the only time they will execute all of them. Between the PFQT and FQT they will deal with any rework. They still treat estimates as commitments and still rush crappy code out to the customer. So every defect is discovered as late as possible, rather than as early as possible. Any error in logic, any error in design (which is the most critical cause of lack of safety and reliability in systems) will not be found until month 12 or 13 of a 15 month project, if it's found in this cycle at all.
There is no place in this world for Waterfall in any variation except for small projects (less than 30k or so lines of C) or projects that have been done a hundred times before by the same team who is going to do it now (they are literally the only ones who can get this done). But most companies will still try to do waterfall with teams of novices (to the domain, often to the profession to as they prefer cheap new grads to experienced developers and experts).
The DoD has, since 1985, endorsed a model based on iterative and incremental development. This means that you scope your initial necessary features, and over a series of projects you add in the extra ones (including ones you may not have thought of to start with, either on oversight or something that changed). Within each project cycle the iterative model has you doing a rough equivalent of the "sprints" in Agile (big-A) shops. Though often longer (still 1-3 months rather than aiming for days or weeks). However, since there's always a lag this wasn't really picked up by leadership until the 1990s so most of the present leadership still started their careers in the Waterfall world of the 1980s (civil service tends to stick around for 40 years) and still insist on peddling that bullshit rather than adopting more sensible development models.
There is no feasible way that anyone working on the F-35, originally conceived in 1992!!!, could have possibly laid out the work for that project properly in a Waterfall approach. Which is also probably why it was years late, billions over budget, and failed to meet some operational requirements when it was finally delivered.
[0] Too late to be effective because everyone who did the development has been laid off or reassigned or simply slept and forgotten what they did a year earlier.
[1] The initial developers may, but they will strip this out before handing it off to the maintenance programmers who are in a different company. Can't help the competition, customer be damned.