“Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.”

“Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.”- from the Agile Manifesto

Okay, now back to the real-world. As Forrester analyst Dave West recently pointed out in an SD Times article, “the reality of agile adoption has diverged from the original ideas described in the Agile Manifesto, with many adoptions resembling what Forrester labels water-Scrum-fall.”

Others have dubbed it Agile-Fall, Scrum-Fall or even fake agile. Whatever you call it, this mixed bag methodology is becoming the norm for test and dev teams – and it’s not hard to figure out why. West continues:

This happens in part because agile adoption has been practitioner-led, leading teams to focus on domains they can influence, mainly the team itself. Areas outside of their control, such as project planning and release management, continue to follow more-traditional approaches, meaning that Scrum adoption is limited to the development team. That team is presented with a detailed project plan and a set of requirements that it then works through, incrementally delivering software (but not to production) as the production release process runs at a different cadence.

While this model is not inherently bad, application development professionals need to carefully consider and make the right decisions about where the lines fall between water-Scrum and Scrum-fall. Otherwise, they are unlikely to realize agile’s business benefits, such as faster time-to-market, increased business value, and improved flexibility and responsiveness.

The reality of water-Scrum-fall is that change will continue. The water stage defines the overall direction of the project, but the team will have many insights during the project that challenge initial ideas. By supporting change while at the same time ensuring that the team understands the impact of that change, the team will not only build better applications, but will also learn more about its process for future implementations.

Chances are, you’ve likely had some experience with this methodology. If not – and you’re looking to adopt an agile-esque approach – here’s a tip from eBay’s Jon Bach:

“Agile-fall” was something I heard at LexisNexis from an awesome PM named Lance Thomas, but in a Google talk in 2005, Elisabeth Hendrickson called it “Scrumfall”, so search on that term and you’ll see that it refers to having the principles associated with Agile (daily stand-ups, sprints, burndown charts, etc.), done in a waterfall-y series of development steps. Example: Sprint 1: Gather requirements, Sprint 2: Design your tests, Sprint 3, Run those tests, Sprint 4, Fix bugs, Sprint 5 regress those bugs. There’s no shame in that if that’s what works, and when you’re going through a transition from Waterfall to Agile, that may be the best thing as opposed to a sudden lever-pull one day where you show up and your desk is next to someone else with no walls and there’s a stack of sticky notes and markers on your chair with an email to report to your first standup in 30-minutes.

This post orginally appeared on the uTest blog.