10/02/2019
If you're thinking that the Agile methodology doesn't make clear the business analyst's job...well, you're not wrong. However, you may be looking in the wrong place.
"A Guide to the Business Analysis Book of Knowledge (BABOK)", says that a business analyst is (emphasis added):
...any person who performs business analysis tasks...no matter their job title or organizational role. Business analysts are responsible for eliciting the actual needs of the stakeholders - which frequently involves investigating and clarifying their expressed desires - to understand underlying issues and causes.
That, of course, isn't a job -- it's a set of tasks that might be part of several different jobs. What's easy to lose track of, though, is that these business analyst tasks are essential to maximizing the value of the Agile team to the organization.
Focus on Analyst Tasks
The key issue, according to the institute, is that person performing these business analyst tasks "play a role in aligning the designed and delivered solutions with the needs of the stakeholders." Notice that the analyst isn't necessarily responsible for designing or implementing a solution. Instead, the business analyst's job is to ensure that the delivered solution is a real solution for the organization and not just something that the team wanted to build -- that the work the team does is valuable.
"Valuable" isn't an absolute -- what's valuable to one organization can be useless to another. To deliver solutions that are valuable to the organization, an agile team must understand the trinity of problems, issues, and results:
- What are the real needs of the business (the problems)?
- What would address those problems (the issues)?
- What will fit with the organization's existing systems (the goals)?
Understanding all three components of this trinity is essential because, for the team's work to be valuable to the organization, the work must address the needs of the business both in a way that works and in a way that achieves the organization's goals.
But, even after devising and developing a solution, these business analyst's tasks don't end. The team also should drive the changes required to implement the solutions: It must deliver the value. Further, these tasks are going to require all the stakeholders to collaborate. That collaboration isn't going to happen by accident -- some level of facilitation is required and facilitation is, again, a business analyst task.
This list of tasks is probably already more than can be performed by one person. As a result, there are probably several people on the team performing these tasks and they may have a variety of job titles, including, 'end user,' 'enterprise architect' and 'product owner' (or even 'business analyst').
Agile Principles and Analyst Tasks
This relationship between business analyst tasks and the Agile development style isn't an accident. If you look at the twelve principles of Agile, you can see that most of those principles are directly related to typical business analyst tasks.
These four principles depend on business analysis input:
- Highest priority is customer satisfaction, through early and continuous delivery of valuable software: Business analyst tasks help ensure that the software that is built and delivered is, in fact, valuable to the organization
- Welcome changing requirements, harnessing change for competitive advantage: It's the business analyst's tasks that help identify competitive advantage and the changes that will achieve that advantage
- Deliver working software frequently: Of course, "working" software goes directly to deciding 'what counts as done': does this deliver the promised value? And, until the the solutions are integrated into the organization, the value isn't really delivered (and we're back at that facilitation process, again).
- Continuous attention to technical excellence and good design: "Good" design, of course, means: "Is this really valuable to the organization?"
For all four of these principles the business analysis task around understand the trinity of needs/issues/goals and understanding what's genuinely valuable to the organization are essential.
But it doesn't stop there: Another three of the principles of Agile require facilitation, which is a key business analyst task:
- Business people and developers must work together daily throughout the project
- Face-to-face conversation is the most effective way to convey information
- Regular reflection to tune and adjust the behavior of the team
In Learning Tree courses, we go beyond these principles to discuss the concrete tasks that require a business analyst. Those include eliciting requirements (and empowering other members of the team to do the same), managing those requirements, and developing a system of metrics to determine both how successful any solution is and how the team is growing and developing.
By the way, if you're interested in the specific skills that a BA needs to deliver on those goals, Steve Blais at BATimes has a great acronym for summing them up.
Business Analyst Roles in an Agile Team
And once you start talking about the skills required, that leads to one job role that seems tailor-made for the business analyst skillset: The role of the Product Owner.
The Product Owner role only became fully recognized in 2010 in Roman Pichler's book "Agile Project Management with Scrum: Creating Products That Customers Love." It's not an accident that the title of the book that started defining the Product Owner's role has, as its subtitle, "Creating Products That Customers Love." The Product Owner is responsible for ensuring that the team is focused on delivering products that have real business value -- that address the trinity of problems, issues, and goals. That definition brings us right back to the business analyst playing "a role in aligning the designed and delivered solutions with the needs of the stakeholders."
Obviously, for a solution to have real business value, return on investment and total cost of ownership must be assessed (another business analyst task). However, value to the organization isn't just in the numbers. Solutions must also contribute to the organization's mission, which may involve intangible benefits. An organization that prides itself on software that's "easy to use" may not be able to quantify the benefits of improving the user experience but does know that constantly improving that experiences is essential to the organization achieving its goals. Again, a business analyst will be conversant with both these quantitative and qualitative metrics.
However, as Roman himself points out in a blog post, moving business analysts into the Product Owner role requires the business analyst acquire new skills -- it can even go horribly wrong if the BA becomes a proxy for the real product owner (as Roman also describes in his blog post).
While Product Owner is the obvious role that requires business analyst skills, it isn't the only role where those skills are essential to the team. It may, in fact, be better to have the business analyst as a team member.
For example, the Agile team always has more potential items it could do than the team can do right now. A critical tool for making good decisions about a team's backlog of items is the Product Roadmap. The Roadmap helps the team decide which items are more valuable than other items on according to the items' value to the business (there's that "value" word again). Helping create that Roadmap is an area where business analyst's skills are essential and should be a team activity. And, when it comes to grooming that backlog, Rich Stewart at AgileConnection provides an example of how business analysts can work as team members to help reduce the demands on the Product Owner to make the team more effective.
You may not be able to see a "business analyst" job title in an Agile team. But wherever the value of the team to the organization is addressed, someone performing business analyst tasks is going to be required. That opens quite a lot of opportunities for a business analyst, including the critical role of the Product Owner. But, as Rich Stewart says in his blog, if you're really being Agile, you should be creating the BA role that your team needs.