What happens to the role of the Business Analyst in an Agile Utopia?

If Agile is to become the next zeitgeist for development, what will become of the traditional Business Analyst?

We all know the traditional waterfall mantra: analyze, design, build then test... underpinned by the common belief that the more you analyze up front the more you save in maintenance later on. This has had a huge impact on the way we organize our teams: separating functions and putting a heavy emphasis on theoretical modeling.

When a project kicks off, the classic Gantt chart dictates that analysts are on-boarded early for a lengthy requirements analysis stage. Once the requirements specification is 'signed off' the analysts are often relieved of their posts for the design crew to take over. The 'sign off' fest continues until eventually the user community is (invariably) force fed a UAT phase and the fledgling product is launched; all the while resources are inhaled and exhaled as the project plan demands. The project then becomes more of a way to co-ordinate a set of individual skill sets and activities.

The Business Analyst in this context needs to be equipped with the full gambit of modeling strategies and tools with a heavy theoretical emphasis often speculating a distant outcome with very little to go on. Analysis under these conditions is a risky affair often resulting in hefty sign-off protocols ensuring that the business people are invited to become accomplices in the speculation game for the protection of all parties.

'As-is' and 'to-be' models are classic approaches to understanding the business change and maintaining organizational buy-in.

The dilemma with this is: What to do with the inherent risk?

Traditional BA's analyze the hell out of an endeavor before committing resources. The real issues only tend to become known towards the end of a project when precious little can be done about it.

Let's contrast this with a glimpse of what's in store for the development teams of the future...

I think its pretty safe to say Market Agility (i.e. responsiveness to the business environment) will increasingly prove to be the differentiating factor for most companies. The business analysts will need to get better at managing the dramatic increase in pace that comes with this. 

Agile development methods seem to be an obvious evolutionary step for our trade. Mainly aimed at restoring the team ethic, Agile (in the development sense) aims to promote development iterations, partnerships, collaboration, and process adaptability throughout the life-cycle of the project. Originating from the techie camp these methods are reaching ever increasing levels of popularity and to great effect... but the progress is slow and often fraught with growing pains as IT departments flex and bend in response.  

So what can the traditional Business Analyst do to adapt? 

Here's a recommended starter-for-ten:

• Fight bureaucracy where-ever you can.

• Restore the partnership ethic where ever possible.

• Improve estimation (Look into Wideband Delphi principles)

• Abandon theory based approaches and adopt an empirical approach.

• Design experiments to answer difficult questions and resist the temptation to make ill informed decisions.

• Embrace the unknown and make (or support) decisions based on observation.

• Promote a risk based approach to testing.

• Promote continuous improvement over state change philosophy.

• Protect your objectivity. Represent the truth.

• Promote the idea of stable, high performing, cross-functional teams (as opposed to silo'd temporary functional project teams).

• Protect your credibility (DWYSYWD).