How To Use Business Analysts on Agile Projects

What's a Business Analyst To Do?

What happened to the role of the business analyst on agile software projects?

Extreme Programming, a pioneering agile methodology, talks a lot about the interactions between developers and customers, but there's no mention of business analysts. Scrum, one of the more popular agile methodologies these days, talks about a Scrum Team which may include an analyst, but there's not much prescription about what a business analyst should be doing on a Scrum Team.

I've always been a huge advocate of the value of business analysts and a strong proponent of agile-based methodologies. However, it would seem, through act of (most likely intentional) omission, that business analysts are not valued very highly on agile projects. As you might imagine, I have strong opinions against this belief. Business analysts provide an invaluable service on an agile project; however, they must be used properly so as not to compromise the integrity of the methodology.

The Proper Use of Business Analysts on an Agile Software Project

First of all, don't try to invent a role to improve or otherwise localize the methodology for your purposes. There's a very good reason why business analysts are not represented in a methodology like Extreme Programming, which has philosophical roots. In almost all cases, tampering with a delicate ecosystem like this will backfire. So it's best to just follow the rules and procedures as defined. Fortunately, a business analyst can function in the role of a developer or a customer. So, choose the side that best fits the situation. For instance, I've been on a lot of agile projects that would've benefited by more customer involvement. A good business analyst is a great customer surrogate for these purposes.

That said, it's best to adopt pair programming and have the business analyst pair up with someone who lives the role in his or her day job. A business analyst who is playing the role of developer should team up with another developer, and a business analyst who is playing the role of the customer should team up with another customer. Pair programming is a best practice in general, however it's most important when you have business analysts in the mix. It helps them grow while mitigating any capability risks.

Finally, stay flexible with which role a business analyst can be at any point in time. This is a great advantage to teams that use business analysts. A developer cannot just become a customer and vice versa; however, a business analyst can move back and forth. Use this to your advantage. Have the business analyst pair with a developer for a few iterations and then pair with a customer for a few iterations. He or she can even play coach or ScrumMaster for a while if they have the skills (as most business analysts do). Having this type of versatility makes for a very nimble and resilient agile team.

Conclusion

Just because the agile methodologies don't call out a role for the business analysts, doesn't mean they're not valuable on these efforts. The ambidextrous nature of the business analyst's skill set caters well to the resource demands that are inherent on all agile software development projects. If you need another customer, use your business analyst as a customer. And, if you need another developer, he or she can play that role as well. Use this flexibility to your advantage and you'll have a super-agile team on your hands.