Problem solve Get help with specific problems with your technologies, process and projects.

How agile development affects role of business analyst

Agile software development methods may alter the traditional role of business analyst and requirements gathering. Expert Karl E. Wiegers explains how.

When I first started seeing agile methods show up, it looked like the folks who prefer no process were looking for some kind of approval to avoid requirements. I was skeptical, but I have since found that agile methods are sometimes exactly what are needed. I am interested in your observations about how agile methods may have changed the role and responsibilities of business analysts in system development projects.

You're right. There are always some people who latch onto any new software development approach with the reaction, "Great! This means now I don't have to do <blank> anymore," where "<blank>" represents whatever they don't like to do on a software project, including requirements. Of course, that's not what any of these new approaches mean; see my article "License to Hack" at http://www.stickyminds.com. Agile development methods do definitely address requirements.

The traditional role of the business analyst has been to facilitate communication between customers who have needs and developers who create solutions. The analyst performs multiple services: bridging, translating, interpreting, documenting, modeling, prototyping and even inventing requirements. Think of the analyst function as being a project role, not necessarily a job title. This role can be performed by various people on the project who have the skills, knowledge and temperament for it. A suggested job description for a requirements analyst is available here.

Software requirements gathering resources:
How a business analyst can help on a software project

Agile development best for delivering products on target

Software requirements gathering techniques

Agile development emphasizes a close collaborative partnership between customer (or, more broadly, stakeholder) representatives and the developers. This is a powerful success enabler for any project. The question, then, is who should perform the central roles in this partnership. For more than 20 years I have advocated a model in which one or more analysts work with one or more key user representatives called "product champions." The product champion concept relates to the "on-site customer" concept in agile development.

One problem with this approach is that it introduces additional communication layers between the voice of the customer and the ear of the developer. You can eliminate some of those layers if the developer has the skills and knowledge to perform the analyst functions, instead of having a separate individual serve as the business analyst. However, that means developers will need training, resources and experience to do a good job when they wear their analyst hat. Not every developer will be comfortable or effective performing that role. So be sure to adequately prepare your developers to grow into the analyst function instead of expecting them to do a great job in this difficult role automatically with no training or guidance.

For more thoughts on this topic, see Scott Ambler's article "Rethinking the Role of Business Analysts."

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.