Our clients often ask us the following question: “What is the role of the business analyst in Agile development?”
Spoiler Alert: There isn’t a role for the business analyst in Agile development.
For a longer answer, we need to explore the history of the Business Analyst (BA) role.
Traditional Business Analyst Role
Business analysts (BA) are typically found within an Information Technology (IT) organization, or adjacent to an IT organization (say within a business unit, working with IT). Here we use IT to designate the organization group within a company focused on producing or maintaining solutions that support back office business operations, employee productivity, etc.
Theoretically, the role focuses on analyzing a business domain, business processes or problem domain with the purpose of improving the domain or solving problems by defining systems or improvements to systems. The analyst then works with IT to implement the systems or improvements.
Practically speaking, the Business Analyst is often a bridge between what a business unit or domain “wants” and how that “want” should be implemented with a technical solution. This bridge is very often implemented through requirements specifications. The analyst then is responsible for writing and reviewing requirements and may be involved in some level of design to implement requirements. The Business Analyst is also often involved in validating requirements, evaluating the quality of an end solution and helping to usher the system through the appropriate sign-offs and training to launch the solution.
Business Analysts are very often found within waterfall development lifecycles where solutions move through “phases” in a linear fashion and where business owners and development teams are not integrated. They exist to solve a gap between independently operating information technology teams and business units.
Business Analysts in Agile
Teams practicing Agile should not have a need for someone with a Business Analyst title. One of the Agile principles is to have “Business people and developers [working] together daily throughout a project”. Within Scrum, the role for this daily interaction is most often through someone with the title of product owner. The product owner’s role is to optimize the value the entire team delivers through proper prioritization and expression of the product backlog. To be successful, the product owner must be properly empowered by the business organization he/she represents to achieve the product outcomes. As the name implies, he/she “owns” the product and associated business outcomes. Business analysts traditionally do not own either.
Given that the product owner is now responsible for a team of ideally no more than 12 people, one should not need an additional person “helping” with story writing, backlog prioritization, etc. Given the proximity of the product owner to the team doing the work and very little need for administrative help given the ratio of people on a team, there should be no need for a business analyst in an Agile team.
What Should I Do with My Business Analysts?
If you’ve read this far, you are probably a company transitioning from Waterfall to Agile development. The question is difficult to answer, and really depends upon the capabilities of the person in question.
Transitioning Business Analysts to Product Owners
We haven’t seen this be successful in many places. But on a case by case basis, it’s possible. If the person is smart, really understands the business, is empowered by the business unit he/she represents and is committed to understanding the role of the product owner then the person may be successful. Frankly, most business analysts have existed for too long as order takers to truly lead business initiatives within a development team.
Transitioning Business Analysts to Scrum Masters
We’ve seen greater success with this approach, but it requires a lot of training. To be successful in your conversion, you will need at least some number of highly trained and experienced Scrum Masters. If everyone is learning on the job, your transition to Agile will be slow and flawed. You can afford to have some (a handful) people transitioning from the BA role but be careful. The role of the Scrum Master and the role of the Business Analyst are very different. Some people won’t be able to make the transition, and others won’t have the desire.
Keeping Business Analysts in Waterfall Roles
Your company will no doubt continue to have several waterfall-oriented teams. Waterfall is appropriate anytime negotiation trumps collaboration (again, see the Agile Manifesto), as is the case in most projects involving systems integrators (I.e. back-office corporate systems or employee facing packaged solutions used by disparate functional teams). In fact, any contract-based development where outcomes are defined in a contract is ultimately a waterfall process even if the company has deluded itself into thinking the solution is “Agile”. Take your best business analysts and transition them into these waterfall projects.
Transitioning Business Analysts “Somewhere Else”
This is the catchall category. Perhaps some of them are recovering software engineers or infrastructure engineers and will want to go back. Maybe there is a place for great business analysts within a business unit working on non-technology related initiatives. In many companies, there may be waterfall projects where they can continue to add value. Lastly, you may no longer have a role for them.