Unfortunately for the business analyst (BA), much of the literature regarding agile development focuses on the perspective of the developer, largely ignoring the role of the business analyst. BAs play a key role capturing requirements on large, software-intensive projects. Teams are co-located where programmers and their "customers" interact directly as a means of eliciting requirements. Organizations that are moving toward agile development may wonder if a has a role in agile software development. The answer, as addressed by this paper, is a resounding "Yes."
Business Analyst's Traditional Role
Having a BA on an agile team will complement the technical knowledge of the developers, reducing the risk that the team will only see one side of issues. When it comes to a software project, the typical BA has one foot in the systems world and one in the business process world. According to the International Institute of Business Analysts (IIBA), a business analyst focuses on the "set of tasks, knowledge, and techniques required to identify business needs and determine solutions to business problems."[i]
The solution is not simply a system solution but a holistic business solution, extending beyond the typical focus of a software developer. A BA is typically adept at working with business processes in the abstract rather than the concrete. His responsibility is to see the big picture, which includes the business context as well as the operation of the system. Developers, on the other hand, tend to view the operation of the system in terms of the concrete operation of the software. Their focus tends toward understanding how to make the specification operate in terms of software. [ii]
A BA's traditional tasks consist of determining functional and non-functional requirements using a variety of elicitation techniques, communicating requirements to business and technical people, estimating requirements, defining requirements attributes, prioritizing requirements, identifying and managing stakeholders, defining and reporting on metrics, managing the scope of requirements though base lining and change control, and ensuring that the requirements are validated. In order to perform these tasks, a BA has a different skill set from that of a developer.
BAs must be good communicators who can interact with a varying audience. They must be able to communicate in the language of the business - at a level equal to the stakeholder - and they must be able to understand and use technical terms when communicating with the development side of the team. The BA must have strong negotiating, presentation, and writing skills. This skill set is not common among software developers. BAs on an agile development team complement and extend the skills typically found in development teams.
Customer on Agile Teams
Agile development doesn't happen without support from customers. According to Vinekar, "using an agile approach entails formidable responsibilities on the client's part" where the customer will have a hand in "identifying and prioritizing features and continuous, active, collaboration throughout the development."[iii] A successful agile team requires the right customer with a combination of aptitude and ability and a team that is willing and able to work closely with the on-site customers.
If more than one on-site customer is needed, each customer's vision must be aligned to represent the same ultimate vision. If any of these points are not true, the agile development project may experience significant difficulty. A highly knowledgeable customer will be in demand from the operations side of the business and from the agile team. There is a great temptation within the business to pull an expert customer from a development project in order to address operational issues, often times leaving a junior, less knowledgeable (and presumably more expendable) customer representative on the team.[iv]
The BA can help in two ways: by reducing the workload on the expert customer and by acting as a mentor for junior customers. The knowledge and skill set of the BA includes techniques for eliciting requirements. This can ultimately reduce time constraints by efficiently eliciting requirements and guiding the expert customer. For example, the BA can use storyboards for visually-oriented customers, interviews when requirements are complex, and either focus groups or requirements workshops when several customers are involved.
A typical BA is skilled at a variety of elicitation techniques. The BA can help train the junior customer to specify good requirements, aiding him to understand the context of the requirements and the ramifications of the requirements. Ultimately, the BA can act as a liaison between the junior on-site customer and the experienced subject matter expert, helping the junior customer to learn more about the product and be effective in specifying requirements.
Getting the Requirements Right and Getting the Right Requirements
BAs specialize in requirements and have the skills to ensure quality; namely that the requirements are complete, correct, feasible, necessary, and unambiguous. BAs are also trained in evaluating the impact of requirements changes. Both of these skills are increasingly important in agile development where face-to-face conversation is the preferred means of communication and requirements are expected to change.
Requirements serve as an understanding of what should be created not only from the perspective of the requirements consumer (the developer) but also from the perspective of the provider (the on-site customer). A close relationship between the on-site customer and development makes formal, written documentation unnecessary in agile development, especially since requirements are expected to change. The customer is assumed to be available to ensure the correct interpretation of the requirements, so detailed documentation doesn't add enough value to the bottom line product to be worthwhile.
Face-to-face communication may be the fastest mechanism, but verbal communication is notoriously imprecise and prone to both interpretation and change. Often, customers specify requirements and do not appreciate the impact of what they've said will have on the ultimate solution. It is not uncommon for customers to miss the interplay between requirements and specify new requirements that conflict with other aspects of the system.
Certain requirements are critical in that they have a significant impact to the operation of the entire system - any changes to these types of requirements would ripple through the system. These requirements must be documented so as to reduce any misunderstanding or assumption. BAs have the technical writing skills to document requirements, using both text and diagrams. More importantly, they are experienced in identifying and tracking the relationships of requirements to business objectives.
Aside from helping customers appreciate the impact of their requirements, BAs typically have the skills to develop visual models. Several methodologies, including the IBM Rational Unified Process (RUP), suggest maximizing visual models of requirements since visual models are easily changed, are absorbed faster than text, can be more precise than text, and are quicker to develop. When it comes to documenting requirements, both textually and visually, BAs can greatly help the effort by aiding the customer with correct quality specification or requirements.
As an example, a given customer may be very well versed in the current system, so well versed in fact that he has difficulty explaining the operation and requirements of the system in terms that a non-expert can understand. The BA can help in such a situation by collecting a glossary, developing good definitions, and graphically depicting the operation of the system. The BA can act as a sort of translator, putting the requirements in terms that the agile team can better understand.
Multiple Customers
Frequently, the stakeholders and on-site customers are different people. It is impractical to have all stakeholders on-site as part of the development effort. The BA can act as a coordinator, working with the stakeholders to understand their vision and assisting the on-site customers during requirements specification to ensure that the requirements do not conflict with the stakeholders' vision. The BA can also act as a coordinator when more than one customer is involved in the project. Projects can fail if the on-site customer who is specifying the requirements doesn't have a good understanding of the ultimate project vision.
The original extreme programming project (C3) went over budget and was cancelled precisely because the requirements specified by the on-site customer prevented the team from moving toward the stakeholders' "big picture."[v] In such cases, it is the BA's responsibility to keep the project aligned with the overall vision by coordinating both aspects of the development effort though meetings and documentation, making sure that the requirements are on target with the vision.
Aside from on-site customers being aligned with the overall vision, there are a number of situations where multiple customers must be engaged in an agile project, complicating the project even further. Agile development teams should be small, around ten people. Larger projects often require multiple teams of agile developers working on the same product for multiple iterations and each team would necessarily have a different on-site customer. A complex product may also require multiple specialist customers. In either case, multiple customers must all share the same common vision and goals. Coordination will ensure that each is providing specifications that are synchronized. Engaging BAs as business savvy coordinators makes sense in such a situation and is aligned with the skill set of BAs.
Summary
Teams that are practicing agile development would do well to engage business analysts. Due to the collaborative nature of agile development, the BA's skill in seeing both the business and system perspectives of the product can be vital to the success of an agile development effort. Including a BA who can act as a liaison, facilitator, and documentation specialist on an agile team will complement the developers and help reduce the risks found on teams with homogenous skills.
As a liaison between the on-site customer and the development staff, the BA can speak the language of both the business and the system and can aid in gauging the technical feasibility of the business needs, ensuring that the development team sees the larger business context. A business analyst can help both parties see incompatibilities of a requirement from the technical or business perspective and take advantage of reengineering the business processes to make the software more efficient.
As a facilitator, the BA can coordinate multiple customers. The business analyst can serve as the point of expertise for multiple projects, attending requirements specification and product demonstration sessions for each of the customers.
As a documentation specialist, the BA can ensure that the impact of a requirements change is understood. The BA can also use visual modeling to help specify the system with greater accuracy than either textual or oral documentation.
The responsibilities of the BA do not change dramatically with agile development, only the formality of the BA's work. The BA can still be responsible for functional and non-functional requirements, clearly communicating and managing requirements. The BA can still be active in identifying and managing stakeholders, managing scope of requirements, and ensuring that the product matches the requirements and achieves business objectives.
About the Author
Michael York is co-founder and Executive Vice President of Cardinal Solutions Group, an IT consulting firm with more than 200 professionals in Cincinnati, Columbus, Charlotte and Raleigh, NC. Since starting Cardinal Solutions with Kelly Conway in 1996, Mr. York has focused on the development of Cardinal Solutions' software delivery capabilities and business development. Previously, Mr. York was one of the co-founders of PCS Technologies, a software development firm established in 1985 that specialized in distribution management systems for large consumer retail companies. PCS was acquired by Retek in 1995 (Oracle acquired Retek in 2005).
[i] International Institute of Business Analysts, Business Analysts Body of Knowledge 1.6, 2006 accessed on 10/1/07 from http://www.theiiba.org
[ii] Weinberg G. The Psychology of Computer Programming, Dorset House Publishing Company, 1998.
[iii] Vinekar V, Slinkman CW, and Nerur S. Can Agile and Traditional Systems Development Approaches Coexist? Information Systems Management 2006; 23(3), pp. 31-42.
[iv] Stephens M, Rosenberg D. Extreme Programming Refactored: The Case Against XP, Apress, 2005.
[v] Harvey Herela, (2005) Case Study: The Chrysler Comprehensive Compensation System, retrieved 10/04/07 from calla.ics.uci.edu/histories/ccc
