From The Archives: What Is An AGILE Business Analyst?
There is a lot of talk among business analysts nowadays about something called an agile business analyst. This appellation is generally applied to business analysts who work in an agile software development environment. This is a topic of discussion among business analysts throughout the industry. Courses are being written and delivered about how to be an “agile business analyst.” There is a discussion group on LinkedIn, with the title “Agile Business Analyst”. One thread on that discussion group was started by Leslie Monday, August 29, 2011, titled “What Is An Agile Business Analyst” and it is still going strong. There are at least a dozen other threads in other business analysis oriented discussion groups on LinkedIn, attempting to answer the same question, and I’m sure there are similar discussions being carried on in other communities around the Internet, and most likely in local IIBA and other business analyst organization meetings.
In some cases the discussions have a certain desperation to them because the agile community itself has in the past, eliminated the business analyst role from the agile software development process. The anti-business business analyst vitriol has been quite strong over the years. The claim has been that the developers can do their own business analysis and an extra person in the position of business analyst simply gets in the way.
In these discussions, there are those, myself included, who claim that a business analyst is, and really always has been agile. (A discussion started by Louise McDonnell that lasted several months challenged discussion members to come up with a clear differentiation between a business analyst and an “agile” business analyst.) The profession of analyzing the business requires flexibility, responsiveness, creativity, innovative thinking, acceptance of change, and a dependence on individuals and interactions. Such qualities are desired, if not required, regardless of whether the business analyst is involved with agile software development, traditional software development, or no software development at all.
So are agile business analysts “agile” because they work on an agile software development team? And if so, does that imply that those not working on an agile software development team are not agile? I contend that in business analysis, agility is a mindset having nothing to do with the framework in which the practitioner of business analysis works. In other words, an agile business analyst is agile whether he works on a scrum team, any other agile team, or no agile team.
Let me illustrate my point by differentiating between a business analyst working on an agile team, or a developer playing the role of the business analyst, on an agile team, and an agile business analyst. Before the agilists start screaming, I am not suggesting that this is a binary or exclusive differentiation. In the annals of agile, there is a constant reference to the difference between “doing agile” and “being agile”. I am trying to demonstrate the difference between “doing agile” and “being agile” as it relates to the business analyst.
Related Article: The Agile Business Analyst: For an Agile Team, You Complete Me
We can look at an agile business analyst manifesto of sorts to describe what an AGILE BA is. You may find that the tenets of this “manifesto” apply to you even if you are not associated with anything remotely resembling agile software development. If so then you can call yourself agile for no other reason than the acronym associated with AGILE BA.
The Characteristics Of An AGILE Business Analyst
Clearly everyone associated with agile must be adaptable, since that is the essence of agility, according to the manifesto and those who promote it. However, the adaptability inherent in the agile software development approaches is focused on the flexibility required as a natural part of software development. The AGILE BA is not solely focused on software development or defining requirements for development teams. The AGILE BA defines improvements to business processes, assists decision-makers in gathering information to make decisions, helps quality assurance test solutions and products, designs user interfaces and even steps in as a product owner, scrum master, or project manager as the occasion calls for. The AGILE BA may define a set of requirements as a standalone document to outline what must be done by the organization to move to new facilities and then prepare the user stories in a just in time approach for an agile development team. The AGILE BA is not committed or bound by any specific process (software development or other). The AGILE BA is committed to solving business problems wherever they occur in the business however they may be solved. Therefore, the AGILE BA must be able to adapt to the business process, the software development process, or even a lack of process, and to any and all management directives, and not be focused on a single process or framework.
The AGILE BA’s goal is to add value to the organization by solving business problems. While the developers are focusing on producing new pieces of working software every two weeks, the AGILE BA has a focus on the overall problem that will be solved when the entire project is completed. The AGILE BA is also the weathervane indicating when a project has outlived its usefulness and is becoming a zombie project. The AGILE BA, always having the goal or the solution in front of her, is able to determine whether the project is still on track, the problem can be solved, or the problem has already been solved. This goal orientation is the result of the AGILE BA’s system thinking capabilities and the business analyst’s ability to see the big picture in addition to the detailed tasks necessary to complete the next Sprint.
While the solution development team is focusing on completing the items on the backlog in a reactionary mode to be sure that software is developed every two weeks, the AGILE BA is looking for new approaches to solving the business problem and improvements to the business processes in which the problem exists. The solution development team must follow the dictates of the product owner as reflected by the prioritized product backlog. The AGILE BA challenges the business manager, sponsor, problem owner and users to define the real business problem behind the expressed “needs” to ensure that the solution team is solving the right problem, and not providing the right solution to the wrong problem. Innovation requires a modicum of critical thinking that may generate conflict and change, moving people out of comfort zones, and taking risks. Such risks are not commonly undertaken when the driving force is producing releasable software every two weeks and the whole idea of the fixed timebox approach to agile software development is to create a comfortable rhythm for the development team to produce software. Breaking out of this comfort zone is not a desirable activity.
The AGILE BA is a leader providing solutions to business problems and continuous improvement to the organization. This leadership factor is not achieved through authority, but through influence and through facilitation and communication. A recent book edited by Penny Pullan, titled “Business Analysis And Leadership: Influencing Change”, written for “all who practice business analysis, whatever their job title.” Suggests that “business analyst lead through their work with stakeholders as they build an understanding of what’s needed and look to the future.” The leadership of the business analyst on the agile team is usually focused on the team and the project and the emphasis in agile approaches is on teamwork rather than individual leadership. To again quote from Penny Pullan: “while many business analysts see no need to look beyond their immediate project, outstanding ones will always have one eye on the organization they work within. They realize that, in order to make change stick, they need to understand and engage widely across their whole organization. This requires an understanding of the entire system, the ability to deal with power and politics, skills and working across boundaries of culture, and an understanding of both strategy and commercial realities.” And this defines the AGILE BA.
Throughout all the AGILE BA dealings with the business sponsor, customers, process worker’s, users, solution team, technical personnel and upper-level management, the AGILE BA exhibits empathy and understanding and provides an intermediary who is a mediator, a calming center in the midst of the storm of controversy and confrontation that usually accompanies organizational change. A certain amount of empathy is needed on an agile team in order for it to function as a high-performing team. That empathy does not have to extend much beyond the team since, as defined by the agile frameworks, there is only one business person to talk to who represents the entire business organization. The AGILE BA is thinking relationship across organizational boundaries, and indeed outside the organization, empathizing with customers, both internal and external, which includes a wide range of personalities and attitudes.
Let’s face it; the agile software development team is focused on the technological issues of producing working software every two weeks. Granted, this working software must be oriented toward the business because it must produce value to the business, but many agile teams depend on the Product Owner or similar role to provide the business justification so they can focus on the production of software. The AGILE BA is unashamedly business oriented, thinking continuously about what can be done to improve the business and the business processes which drive the business. The AGILE BA is thinking about what the business needs to do to solve the business problems in addition to what the solution team needs to do. The AGILE BA is as comfortable talking to senior executives about business matters, the marketplace, and competition, as to the development team about user stories.
In a timebox driven, delivery focused agile process, the general guideline is to not plan more than one or two iterations ahead. As Jim Highsmith advises,” The agile approach assumes that the project plan is fundamentally irresolvable past a very simple approximation. There is no amount of information that will provide the resolution to the project issues beyond that point”. And that point is generally two – four weeks and within the somewhat narrow focus of the project itself: the system and the features or functions being developed. The AGILE BA is completely familiar with the problem domain, the business area in which the problem exists and is able to anticipate positive and negative impacts to other areas of the organization. However, the solution should be the best for the whole organization, and not just a particular business area. Therefore, the AGILE BA has to retain enough independence to evaluate potential solutions based on the overall impact to the organization rather than the influence of the particular business area and its managers. Solving a business problem solely for the business unit might have immediate benefits; solving a business problem from the perspective of the whole organization brings much more lasting value.
So there you have it, a clever acronym to distinguish what an agile BA is. And, as mentioned earlier, to many business analysts following the tenets stated above, the words “AGILE BA” could be replaced by “business analyst” because the tenets define the job of analyzing the business, or being a business analyst, whether agile or not.
Don’t forget to leave your comments below.
Pullan, Penny and Archer, James, “Business Analysis and Leadership: Influencing Change”, Kogan-Page Limited, 2013
Highsmith, James, “Agile Software Development Ecosystems”, Addison-Wesley Publishers, 2002