What is happening to business analysts in agile projects

I went to a conference recently and someone asked about the impact of agile projects on the role of the business analyst (BA).

The panellists all explained that BA’s are really important members of the team. This was comforting for the audience but didn’t really address the question.

Then I ran a BA course and one of the participants asked the same question – What is the role of a BA on an agile project?

So one of the other participants summed up what nobody at the conference had wanted to say. He was a developer on an agile project that had no BAs at all and things went really well.

The developers spoke to the people from the business and they found that they could all speak the same language. In other words they felt they were better off talking directly to each other and uncovering misunderstandings and assumptions directly rather than having an ambassador (or translator) running between them.

Our hardy participant then went on to say that he thought the addition of a BA on that project would have been a distraction rather than a help.

This was disturbing news for the the other participants in the room. We discussed ways that a BA could have added value, but we found that we were trying to invent a role for the BA rather than meeting a real need.

Then our hardy participant said that he was also on a larger project where the BA’s added a lot of value.

Apparently not all the stakeholders on the large project could be fairly represented. So the BA’s went outside the project team to explain the project to those stakeholders not close to the action and to gather their needs.

So they worked very much in the same way they would do on a waterfall project, except that they needed to work with stakeholders continuously as the project evolved rather than in small bursts at the beginning and the end..

In addition the BA’s brought skills to the team around understanding processes, looking at the impact across teams of the stories and features the team were working on and asking both dumb sounding and uncomfortable questions to help the team focus on what was really important.

In other words the role of the BA on the larger project had not changed significantly. The requirements document was gone but the interviews, workshops and even some informal modelling tools were still there.

We then discussed my experience and the experience of a couple of the people who had been on a lot of agile projects.

After the discussion I promised to capture that information in my blog. So, some weeks later, this is a summary of our own unverified views.

As you will see there is not one answer to the question but several, partly contradictory ones:

Increased focus on facilitation skills

Some business analysis are excellent facilitators and since there are many workshops in agile projects, the role of facilitator has almost become the primary role of some business analysts.

Some have ended up being the Iteration Manager (or Scrum Master) because this role can be a facilitation one. Others stay in the role of business analyst but take on the running of meetings, the facilitation of requirements workshops and so forth.

This is good news for BA’s who love to facilitate but not such a good fit for strong technical analysts and BA’s who are strong subject matter experts rather than facilitators.

Merging of business and system analyst roles

I hadn’t noticed this one because i have not been working with teams that have specialist “Business – BA’s” and specialist “IT BA’s” but I am told that in some agile teams the specialist BA’s are becoming generalists, focusing on generic skills rather than their old domain.

Return of the system analyst

In complete contradiction to the idea that BA’s are becoming more generalist than specialist, some IT business analysts are apparently returning to the old fashioned role of being the one who understands the impact across systems, the impact across processes and also the requirements of the production support teams.

This appears to be because agile teams are basing more decisions on the views of people in meetings rather than the guidance provided by a technical document. This had therefore led to an increased need for someone who knows which decisions the team can make safely and which ones should involve other IT people.  Thus the system analyst BA performs part “canary in the coal mine” by becoming worried about impacts before others do and part subject matter expert in IT.

Related to this some developers are apparently migrating into a system analyst type role as they get asked to perform spikes (analysis) beyond the application specific code the team is working on. Apparently this is in addition to the role of a solution architect (who designs the technical solution) and the technical guru who leads the developers in understanding their turf.

Usability and non-functional BA / designer

Some web related teams are starting to focus on end user requirements rather than business requirements. Sometimes this involves interviewing users but it often goes far beyond this into interaction design, prototyping and modelling and fully fledged research.

Personally I don’t see this as the same role as the traditional analyst, but I do see it as a fresh new career if I was an eager young BA.

I also have my own theory that we are able to measure more and more on the web and it is getting easier and easier to measure things effectively. But at the same time very few teams take advantage of this or know how to determine what to measure. So I personally see and increasing role that would suit many technically minded BA’s, where the BA becomes the person finding out what decisions should be made on anything that is measured and then works with the technical and business teams to build the right reporting into the system.

Outside the web development teams, according to scandalous rumours, some agile teams are forgetting about non-functional requirements. This appears to be because they see stories as the only requirements on the project and only capture functional requirements through the stories. So some business analysts are getting involved in measuring or gathering information related to accessibility, portability and anything else that is spelt x-ility.  This sounds like a good thing, although I wonder if this role is best suited to BA’s with a background in the right “ilities” or with the ability to know where their own approach should give way to expert input.

Becoming the boss (product owner)

Some teams use the traditional Scrum role of “Product Owner” and this is similar to the BA role, except that the product owner makes decisions on behalf of the business. And in some teams the business analyst is falling into this role almost by accident. The danger is that the business analyst might go “mad with power” and forget to get stakeholder input but there is a good fit here for the BA who possesses commercial acumen and a keen sense of what matters to the business owners.

In some teams this role is called producer, where it also includes owning the vision for the site being developed beyond the one project.

Tester business analysts

Some teams are starting to merge the role of tester and business analyst to almost be the “consultant for all non-techo stuff” for the project. This works well in my opinion where the BA is a strong tester or even better the tester is a decent analyst. But the business analyst needs to move into testing properly and not just do “BA testing”.

Business architects and enterprise analysts

Quite a few agile projects have mistaken activity for progress in that they have done lots of coding and built cool new systems but have not provided user support documentation, process changes or business integration.  As a result these projects have delivered what they think is the project very quickly but have failed to deliver any value.

So there is an increasing recognition that agile projects have to understand and interact with the business processes, business structure, business capability and so forth. So some teams are promoting the business analyst to become a business solution architect.  This means that the BA is now responsible for process change, value measurement and other related areas.

This suits the strongly “business-technical” BA’s but is a stretch for the generalist BA’s the subject matter experts who have become BA’s by accident and the IT focussed BAs.

Technical writers and trainers

Some projects are using the business analyst to run workshops for the business or for end-users and this role is sometimes being extended to take on writing technical documents, creating old fashioned training courses and even creating videos, e-learning and similar artefacts.

This is a role well suited to some business analysts who are willing to learn new skills and push the boundaries of their old roles.

Librarians

Lean manufacturing and agile development are both supposed to be about knowledge management and exploitation. But some agile teams have made the mistake of thinking the only knowledge that matters is the knowledge needed by developers to right code.

There is a gradual recognition however that agile projects are really well placed to create user support tools, production support handover materials, improved knowledge management for business users and so forth.

But creating this knowledge is a demanding role that needs a continuing focus throughout the life of the project. It also requires the creation of knowledge in some kind of format that will live on beyond the life of the project.  For some teams and some business analyst I personally think this creates some real opportunities to define and carve out a new role as a librarian (though people seem to think we should find a different title).

Conclusion

The frequently ambiguous nature of the BA role means that the role is under threat in many agile teams. Business analysts who struggle to explain the value of the work they do are sometimes struggling with their role.

And even some very experienced analysts are finding trouble integrating the key components of their old role into the new approaches being adopted by the team.

At the same time other business analysts on agile projects (particularly in larger organisations) are finding their role is not very different from what it has always been.

And other BA’s are starting to find potentially scary but exciting opportunities if they can carve out a modified role and push themselves to develop new skills in areas related to, but not historically included in, the traditional business analyst role.