Organizations using the Scaled Agile Framework (SAFe) might want to integrate a business analyst (BA). This proves rather difficult, since SAFe has not included this role in its framework. This leaves many organizations questioning how a BA could be integrated into the process. They opt to have a BA flesh out what needs to be developed. This sometimes leads to conflict with the Scrum teams or a requirements engineer of a team.
SAFe is a framework which has a layered structure for managing several endeavours and which can be adjusted depending on their size and the organization. It has neither mentioned the role of the BA nor that of the requirements engineer. And yet, the roles, their methodologies, and their toolset are important for solving business problems.
The question that needs to be asked is ‚how does an organization best use the skillset of a BA within or around a SAFe setup?‘
SAFe is focused on implementation
The starting point of work in SAFe are epics. It uses epics as
„a container for a significant Solution development initiative that captures the more substantial investments that occur within a portfolio.“
Scaled Agile
In order to make the initiative manageable, epics are then broken down into features which are
„a service that fulfills a stakeholder need.“
Scaled Agile
We could consider this a high-level business requirement. If, and that is a big if, if the definition of a feature in SAFe wouldn’t contain the following statement:
„Each feature is sized or split as necessary to be delivered … in a Program Increment (PI).“
Scaled Agile
A PI is a quarter of a year. Is it more important for a feature to fulfill a stakeholder need or that its development size fits into the remaining capacity of the development team? It is the latter: the feature is sliced for aspects of implementation management, not for aspects of business value.
The features are then sliced into stories which are
„short descriptions of a small piece of desired functionality, written in the user’s language.“
Scaled Agile
Unfortunately, these stories are often written with aspects of the existing implementation and have to be sized that they fit into a Sprint, which are between two to four weeks.
Epics, features, and stories have one thing in common, at least in SAFe: they all tend to be driven by aspects of implementation. How do we solve this stakeholder need technically?‘, ‚What do we need now, what can we remove, and what will fit into the PI and subsequent sprints?‘
The issue with epics
If SAFe considers the epic to be the starting point of all thinking, then it should be formulated without an implementation or solution bias. Unfortunately, they aren’t.
The business solution is a one sentence description. The business problem is not even mentioned, or problem and solution are understood as the same. By requiring that an epic states the business solution, but not requiring the need to identify the business problem, SAFe directly jumps into the solution and implementation.
Where do epics come from?
Do epics appear out of thin air? Does someone have a gut feeling, and then write a name onto a card resembling the epic? Most likely not.
SAFe proposes that an epic is supported by a lean business case which is similar to a business plan. It is supposed to describe the cost for implementing the business solution, the earnings which the epic will bring, and optionally how the business solution will be billed so the earnings can be realized.
Unfortunately, the right questions have not been asked, yet: ‚what is the business problem, how much is that problem costing me, and how much am I willing to invest to solve it?‘
Status quo vs. leapfrog solutions challenging the status quo
Defining a proper solution requires to identify and understand the underlying problem first. All too often, we quickly jump to conclusions resembling a technical solution to a business problem which hasn’t even been identified. It should be the other way around: After we have identified the business problem, we can propose possible business solutions: from changing the business process to implementing a technical solution best-fitting the status quo. But there exists another option:
We should always challenge the status quo and look for better ways of doing something. It is only then that we can identify a revolutionary and innovative leapfrog business solution which is miles apart from what an evolutionary business solution could deliver.
Once an evolutionary solution has been defined in the epic, there is hardly a need to challenge the status quo. This results in the need to define a leapfrog business solution during the writing of an epic or even before. But, leapfrog solutions don’t come out of thin air.
Books about product management paint a picture of a product manager who is a jack-of-all-trades, the product hero, who single-handedly comes up with this business solution. Next to the many other roles, this is impossible.
A business analyst is like a psychoanalyst of the business
Product managers don’t have to come up with the business solution themselves. Trained specialists who identify business problems and propose business solutions can help. One of these is the business analyst, who doesn’t come up with the business solution out of thin air, but by using a methodology and a set of tools.
BAs study the workplace, the business, the customer, or working people in general. Once they have understood the underlying business problem, they can propose business solutions.
Sometimes it is enough to coach the people in the organization to become better or to provide better products to customers. This is similar to a psychoanalyst who listens to a patient, identifies the problem, proposes possible solutions, and coaches the patient to become a better self. No patient would like the psychoanalyst to have a solution ready before he has even said a word or before the root cause has been identified.
The BA begins at the latest when the epic is created
Since the epic only states a business solution on a high level with the aspect of implementation, but the goal of a BA is to identify the underlying business problem and the best-fitting business solution, the BA must consequently be finished with the description of the business solution before the epic has been finalized.
Upfront thinking about a business problem and the optimal business solution supports the creation of an epic.
If the epic has been created to initiate the upfront thinking, it could sometimes be closed before any implementation is done, because the business analyst has identified a business solution which doesn’t require any implementation effort.
If we assume that understanding the business problem is important, then that must be done before the epic is finalized. Otherwise, how can we be sure that a proposed solution defined in the epic solves the right business problem?
Once the business problem has been well understood and the best-fitting business solution has been documented as much as needed, the BA can further support during the writing of the epic and even suggest how to slice the epic into features from a business perspective. But, as shown above, the features are usually not sliced with a business perspective, but with a focus on implementation.
Is upfront thinking about solving the business problem agile?
Absolutely! Implementing a solution for the wrong problem is as bad as not doing anything about a business problem. Thinking about the business problem and identifying the optimal business solution is agile, if the epic is written, directly approved, directly sliced into features, which are then directly sliced into stories, which are then implemented.
If an organization implements SAFe but still has yearly budget discussions after defining all epics for the next year, then that is what makes upfront thinking about solving the right business problem and choosing the optimal business solution appear to be slow and not agile.
The goal must be to define epics as small as possible so that they create value, solve a business problem, and contain no waste.
If epics are in the backlog for too long, then that’s not agile. If the implementation of an epic has started but parts thereof are not implemented right away, then that is not agile. The reason for this to happen is likely waste in the epic.
The waste in an epic will begin to stink after a while.
An epic should therefore not be a container for features which might be done sometimes in the future. Epics should be limited to what’s needed to solve the problem, nothing more and nothing less. They should be begun and closed as soon as possible.
But let’s not forget that SAFe in itself is not agile as per the definition of the product increment. Being agile and needing to wait for three months until the next product increment to change or do something don’t match.
Summary
Business Analysts have a toolset which they can put to work to identify a business problem and/or possible business solutions within SAFe, in a normal business situation, as well as within an innovation process. They are the attorneys of the subject matter experts, who have limited time available for project work, and can therefore ensure that the voices of the SMEs are heard by the development team. A good BA knows that listening to others is the key to form a strong relationship based on trust.
Since SAFe is often focused on the technical solution, the main part of the work of a BA must therefore begin at least when the epic is created and finished before the epic is finalized.
Olav's Blog 