We love to make up words.
First, we got Scrummerfall. This is the negative term coined by Brad Wilson whereby Scrum is combined with Waterfall to produce an unsustainably poor process, quickly abandoned. As Brad coined the term:
“The worst case scenario, in my experience, is embedding Waterfall inside of Scrum. This often manifests in what I call the One-Two-One pattern: one week of design, two weeks of coding, one week of test and integration. I’ve yet to see a team that was long term successful with such a system, especially if they are strongly rooted in historical Waterfall. As often as not, they will abandon Scrum after just a few sprints, claiming that it failed to provide anything but pain. Worse, that’s often the extent of their foray into agile. They “tried that agile stuff” and failed, so they’re sour on it.”
Now, we get Waterscrum. This term, coined by Kevin Neher, is something a bit more positive. This refers to the notion of using Scrum as a process in an organization that uses waterfall-based checkpoints to manage risk. As Kevin defines it:
WaterScrum: co-dependent Waterfall and Scrum projects. Similar to trying to play (American) football and soccer on the same field at the same time, requiring extra levels of coordination and timing.
Both terms define different aspects of the same problem. When an organization moves from Waterfall to Agile processes, they have to change more than just how to track the delivery of code. They have to change the practices of coding as well as the methods used to govern investment and manage risk. It is not an easy transition, and in the modern age of metrics and scorecards, it is doubly difficult since scorecards demand a number, and that demand sometimes constrains creativity away from processes that don’t produce the number in the same way (or at all).
For example, in our IT setting, we have a number of Scrum projects. Our normal risk management process requires that the business sign off on the design for the application before coding begins. In an agile process, this is somewhat silly, since there is a much more blended delivery of both code and design much earlier in the process. The working mechanism we’ve come up with is that the Scrum team still has to have a ‘baseline’ but that it can occur at the end of the first or second sprint, where high level design is largely understood for a near term release (a few months away at most) and proof of feasability can be demonstrated in functioning code (and hopefully a small number of architectural models).
That accomplishes the goal of managing and reducing risk while still allowing the teams to proceed using an agile approach. The challenge is not getting the governance folks to accept the notion of allowing coding to proceed without approval. The challenge is getting the agile teams to step up to getting that approval after two sprints to continue on their path.
I caution this much: if your team wants to go the route of using agile, make certain you do not shrink from the responsibility of providing feedback to the risk management and governance folks. Otherwise, you may deliver value but manage to get a black eye anyway, for failing to cross the right benchmarks at the right time.