Many organizations have an IT role called business analyst, sometimes called system analyst or simply just "analyst." No matter what they're called, these professionals serve as bridges between the development staff and your project stakeholders. Business analysts work with project stakeholders to identify, document and validate requirements. They may also help to scope the system, identify potential areas of automation and reengineer the underlying business process. Business analysts work with developers to translate those requirements into something that they understand, and then translate developers' subsequent questions into something the stakeholders can understand--thus, the cycle continues.
Why did many organizations adopt the idea of having business analysts on staff? The general reasoning is that developers don't have the communication and modeling skills necessary to elicit requirements effectively, and sometimes they even lack the inclination to do so. Furthermore, our project stakeholders typically don't have the skill set necessary to effectively document their own requirements, and therefore need someone to guide and facilitate their efforts.
In theory, this approach should work quite well, and in practice, it often does. For many organizations, the addition of traditional business analysts has clearly improved the quality of the requirements elicitation and analysis modeling. It has also opened up communication between the "tech weenies" in IT and the "business morons" that the system is being built for--clearly a step in the right direction.
Becoming Barriers
Unfortunately, however, the traditional concept of the business
analyst isn't ideal. Although business analysts can act as a
bridge between the two groups, they can also be a barrier. On the
Agile Modeling (AM) mailing list, Ron Jeffries depicted the
communication approach of traditional business analysts as
"stakeholder => business analyst => developer => business analyst
=> stakeholder." This looks a lot like the telephone game,
doesn't it? The signal degrades between hops, decreasing the
chance that the actual message will arrive intact. Although a
highly skilled business analyst with excellent communication
skills will reduce this problem, it will never disappear.
Because they're communicating with an intermediary, your project stakeholders don't have as much influence over the software as they may think. They're influencing the traditional business analyst, and the models and documentation that these people create, but have no direct sway over what the developers are creating.
Another inherent problem is that the task of business analysis will be stretched out. Instead of Iterating to Another Artifact, as AM suggests, such as to a design model or even source code, traditional business analysts will probably focus on expanding the artifacts that they specialize in. Not only is your development effort likely to devolve into a more serial process, instead of an iterative and incremental approach as suggested by the Agile Alliance, the business analysts are likely to develop more documentation than is required.
With traditional business analysts in place, developers aren't given as many opportunities to improve their own communication skills or learn about the nuances of the business, because they have little or no direct contact with users. Nor are they given the chance to discover that the "business morons" are actually pretty smart after all, with knowledge worth learning. Similarly, project stakeholders miss the opportunity to learn about how software is developed and to discover that the "tech weenies" are actually very interesting people.
How can business analysts be more effective? AM suggests that development teams follow the practice Active Stakeholder Participation, in that they work closely with their project stakeholders. First, let's assume that you are able to co-locate your development team with your project stakeholders, an ideal situation that you should always strive to achieve. In this situation, the agile business analyst should be just another one of the developers on the team, leading requirements and analysis modeling efforts as needed, working actively to facilitate communication within the team, mentoring developers in business analysis skills and perhaps even mentoring project stakeholders in development skills. Ron Jeffries says it well in his September 2001 article "Business Analysis in Extreme Programming" at http://www.Xprogramming.com: "This begins with a simple change of focus, from 'We'll go out and find out what the customers want and bring it back,' to 'We'll go help the customers figure out what they want, so they can tell us.' This change of focus leaves control in the hands of the customers, and makes all the difference."
A critical skill that an agile business analyst brings to the table is the ability to investigate and understand how the business actually works, as opposed to how developers think it works or want it to work. Agile business analysts also perform non-business analyst activities, perhaps pair programming with one of the developers on business code or working with users to develop acceptance tests. In this way, the agile business analyst grows his or her own skill set over time.
Let's assume the situation isn't ideal--you're unable to co-locate your developers and your project stakeholders. In this case, the agile business analyst shifts into something closer to the traditional role, that of trying to bridge the gulf between developers and project stakeholders. They would strive to have the project stakeholders working with the developers and therefore try to get these people together as often as possible by facilitating conference calls, videoconferences and online meetings between the two groups. Perhaps they'll help to arrange periodic co-locations where some project stakeholders travel to the developers, or vice versa, to enable direct interaction between the groups.
The fundamental role of the business analyst focuses on improving communication between developers and project stakeholders. Traditionally, this often meant forming a bridge between the two groups. Though this was a definite improvement in some situations, it erected barriers. Now is the time to take the next step, to become more agile and use business analysts as communication mentors/coaches. This isn't to say that every existing business analyst is qualified to become a communication mentor, but chances are that your pool of business analysts is a good place to start looking for likely candidates.
I'd like to thank James Bielak, Ron Jeffries, Paul Oldfield and Paul Tiseo for the feedback they provided on the Agile Modeling (AM) mailing list regarding this topic.
Recently on the Agile Modeling Mailing List:
The Vision of Agile Data
Data is clearly an important aspect of software-based systems, a
fact that the information technology (IT) industry has understood
for decades, yet many organizations still struggle with their
approach to data within their software processes. The goal of the
Agile Data (AD) methodology is to define strategies that IT
professionals can apply in a wide variety of situations to work
together effectively on the data aspects of software systems.
This isn't to say that AD is a "one size fits all" methodology.
Instead, consider AD as a collection of philosophies that will
enable IT professionals within your organization to work together
effectively when it comes to the data aspects of software-based
systems.
Politics
Politics is an unfortunate reality within every organization,
something that developers need to accept and learn to deal with.
Over the years, I've noted two vastly different types of people
in IT organizations. At one end of the scale are the heads-down,
"I'm here to build software" people, and at the other end are the
folks with superior political skills, yet scanty practical savvy.
Whenever these types conflict--say, proposing an architectural
approach to a new system--the political group invariably wins,
even though their proposal may not have much hope of working.
These people succeed only because they have the political skills
required to get their point across to management. Needless to
say, this discussion was interesting.
Questionnaires
A member of the RUP forum wanted to know how he could write and
distribute questionnaires to his project stakeholders to gather
initial requirements from them. I cross-posted my response to the
AM mailing list, where the conversation took off. Many people,
including myself, were concerned about this practice, as we felt
it didn't reflect the philosophy that developers and stakeholders
should work closely together. Documentation is the least
effective form of communication; therefore developers should use
questionnaires only as a last resort. With questionnaires, you
run the risk that they'll simply be ignored, or worse yet, your
stakeholders won't understand what it is you're
looking for and will go off on a tangent.
Recommended Online Resources
The Agile Alliance Home Page
(http://www.agilealliance.org)
is the best starting point for anyone interested in learning more
about agile software development.
"Agile Analysis" by Scott W. Ambler
(http://www.agilemodeling.com/essays/agileAnalysis.htm)
explores how to take an agile approach to analysis and explores
the concept of an agile business analyst in greater detail.
The Agile Data Home Page
(http://www.agiledata.org)
is the working page for the Agile Data method. Interesting things
are starting to happen here, so join in the discussion.
Agile Documentation
http://www.agilemodeling.com/essays/agileDocumentation.htm
Agile Modeling Mailing List
http://www.agilemodeling.com/feedback.htm
Agile Modeling Training Resources
http://www.agilemodeling.com/training.htm
"Business Analysis in Extreme Programming" by Ron Jeffries
(http://www.xprogramming.com/xpmag/BizAnalysis.htm)
is an insightful look at the role of business analyst on an XP
project.
RUP Forum
http://www.rational.com/support/usergroups/index.jsp
