In the past few years, software development has been shifting more and more from traditional to agile practices. This change impacts how business analysts perform their role. Here are three key aspects of the business analysis work that are different in an agile environment:
-
The BA becomes a key player in avoiding costly software architecture problems
There are many definitions of “software architecture”. For the lack of a universal description, I’ll use here one that I think reflects the intention behind the many proposed definitions listed in the book Documenting Software Architectures: Views and Beyond: software architecture is the set of significant decisions about the organization and interaction of the components of a software product used to govern its design and evolution over time. As explained in the prologue of the same book,
Architecture is what makes the sets of parts work together as a coherent and successful whole.
The purpose of software architecture is to ensure that the software product satisfies the system’s quality and behavioral requirements. Successful software products have a solid architecture behind them, capable of addressing all the functional and quality attributes required to fulfill the business need.
When a BA works in a traditional software project, he or she is expected to detail the majority of the requirements up front, making available to the system’s architect all the information needed to understand and support the business goals. Agile projects, on the other hand, emphasize the incremental delivery of client-specified features. While slicing off a set of features for earlier release may prove beneficial, the lack of full visibility into the overall requirements as the initial architecture is defined often cause issues related to system behavior, performance, scalability, maintainability, or other crucial attribute. Such problems typically require costly rework to retrofit important capabilities that weren't identified until the project is halfway. As pointed out in the book Making Software: What Really Works, and Why,
Many agile projects succeed by doing a lot of architecting, but spreading it out across the life cycle through re-factoring. This is an effective process as long as the project stays small and noncritical, but can run into “easiest-first” difficulties otherwise.
To avoid the problems caused by poor architecture decisions that cannot be easily undone by re-factoring, a BA working on a complex agile project must work extra hard to make sure the high-level requirements are properly identified early on. In contrast to a traditional project, an agile project poses a substantial risk that the team will move too quickly into iterative design and implementation, before the critical aspects of the solution are sufficiently understood to support the right architecture decisions.
Even though in an agile project the expectation is that requirements will be defined closer to implementation (in a “just-in-time” manner), if crucial aspects of the system aren't acknowledged during the early stages of the project,chances are that one or more important quality attributes will be ignored and become incompatible with the initial architectural commitments. Here are two real-life examples that could have been avoided by more investment in upfront requirements analysis:
-
In a system that needed to store information about both suppliers and customers of an organization,the BA failed to determine early on that the same company might be listed both as a supplier and a customer. The late discovery of this requirement made it impossible to implement an optimal solution, demanding instead the use of an undesirable workaround that required the duplication of entries for the companies that had a dual relationship with the organization.
-
In an e-commerce back-office system, the implementation of features was initiated before some of the non-functional requirements were well understood. As a consequence, the team made architecture choices that allowed the right functionality to be produced, but impeded the expected security control structures to be implemented. Expensive re-factoring was required to ensure that the ability to perform certain operations was restricted to specific roles, as demanded by the compliance group.
Agile approaches emphasize the practices of minimizing unnecessary planning and documentation, and a big challenge for a BA working on an agile environment is to learn how to effectively distinguish an early analysis effort that is “unnecessary” from what’s crucial to avoid the risk of wrong architecture decisions that cannot be easily undone.
2. Business analysis skills are critical to ensure the right bundle of features is selected for each release
When releasing software incrementally, it’s important to choose the right batch of features that is both high-value and immediately useful. In theory, product owners, business stakeholders, and/or end-users should be able to make the right decisions about which features will deliver the most value in the next release. In practice, however, it’s common to see agile releases that incorporate the highest value features and still don’t enable users to achieve their goals. This issue happens largely as a result of the phenomenon of bounded rationality: a few supporting features that didn't make the cut turn out to be essential to make the release truly useful to those trying to accomplish a goal with the software.
Take for example the construction of an online store.Stakeholders could very well assign a much higher value to the checkout process than to the ability to estimate shipping costs before placing an order. If, however, the products being sold are typically large and heavy, thus incurring significant shipping costs, customers may be reluctant to create an order before checking the final price. Under these circumstances, a release that enables checkout, but does not support shipping cost estimation, may not be the best use of the available resources. It might be better to postpone another high-value feature, such as the offer of additional payment methods, in order to include in the release what could be considered a lower value feature, but that in practice represents an important supporting capability to convince customers to buy.
When stakeholders are prioritizing features, the business analyst must be able to step forward and help them use their best judgment to decide what features make up an optimal release. By asking the right questions, the BA can help the decision-makers understand not only what features will provide the highest value, but also what additional capabilities must be included to complement the most valuable features, in support of a particular type of user or business process. This is one of the most valuable contributions of a BA in an agile project: to ensure that along with the highest value features, a release incorporates all the surrounding functionality required for the new capabilities to be truly useful to the people who ultimately receive them.
3. Test analysis and design skills take a front seat in the BA role
BAs working on agile projects are more effective when they display solid knowledge of how to create quality acceptance tests that successfully cover all dimensions of the behavior and quality of software produced in short releases cycles.
In agile approaches, test analysis and design are essential components of the requirements analysis and system specification process. Acceptance tests often serve as the specification of what is required of the software, and may be captured as executable test scripts in some documentation/testing tool. When part of an agile team, the BA must be able to work with various constituents: the product owner, developer, tester, UI designer, to define effective acceptance tests for the user stories covered in each sprint or iteration.
Author: Adriana Beal spent the past 10 years consulting for Fortune 100 organizations implementing large, complex software projects. She currently works as a product manager for an enterprise-grade software-as-a-service application at Spredfast in Austin, Texas. Opinions expressed are solely her own and do not express the views or opinions of her employer.