Do we need a business analyst on an agile project? Are there Agile business analysts?
This is another ongoing debate, and one of the questions I have met on interviews, forums and discussion boards in some form.
With the promise and perceived philosophy of Agile – requirements are constantly changing, documenting them is unnecessary, everyone on the team does everything, etc. -, people started to question the need for a business analyst on the Agile projects.
While I believe that the answer is most of the time yes, my answer is still: well, it depends on.
Lets see what I mean by describing some of the Agile projects I have met during the years. This is not a complete list of all the possibilities, these are only project set ups I have met.
One team, short project, product owner is co-located with the development team
This is the ideal, classic Agile project set up – the project lasts a year maybe, there is only one team involved (4-6 people) and the product owner, if not sitting right with the team, is close, easily accessed.
If you run a project like this, then my answer is no, you don’t need a business analyst. Someone still have to do the business analysis related tasks, but there is no definite need for a dedicated business analyst.
The product owner can meet with the team easily when there is a need, and by selecting the right sprint length the whole project can run by the book – user stories refined by the product owner and the developers as they go along.
Multiple teams in one place, product owner is co-located with the development teams
When there are multiple teams involved in the project it usually means that there are more than one business areas involved, and the teams are working on different but related pieces of the same system.
In this case, even if there is one product owner and even if the product owner is in the same building as the team having a dedicated business analyst on team is a very good idea.
With this set up generally every team will have a separate backlog fed from a “Master Backlog” created for the whole of the project.
The product owner simply won’t have enough time to do everything, and in this case the business analyst can help tremendously by acting as a proxy product owner, handling the majority of questions and helping with the product owner – team communication by working forward to spot possible areas where the different teams will have to synch their work to a greater degree.
Multiple teams, business and development is spread all over the place
There is definite need for dedicated business analysts. And not just one, probably more.
With the development team sitting in Budapest for example, while the business and the product owner located in Boston, Hong Kong and Sydney, the communication between business and development team is getting really complicated and challenging.
Business and the product owner won’t be available on a whim, getting hold of them can take a long time and the business analyst can make life easier for everyone.
Some people even risk that with such a project set up it is impossible to work Agile, but that is not necessarily true – but definitely more challenging.
Business analysts can act as proxy product owners. They can do most of the leg work and preparation, gathering most of the information for the team so they can be prepared for the meetings with the product owner or the business.
And I am not the only one who has the same opinion, Bonna Choi from ThoughtWorks Studios came up with very similar argument in her post Do we need Business Analyst on an Agile team? which you should definitely read.
I wouldn’t really call it a conclusion. It’s just my opinion that while in theory you can run an Agile project without a business analyst, and there are projects where that will work really well, most of the time it worth having one.
The reality is that on most of the projects the product owner won’t be available all the time, he will work on his normal, everyday tasks, and being a product owner on the project is an extra. Something he has to do in addition to his usual work.
And his quarterly review will be based mostly on his everyday work performance, not on his product owner activities. Also, most of the time the product owner will be new to Agile, creating product backlogs and user stories will be something completely new to him and he will need help with it. Having a business analyst can be a huge help – also the team won’t have to take time away from actually creating software to help with the backlog building.
Beware of building a wall!
Having a business analyst on an Agile team doesn’t mean that the product owner and the developers never meet! It is an easy trap to fall into and a very dangerous one!
The business analyst is not a wall or a filter. He should help both side to be able to have more meaningful conversations. He should help them so the product owner and the team doesn’t have to worry about those tasks that are not helping them move the project forward – or where they would be less effective than the business analyst.