Business Analysis On ‘Agile-Type’ Projects

This week I ‘ave mostly been reading about Business Analysis (for those who remember Paul Whitehouse’s character Jesse from The Fast Show)

And, unlike Jesse’s diet and fashion tips, there is much to say about business analysis in the current project environments that are moving away from traditional waterfall methods towards – if not exactly agile methods – an environment with shorter timescales, quicker deliveries to the client and an iterative approach to meeting project objectives.

As Angela Wick points out in her insightful post on BA Times “Don’t Skip the Analysis When Moving to Shorter Iterations” some people believe that analysis is not required when using shorter iterations (whether that’s under the guise of an agile project or not). But the risks of not doing at least some analysis sometimes mean that the “big picture” is lost because the focus is on individual deliverables rather than the whole project; and the relationships and inter-dependencies between each deliverable can be forgotten.

Certainly, on agile-type projects we do not, and cannot, expend too much time on a full and detailed analysis but that doesn’t mean some analysis is not important – it’s getting the balance right that is essential. And the best way to spot a lack of analysis on a project that is already underway, according to Angela, is if there is a large backlog of defects or “enhancements”.

To locate the source of the analysis problem she suggests looking at all the issues in the backlog and analysing how they are related, then group items that impact the same users and those that relate to the same processes to better understand what is going wrong.

No Business Analysis Means Certain Project Failure

According to Brad Egeland a project without a business analyst (BA) is doomed to fail and here are some of the reasons he cites for why he believes a business analyst is indispensable:

• The BA communicates with the project client at a technical level to discuss and identify the genuine need and work through requirements so the final solution meets that need.
• The BA is the technical liaison with the client’s subject matter experts and can ensure that requirements are clear, concise and detailed. In addition they are invaluable during user acceptance testing.
• The BA provides a link to the project team technical lead to help ensure key requirements get interpreted accurately and that the proper amount of time, planning and attention is given.
• The BA helps the PM perform well by ensuring that the delivery goes smoothly and the communication with the technical team is handled properly.

 

It’s Not the Title That is Important

 

Bonna Choi discusses many of the same points that Brad raises in her article Do we need a Business Analyst on an agile team?. Bonna believes the role of the business analyst is the role most often challenged in an agile project environment but every project needs someone who can help the project team and the business stakeholders develop a shared understand of why a project is being undertaken.

Also teams can make faster decisions with a BA on board because a BA is able to provide the sorts of answers the project team need to make progress. They have an understanding of the technical detail that the client may not necessarily have and are the interface between the client and those doing the project work.

But Bonna doesn’t believe the title Business Analyst really matters, provided there is someone on the team who can deliver this type of work and drive the right common understanding of what is need to make the project succeed.