Agile Business Analysts?

I have recently been fleshing out my thoughts on the role of business analysts in an Agile team. This is something I have historically addressed on a case-by-case basis with clients, but when thinking about it last week at a client site, I realized that I do have a general take on how the role and responsibilities of a business analyst change when a group moves to using an Agile process. Per the usual, I’ll be using Scrum as the example process where needed.

The Classical Roles

Historically the business analyst has had two primary roles. In a process where cross-functional communication and collaboration are minimized, these roles are essential. What little communication that takes place between the business and the software development teams purporting to serve them passes almost exclusively through one or more business analysts. I view the business analyst in a phased development approach as having two roles; Translator and Gatekeeper.

The Translator

The business analyst is primarily tasked with taking the needs of the business and translating them into a written document that is then handed to the software developers and testers. This role’s necessity is based upon some fundamental assumptions. First, programmers and testers are on the whole, too socially retarded to actually talk to the business persons and find out what they want. Second, the business is primarily viewed as being unable to focus its thought long enough to tell the programmers and testers what they need. Since a key value of an Agile approach to software development is to have individuals and their interactions be the driving force rather than processes an tools (see The Agile Manifesto), the obliteration of this role is a primary objective.

The Gatekeeper

Business analysts are also viewed the gatekeepers for requirements in classical, phased software process approaches. This is a somewhat unfair role, since they rarely have the authority to prevent business or technology changes, like a meter maid trying to stop an armed terrorist. It’s even more unnatural since change always happens, so it’s like the meter maid being assigned to an anti-terrorist unit with no additional training, authority, or weapons.

The Agile Roles

Some of the more extreme practitioners of Agile methodologies say that business analysts have no role in an Agile team. I disagree, provided the role of the business analyst is allowed to evolve. The roles I’ve seen them take on as valuable members of an Agile team are Facilitator, Historian, and Journalist.

The Facilitator

A high degree of collaboration and interaction take place between business and technology in Agile Software Development. The business analyst can serve a critical need in these interactions, facilitating communication between business and technology and making sure that critical areas are being covered in an interaction. This can be a more fulfilling experience for an analyst, since they often talk to one side, then go to other to pass on the information, all the while thinking, “Man, this would be simpler if you were both in the room with me at the same time.“

The Historian

The business analyst’s documentation skill is excellent for capturing significant information that often gets lost in a team of purely technical people. I have seen some great uses of business analysts in this area. One is to document the system that the team actually builds (not the big, up-front imagined system that is covered in a phased design stage). Another is capturing key technological and architectural decisions and the context in which they were made, so that when a group revisits certain items asking, “Why in the world did we decide to do that?”, they have the means to be reminded or informed why a particular path was chosen.

The Journalist

The business analyst can also be the team’s journalist, making sure the latest information makes it out to all interested parties. One creative approach I’ve seen at a client site is a business analyst who has a project blog. He posts entries after each meeting between the business and technology, documenting what new user stories were created (even scans in the story cards!), a summary of the discussions held, and documents any key decisions that might have been made. Oh, and he provides an excellent executive summary at the top that’s suitable for anyone’s review, right up to the CEO. Tell me you wouldn’t love to have that guy in your Agile team.