Question: What value does the BA provide within a true agile project?
There’s actually two interesting points to discuss in this question. First, the question regarding the value provided by a business analyst, and the second, the label “true agile project”. I’ll address each point separately.
The value provided by a business analyst on an agile project is based on how experienced that business analyst is in business analysis skill sets, and how willing they are to share their knowledge and pick up other tasks not normally in their wheel house. A key aspect of working on an agile team is being willing to step outside the normal responsibilities of your role to help the team move past a bottleneck. If testing needs to be done, team members should pitch in and help test. If the project manager needs some help with some of the project management related tasks that aren’t covered by the team managing their day to day work, team members can step in to help. If developers need another pair of eyes to look at something they are developing or need to talk through a particularly challenging issue, a BA just may be able to help. If some work is needed on the system help information, the BA can pitch in to help any technical writers.
What will quickly make a BA not very valuable, and subject to be kicked off the team is hoarding all the contact with the customer. Everyone on the delivery team should have contact with the customer if need be. What the BA can do is coach customers and developers alike on how to talk with each other and reach agreement on a common language. Where the BA will really add value is working with the Product Owner to paint an overall view of the objective of the project and help ensure that the team has considered all of the various intricacies of the problem space and possible solutions. For more perspective on what a BA’s role is on an agile project, see the post on Business Analysis on an Agile Project.
When I hear the phrase “true” agile project, I immediately become concerned that the focus of the project is following agile prescriptions rather than delivering value to the customer. Experienced practitioners of agile methods will suggest that the best way to learn agile is to follow the guidance of the agile approach to the letter. The agile approaches are fairly light on prescription following the philosophy that simple rules will guide complex behavior. The reasoning behind the guidance to follow the approach to the letter is so that the team will experience how all of the techniques and philosophies work together to make the team more effective. Once the team has experienced the symbiotic of the techniques and more importantly understands why those techniques work together, they should look to revise their process based on reflection and adaptation.
This is certainly good advice, but it can drive teams to focus so much on doing the process just exactly so, that they lose sight of the true purpose of the project to deliver value to customers. A different approach may be to understand the characteristics of the project and use that understanding to determine the most appropriate approach to solve that problem. Many agile techniques, and some complete agile projects are certainly well suited to provide solutions to many projects, but sometimes it is better to use a combination of techniques. So instead of focusing on a true agile project, look for a truly successful project, with success measured as delivering value to the customer.