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.
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.
Credit: Steve Blais
Are you interested in learning more about becoming a good, or even better Business Analyst?
Then I highly suggest you enroll for our BA Career Coaching.
Contact us at Jadetan Enterprises Ltd via
Tel: 0872 113 1105