I was hired as a Business Analyst in a couple of assignments a few years back. It was a good experience and I learnt a lot about the business processes of the customer, but it struck me how bad we actually performed.

A really skilled team of business developers/customer representatives were located on-site, literally besides the development team. In spite of this really great opportunity, they placed a team of BAs in between, effectively blocking the potential pipeline of feature development.

It was a really complex business scenario were we would have been helped by an agile and empirical process, getting continuous feedback. Instead the BAs were creating heavy requirements documentation upfront together with the customers. We were struggling with capturing the full requirements specifications and signing them off before handing them over to the development team.

Imagine a document driven process were all the experts are sitting in the same room! Talk about waste!

What I would like to suggest to this organisation is to get rid of the BA role to save a lot of waste, introduce an agile methodology such as Scrum and to release small releases often to get valuable feedback in the empirical process. I would also recommend to write the requirements in lighter stories instead of heavier use cases and foremost of all pair the customer with the developers instead of putting a BA filter in between. That would increase productivity for sure.

Maybe it is a good idea to let the BA and the tester roles converge, like Dave Nicolette is suggesting in Collapsing the roles of tester and business analyst? It’s not a bad idea. Testers need to know the business and BAs need to know how things are tested. Especially with the movement towards test driven development and test driven requirements (automated acceptance testing).

2 Responses to “Business Analysts Blocking the Pipeline”

[...] Read the rest of this great post here [...]

Hmmm I’m not sure about this suggestion – I think there is an argument for someone being responsible for managing requirements at least. Something programmers typically dont want to get bogged down with