“Welcome changing requirements, even late in

“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.

 Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

Want to see more interviews from STPCon? Check out the full list here.

Oh – and did we mention that this video includes a testing robot? Well, now you know!

Want to see more interviews from STPCon? Check out the full list here.

Want to see more interviews from STPCon? Check out the full list here.

Want to see more interviews from STPCon? Check out the full list here.

Want to see more interviews from STPCon? Check out the full list here.

Want to see more interviews from STPCon? Check out the full list here.

Want to see more interviews from STPCon? Check out the full list here.

Want to see more interviews from STPCon? Check out the full list here.

On the heels of this news, uTest is happy to announce a new plugin that allows bi-directional integration with JIRA. As one of only fifteen plugins that have been pre-installed on Atlassian OnDemand, we’re obviously quite excited about this news and what it means for our growing base of customers, and our global community of testers.

So what does it mean, specifically? Well, previously, companies could consolidate and track their bugs in JIRA by importing reports logged in uTest’s platform.  But now, JIRA users can map uTest data fields back to data fields in JIRA, which creates a seamless, two-way system for managing bugs found in the lab or in the wild. The end result: a greatly simplified process for test case management.

Perhaps the coolest thing about our new JIRA plugin is its one-click integration with Bug Fix Verification, a robust new time-saving feature launched in Version 4.0 of our software testing platform. Since uTest’s community performs app testing in real-world conditions – working on real devices, carriers, browsers, and operating systems – it can be difficult for customers to validate that a bug fix has addressed the problem.

Using Bug Fix Verification, companies can automatically send a request to uTest’s community, ask them to try to reproduce the bugs on a newer version of the application, and report back whether the defects have been successfully eliminated.

As you might imagine, this plugin is best suited to meet the needs of agile development shops, many of which are under intense pressure to speed up the testing process.

To learn more about this integration – and what it could mean for your testing team and operations – be sure to check out the Atlassian OnDemand product page.