I was a DoD contractor (the coding type, not the shooting type) for almost 15 years, and this is a …

I haven't read the doc, but I worked on lawsuits (I'm a lawyer) that at their core were asserting that agile software development isn't as safe or bug proof as waterfall. Basically in the medical device (or adjacent) space the idea asserted was that 'fail fast' was illegal and didn't have enough safety checks. Agile software development is a tough pill to swallow for non-engineers. The lawyers and business people can't wrap their head around the idea that building iteratively could actually reduce bugs and improve quality - because the way they work is via process planning docs and checklists.

Just out of curiosity, how does someone with in-demand, highly-transferable skills like software development find themselves working in a place they generally dislike for 15 years without leaving sooner?

> The problem is that you can't take a process and put software drones on it and deliver software of any complexity. That goes against much (but not all!) of the DoD paradigm, it is interesting to see they might be changing. My (outside) impression has changed the more I've heard over the years, to the point that I assume the DoD and military are acutely aware that the drones aren't really interchangeable, and that at every level they cultivate people under them they know "get shit done" and hand the important projects to them. Those people in turn have those under them that "get shit done" they hand the important things to, and so on, all the way down to privates in the military. The important thing being that those people that get shit done are given a lot more leeway in how they accomplish things (which might later become doctrine of successful), and this is specifically how those org…

> I've heard some software devs state that "the waterfall method was never really used". What they mean by that is that the person who invented the phrase "waterfall method" did it specifically to tell the world about something that did not work. In fact, even going back to the NATO software engineering conferences of the 1960s, they were discussing how development needs to be agile. But sure enough, few big organisations got that memo.

I'm a current DoD contractor (the coding type) and the agile/waterfall mentality still holds up. Different departments and different projects within each department will have different methodologies for planning and delivering products. However, where I am, there is a huge emphasis on "getting shit done" well ahead of schedule. I'm lucky to work with smart and motivated folks who together, work well and we are wildly successful. My biggest gripe, shared among many of my coworkers, is the level of micromanagement. Multiple business analysts, product owners, stakeholders, SCRUM masters, managers, etc. who all share essentially the same job - delegating and scheduling work. It makes every project 10x more difficult and complex than it otherwise should be. An example just from this past week: Project A: we are delivering a single product. Three managers, two SCRUM masters, multiple business …

I keep banging on about "software is a new form of literacy". Imagine you have a group of illiterate managers who have just hired a group of writers to write some company policy documents. You could have the managers (carve / draw / modern dance) their requirements in a waterfall manner. Of course you could get one of the managers to sit down with the developers and tell them how the policy's work each day, embed with them Agile style. However in the end you can't be everywhere, sometimes there aren't enough people in the company who understand what is needed, or even be sure that the embedded people agree on what is needed. These are business problems - but they are also literacy problems. We have a literate society and so there are enough literate people to write policy documents to cover a whole compmay. We need to make enough people who can code, so they can write the policy document…

Related to agile on DoD projects, here’s a presentation from Lockheed Martin about their adoption of SAFe (Scaled Agile Framework) for their F-16 software projects. While agilists consider SAFe to be “waterfall in agile clothing” sold by consultants, Lockheed Martin successfully reduced their cycle time from 3-4 years per program increment (delivered to Flight Test team) to 9 months. They’re delivering smaller increments to QA and iterating on feedback more frequently. https://youtu.be/nvfYLZ52zX0

> The problem is that you can't take a process and put software drones on it and deliver software of any complexity. That would be news to most tech companies, these days, that seem to be obsessed with hiring huge armies of inexperienced engineers, relying on the process to make them magically deliver code like they were masters. I worked for a couple of major corporations, and got lots of waterfall. A the Japanese company, I quickly learned never to utter the dark majik phrase " A G I L E ," as it conjured demons from managers. Also, looking at that PDF, I realize that it is a slide deck. That presentation must have been a soporific.