In a previous post, Nicholas Chaillan brought up the term water-agile-fall, or water-scum-fall. This is a situation where an organization that has traditionally worked with linear waterfall methods tries to adopt agile or scrum methodologies, but agile really only (kind of) touches the developers and does not bring the rest of the functional areas along with it. That seems to be a problem. Here’s one explanation:
In a Water-Scrum-Fall environment, the front-end of a project still has the high-level project planning with approval and governance gates that follow a more traditional waterfall approach. The development team has non-agile interactions with these front end project teams. Similarly, the back-end of each agile iteration is abound with non-agile interactions. DevOps processes are heavily laden with governance and staging areas before an actual release is put into production. It can be quite challenging to align Agile sprints with more traditional waterfall release schedules.
“… it’s imperative that application development and delivery professionals push back on the water-Scrum side of the model. Spending too much time upfront will not increase the quality of the release; on the contrary, it is wasteful.”. On the “fall” part of the model Dave West warns: “Application development professionals should challenge the status quo of infrequent releases and push to better integrate release processes into the development team.”
Until the rest of the acquisition community embraces agile methods, which isn’t simply just a faster iteration of the waterfall paradigm, program execution is at risk. Indeed, focusing on program outputs — and the requirements to get there put into a contract — in advance of “doing” is precisely a major problem area. The development team must feel like the design and the initiative is their own, in which case they can own responsibility.
My main concern about the approach described here is that nobody is getting guidance on when it applies and when it doesn’t. Some people (e.g. the DIB) explicitly assert that it ALWAYS applies; you should do every DoD software development this way. However, if you listen to what Chaillon says, there are some key assumptions in there, such as the assumption that you can get to a Minimum Viable Product (MVP) in a matter of weeks. For development projects like a new GPS ground control suite (OCS or OCX), or ALIS for the F-35, that’s clearly not even close to true. Nobody (that I have heard) is talking about how you get to a point where you can start being agile when you have massive functional content requirements in the MVP.
Yes, one young developer I know said he likes to sit around for months thinking about a problem and then rapidly integrate a software solution rather than bang out a MVP as soon as possible then iterate. Both OCX and ALIS had predecessors, however, which supposedly would have given a baseline from which to pull what is useful and iterate from there. But in both those cases, what actually happened couldn’t have been a worse outcome than whatever counterfactual you come up with. Perhaps, again, it starts with enterprise tools so you’re not building the full stack, as Chaillan recommends. When the infrastructure or operating systems need to be reinvented, then you may have to stop and start from first principles again — perhaps in a waterfall approach.