Survey: Top Agile 'Pain Point' Is Capturing Requirements

Going Agile shifts the focus of gathering application requirements from detailed specifications to user stories, and that's the biggest obstacle to success, according to a recent survey of companies making the leap.

However, the top reported 'pain point' listed by companies was dependent upon what stage of Agile adoption the respondents were at, according to the survey, which gathered information from nearly 1,000 developers and other business professionals and was published last month by AccuRev, UrbanCode and Rally Software.

So, while capturing requirements was the top overall problem area among all respondents, a lack of automated tests was the No. 1 issue among companies that were at the "mostly/all" level of Agile adoption. The other levels were: no plans, planning, piloting and scaling.

"This study showcases the shift in key Agile pain points as Agile processes are increasingly deployed throughout an organization," according to the survey overview. The "Agile Pain Points and Adoption Trends" survey report can be downloaded from AccuRev's Web site upon user registration.

The report listed the "top five overall Agile paint points" and the respective percentage of respondents listing them as No. 1 as:

  • Capturing requirements (16%)
  • Lack of in-house experience (14%)
  • Lack of automated tests (13%)
  • People spread across projects (10%)
  • Support [of] Agile and non-Agile projects (8%)

Other pain points listed in the survey included: audit/governance on an Agile project, lack of automated deployments, Agile with a distributed team and lack of automated build and more.

The survey also gathered information on the level of Agile adoption among organizations, and the results were consistent with other similar studies that indicate the majority of software development efforts are shifting to Agile methodologies. It reported that 68 percent of organizations were implementing Agile at some level. These levels of Agile adoption among respondents were:

  • Piloting with small groups (37%)
  • Investigating (25%)
  • Scaling (23%)
  • Mostly/all (8%)
  • No plans (7%)

 

About the Author

David Ramel is an editor and writer for 1105 Media.

Reader Comments:

Thu, Feb 17, 2011 Steven Gordon AZ

Looks like I read two comments as a single comment. I still stand by my major point.

Thu, Feb 17, 2011 Steven Gordon AZ

The comment that starts saying "Agile, in a word, is a delusion!" and ends saying "If you build something that has not been built ever before and it's near impossible to know what the best solution is (e.g. Facebook) Agile is great" illustrates that even when you think you know what you think when you start, it often is different than what you think when you finish. This is why fixed, upfront requirements are suboptimal. Agile is a pragmatic approach to the fact that the requirements at the end of a project are very rarely what they are at the end. If the project cannot easily be redeployed, then we may have to fix the requirements (e.g., Mars Rover), but otherwise, we should leverage what we learn during a project about how to best meet the project's goals. Fixed designs based on fixed requirements makes it very expensive to apply what is learned during a project.

Wed, Jan 26, 2011 Steve Naidamast Mineola, New York

Agile, in a word, is a delusion! It is used mostly by tech-managers as a euphemism to tell their own supervisors that they have a development life-cycle when all they really have is a "stuff it in as fast as you can" approach to every thing they do. Even when developers use the term they have little understanding of quality development processes
required to build good systems and their coding styles demonstrate this.

Software development takes planning and time to implement quality products. However, since the dot-com bubble everyone is just interested in cutting any corner possible to decrease the time it takes to put in a software project. Hence, Agile development, which is an outgrowth of the earlier XP paradigm; and that in turn was based on a failed implementation, the Chrysler C3 Payroll Project, which was eventually canceled.

Proper software engineering techniques and paradigms are the only way to efficiently and even quickly implement quality results. Such principals have included Agile style development cycles for years, which are known as the "incremental" and "evolutionary" development paradigms. However, all such engineering development cycles include establishing requirement guidelines for proper acquisition of such information which is the most important foundation for any such project.

Wed, Jan 26, 2011 Marc Beaverton, OR

How much longer does it take the software development community to figure out that software development, like any product development, is ALL about requirements?
Didn't the iPhone become a hit because Steve Jobbs got the requirements right?
Isn't product development just a race who can most quickly get the requirements right?

Any endeavor requires balancing between thinking things through ahead of time or jumping right in to gain experience quickly. Not thinking things through may waste resources. Pondering too long before actually starting development may take too much time and may cause wasting time on irrelevant issues; so there is value in incremental development. The company who finds the right balance wins.

Agile teams tend to not think things through and to accept rework as a fact of life. Once "refactor" becomes a euphemism for "redo" you may get the requirements quicker by making an effort to think things through ahead of development. (This does not exclude incremental development.)

The balance obviously depends on the product and how quickly the product needs to adapt to market changes. If you build something that has not been built ever before and it's near impossible to know what the best solution is (e.g. Facebook) Agile is great - the earlier you get market feedback the better. But if you build a Mars Rover, Agile may be more costly than necessary.

Add Your Comment Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above


Close this Advertisement