Great document overall! > The purpose of this document is to provide guidance to DoD program executives and acquisition professionals on how to detect software projects that are really using agile development versus those that are simply waterfall or spiral development in agile clothing (“agile-scrum-fall”). Actually doing 'waterfall' properly would probably be fine? Or at least not the bogeyman it's made out to be.…
> Actually doing 'waterfall' properly would probably be fine? Or at least not the bogeyman it's made out to be. Doing waterfall in the exact sense that is usually described will almost certainly never work well. People usually focus on the design phase, but I think the much more catastrophic part of 'waterfall' is doing testing only once development is complete. Now, you absolutely can successfully run software proje…
This is my own experience, but I was involved with a multi-year project for a federal agency that did exactly this. I think what many people don't understand is that the design phase is a byproduct of the internal processes necessary for even getting to the point of developing a system in the government. What I mean by this is, systems don't appear within based on good ideas or pitch decks, they start with policies, and based on those policies, procedures.
Why is that necessary in government? Because typically, there are laws, executive orders, regulations, and various other policy devices that have to be implemented at the agency level, there is a review period that allows for input from affected external agencies, etc. In some cases, there is even involvement from congressional committees and their staff members. This is especially true if appropriations are necessary for funding a program.
I can honestly say it took a year and a half just to develop the policies and procedures, to coordinate them, and to begin work on the system. That was ridiculously quick, given the scope of the project. The good thing about doing it this way, is you have a very clear roadmap at the outset. The downside is, the process for making significant changes to the system's functional requirements can be a challenge (e.g., changes to policy/procedures, another review period, etc.).
That being said, once we actually began the development phase we took a much more agile approach. We would hold daily stand-ups, regular testing/feedback sessions with customers, established product owner(s), etc. I would say it worked really well, but it was not without difficulties. Those difficulties are far bigger than agile vs. waterfall though, it's just the way the bureaucracy functions (for better or worse).