As agile methods become widespread in organizations, it’s not surprising to see the idea of the business analyst as a dispensable role taking root among IT project teams. After all, in agile approaches, tasks typically performed by a business analyst, such as requirements elicitation, analysis and documentation, are replaced by a conversation between customer and developers. As Kent Beck and Martin Fowler wrote in their book Planning Extreme Programming (Boston: Addison-Wesley, 2001, p. 47),
“The shorter the story the better. The story represents a concept and is not a detailed specification. A user story is nothing more than an agreement that the customer and developers will talk together about a feature. Hideous written detail is not necessary if the customer can work with the programmers while they are programming.”
In an ideal world, all projects would have an “on-site customer” available to take an active part in the software development process, representing and making clear decisions about the business and end-user needs in a just-in-time manner. In practice though, especially in the case of internal applications, it is more common to have multiple business units sharing a system that supports cross-functional internal processes, with the following consequences for a software development initiative:
1) Instead of a “single customer” with time for daily conversations with developers to clarify requirements, provide feedback on implemented features, and make decisions in a just-in-time manner, the project has to rely on a group of busy senior managers to make collective decisions about the system.
2) Achieving consensus about priorities and implementation details requires collecting ideas and final decisions from various stakeholders.
3) Refining the requirements and establishing acceptance criteria for stories in the backlog may require research and analysis activities to be performed in advance of each development cycle to support timely decision-making.
Some “agile evangelists” may argue that the described situation precludes agile adoption, because agile requires an on-site customer, or dedicated product owner, or all team members working together in the exact same room, or another unmet requirement. Again, in practice that is not a reasonable expectation. As recognized by many experienced agilists, even though the perfect circumstances may not be present, businesses still want to take advantage of the benefits of a more flexible approach to software development that can support continuous innovation, product, people and process adaptability, and improved time-to-market. And that’s where the business analyst fits in the picture.
Facilitator and problem-solver
Taking advantage of the benefits of an agile approach under less-than-ideal circumstances means adapting agile practices to the reality that businesses faces. In my consulting practice, I have been witnessing a growing demand for senior BAs to join teams working on cross-functional, complex software projects using agile methods. The addition of a business analyst to the agile team is being received with great enthusiasm by both the business and technical groups due to two main desires: to end a vicious cycle of time-wasting meetings (in which conversations about new features wander from one topic to another without reaching any conclusion for lack of a skilled facilitator), and to adopt a more disciplined approach to identifying business and user needs beyond what is explicitly stated, so that the solution built can actually meet those needs without constant rework of existing functionality.
One might argue that such responsibilities should be taken by the product owner (the role that represents the interests of the customers and other key stakeholders in Scrum, a popular "flavor" of agile). Indeed, some product owners do have the combination of skills, desire, and time to dedicate to the facilitation and problem-solving activities required to achieve consensus about priorities and user story details. If that is the case, in addition to performing their job (manage the product backlog, ensure the right balance between business goals and constraints), the product owner will be fulfilling a BA role as well. The two roles are not to be confused, though: by definition, a product owner has the authority to make decisions about functionalities and project priorities, while an analyst is responsible for helping stakeholders achieve a solid understanding of what needs to be accomplished, but doesn't have the power to cast a deciding vote on any outstanding issues. As well described by Laura Brandenburg in her Business Analyst Manifesto,
On every successful project you’ll find a business analyst. Their title might be director of technology, product owner, product manager, requirements analyst, business process engineer, VP of operations, development lead, team lead, project manager, or CTO. The title is rather irrelevant. The activities of creating alignment around a clear understanding of “done” that creates positive change is what it means to be a business analyst.
A skilled business analyst may become a key member of an agile team by performing tasks like the ones listed below, which the technical and business groups will not necessarily have the time, interest or skills to tackle:
-
Establish effective mechanisms to help stakeholders assess their needs and make timely and well-founded decisions about features, priorities, issues, acceptance criteria.
-
Perform the analytical work necessary to achieve in-depth understanding of the problem and constraints.
-
Manage conflicts using a collaborative approach.
-
Identify epics, user stories, and test conditions in facilitated sessions.
-
Research business and user problems and determine the best solutions in advance of an iteration in order to avoid delays during development caused by lack of clarity about what is required to make a user story successful.
-
Act as a “product owner proxy”, being available on a daily basis to clarify requirements, discuss trade-offs with the development team, and help ensure that the product is intuitive and easy to use.
-
Share progress with the business stakeholders and facilitate the discussion of issues arising in development.
Producer of relevant documentation
Agile places a greater emphasis on working code over comprehensive documentation, but that doesn’t mean that documentation goes away–only that it is reassessed according to the value it provides. Even though documents are not supposed to replace getting the right people in a room to work things out together, the right piece of documentation may be crucial to keep the focus of the team on the rapid delivery of business value.
Documentation (which doesn’t necessarily have to be formally writte, as it can be composed of visual representations, and even video or audio recordings) may be required throughout the life of an agile project in different circumstances, including:
-
when an iteration is about to start, and the developers need to be reminded of implementation decisions and hard-to-remember requirements (such as complex business rules that apply to a user story);
-
when the team is preparing to hand off the project to another group that will maintain the product, and readable code plus automated test cases are deemed insufficient to explain system behavior or clarify the reasons behind certain implementation choices that may affect future work;
-
when end users will start to use a new product or feature, and need help understanding how to operate the software;
-
when regulation and compliance issues require a permanent record of implemented system behavior.
Expecting business or technical team members to write readable and effective acceptance tests, or produce useful user manuals, is unrealistic in most organizations: business stakeholders and development teams rarely have the time and the combination of competencies necessary to produce such deliverables with the velocity and quality that is needed for the project to succeed. Having a skilled business analyst responsible for creating the necessary documentation (or supervising the work of technical writers doing the work) minimizes the risk that such deliverables are not ready at the time they are needed, or lack the level of detail and quality required to achieve project goals.
Well developed business analysts can help agile teams in all aspects of communication, from selecting the documentation methods and formats that are most appropriate for the project, to producing quality documents and ensuring that the pieces of document are ready at the points of the project when they are needed.
Underperforming BAs need not apply
As with plan-driven organizations, mature agile organizations are always looking for ways to improve the performance of their software process. Optimization of the development process may require tailoring agile methods to the company’s needs and capabilities, and adding a talented BA to the team is becoming an obvious answer for many of the struggles that sometimes agile teams face, from competing interests among various stakeholders, to lack of a clear understanding of the problem to be solved with the software solution.
If a skilled BA will thrive in such environment, the same cannot be said about business analysts who lack facilitation and problem-solving skills, and generally don’t add value even to plan-driven projects. For BAs who consider their job just to record what the business stakeholders say and hand it to the developers, there will be no space in an agile team. On the other hand, a BA who is proactive, flexible, successful at working across organizational boundaries, and capable of responding positively to the challenges of building software in short iterations, won’t find it difficult to fit in as a valuable contributor to an agile project. Which one will you be?
Author: Adriana Beal has a B. Sc. in electronic engineering and an MBA in strategic management of information systems. For the past 10 years, she has been identifying business needs and determining solutions for business problems for a diverse client base that includes IT, telecom, and major U.S. financial institutions.
Article image © Yabresse - Fotolia.com