Welcome back to part 3 of the Basics of Agile series, where I focus on Agile from a Business Analysis perspective. This article introduces the Principles of Agile Business Analysis.
These principles are detailed in the Agile Extension to the BABOK® Guide (Agile Extension) from IIBA. This book, as the title suggests, is an addition to the BABOK®, also known as the Business Analysis Body of Knowledge®. Recognizing that there are special considerations for projects utilizing Agile methodologies beyond those presented in BABOK®, IIBA teamed up with The Agile Alliance to produce the Agile Extension.
The Principles of Agile Business Analysis are:
In the first article of this series, I talked about basic things being profound. Each of these principles may seem very simple on the surface. Yet, when they are understood thoroughly and combined, they are potent declarations that guide our work as Agile Business Analysts.
Here is why.
See the Whole
There are multiple ways this phrase can be applied, depending on the context. For example, on a Strategy Horizon level, it could imply seeing all of the capabilities of an organization, and how those capabilities fit together. On an Initiative Horizon, See the Whole could mean looking at all of the processes involved for a feature. And on a Delivery Horizon, it could mean having complete requirements with an understanding of how that requirement meets the broader goal.
Or, you could take another view. See the Whole could imply completeness of involvement from all stakeholders, ensuring no one has been left out. Or, have all environmental factors have been explored.
No matter how you look at it, the concept of See the Whole boils down to two things – Scope and Completeness. Do we cover the entire range of impact for the initiative or piece of work? Does it represent that range fully?
Think as a Customer
Aside from the concept of iteration, there probably has not been a concept more talked about in Agile than “Think as a Customer.” As Agile Business Analysts, doing that requires much interaction. Your guesses about what is wanted must become hypotheses to be questioned, and eventually confirmed or adjusted through your communications.
It is OK to make an initial guess and allow yourself to be wrong because the goal is to eliminate what is wrong. Eventually, this will enable you to understand what is needed and, more importantly, why it is so important.
Then, when relaying the information gathered, your voice through verbal, models, text, or any other communication, having developed that knowledge from the customer of their needs, becomes the Voice of the Customer.
Analyze to Determine What is Valuable
Value is the primary tool for prioritization. However, “value” can mean many different things depending on context and who perceives it, i.e., “Beauty is in the eye of the beholder.”
It can also depend on timing. In markets during a boom period, value can be seen everywhere. If a market busts, however, value can be challenging to find.
Value can be fleeting. That is why we analyze and why the analysis repeats over time. Especially at the Strategy and Initiative Horizons, the analysis will be repeated to confirm the necessity and priority of initiatives. Similarly, the value analysis occurs at the Delivery Horizon for the priority of work to be done for an initiative.
Get Real Using Examples
In Real Estate, often listing agents will insist that the seller stage the house so potential buyers can better visualize how the home functions. In essence, that is an example of Getting Real Using Examples.
Examples do several things. Primarily, they confirm understanding with the customer. If the example is not correct, the customer helps inform the analyst to change it. More than that, examples can be viewed in an A vs. B comparison, allowing a decision on alternatives. The examples can be of a design, process flow, calculations, or function. The beauty of examples is that once they are accepted, the example can easily be communicated to the development and testing teams as part of the requirements. In that way, examples are an essential element of a shared understanding.
Understand What Is Doable
To start, the word Doable is a relative term. Many factors can determine the feasibility of work.
That said, one of the critical elements of Agile initiatives is visibility. With visibility, all involved can see how the initiative is coming along and what is coming next. Yet if something is difficult, perhaps no one wants to admit something is too difficult for the value gained. Developers often think they can solve any problem. That is human nature for problem solvers.
Agile has a way to handle the problem. The short version is – knowing about added time or costs before performing work allows the customer to decide whether a feature is developed, altered, delayed, or removed.
A typical scenario for how that works follows this path.
At some point during what some methodologies call “grooming,” the Agile Business Analyst or Product Owner has given estimates on the work items. Those values are communicated to the customer. Then the development team has the opportunity to place their revised estimates on the work. If the estimates are significantly higher than expected, the customer would receive feedback about that feature and make a decision. This creates an opportunity to perform a cost-benefit analysis. If that assessment shows the function costs more than the customer values, then it either receives a lower priority, a revision, or it is canceled.
Alternatively, doable can be a firm constraint. The Agile Business Analyst must understand the capabilities available to the team. Perhaps a technology is not as stable as thought. Maybe we do not have a critical resource. In those cases, no matter what the value is, that feature is not doable until the constraint is removed, if removal is possible.
Whether “doable” means additional time or resources, or technical limitations, in either case, these items may generate a change request to account for the extra time or resource requirements.
Stimulate Collaboration and Continuous Improvement
I think this is two different items, but there are more areas where they overlap than where they do not. There are some areas, such as manufacturing, where improvement can come from process observation and adaptation based on empirical data. The counter-argument is you could acknowledge that the Agile Business Analyst would not know about those empirical computations unless told in some way.
Given that these are not synonymous (but mostly overlap), the point of collaboration is to bring about improvement. Every interaction with a customer, subject matter expert, or development team has the potential to make the result better. All collaboration, therefore, contributes to Continuous Improvement. This principle is a reminder to take advantage of that opportunity.
The Agile Analyst does need to stimulate collaboration. Customers are busy, and it will take an effort to convince them of the need to engage. Yet with Agile, gone are the days when the responsibility for the result is wholly handed off to design and development. Now, to some extent, everyone is responsible for outcomes. Often a reminder that unclear or incomplete requirements are an unacceptable risk can help a customer understand just how important collaboration is to the effort.
Avoid Waste
When I said everyone is responsible for outcomes, that holds for successes and failures. Avoiding Waste means avoiding failures such as rework, missed requirements, or features not directly traceable to Customer priorities. Waste could be not seizing the opportunity to change – an opportunity cost. It could be that the team did not work efficiently. Or the work did not function properly. All of these require revisiting what has been done and creates churn.
The point of the previous six principles culminates in avoiding waste. That means no waste in the final deliverable. It also means no waste in any step along the way. Waste can also be seen in cycling through discussions about the same feature due to indecision during the requirements gathering sessions. Waste can be seen where communication is either not clear, or not received clearly, requiring repeated attempts to clarify. In those cases, again, it comes back to feedback and experimentation, so that the need is observed, an improvement attempted and results confirmed.
So waste can take many different forms. But does that mean any repeated effort is waste?
No.
Perhaps at this point, it would do well to define waste, or at least describe it as associated with different roles or initiative phases.
What is Waste?
I’m not opposed to asking what seem like obvious questions. In practice, if the problem of waste were simple, then we would have a lot less of it.
Keep in mind that Agile is iterative, so there are some elements of repetition. Repetitive tasks may or may not be wasteful. It depends on the purpose of those tasks.
Next, remember that decisions may differ once a hypothesis is confirmed or refuted, and often the experiment is repeated to show results over time. This is especially true in the Strategy or Initiative Horizon. So the work of analysis is often repeated. Yet, the goal is not to have wasted effort. The effort of analysis must have a purpose toward helping make the best decisions.
Alternatively, there is waste associated with the deliverable. There are a few sources for these kinds of waste. First, if the requirements are not complete and correct, then the deliverable will be wrong. If you use the wrong map, you will not get anywhere. Likewise, incomplete and incorrect requirements will leave the team going in circles instead of making progress.
If the team does work that is off the script, that is another form of waste. On my first Agile assignment, a developer reported that he was being pulled away by other responsibilities. That was an issue that affected the capacity of the entire team. After recognizing the problem, we had the developer refer any outside request for his time to me. Technically, in that organization, the Scrum Master should have handled that, but that role had gone through some change in personnel (3 in 6 months).
If the team does something that should have been at a lower priority, again, that is a form of waste. Work should be done with the most valuable item first, so long as those requirements are complete and correct. Agile addresses this through collaboratively reviewing the requirements, features, and functions with the customer to determine what is most valuable.
Finally, there is waste due to error. If everything were perfect as envisioned during design, there would be no reason to test. However, we need to realize that testing is the last line of defense against a problem going into production. This is why there are multiple layers of testing, by members of the development team, by specialized test engineers and as part of User Acceptance Testing.
I have spent much time on Avoid Waste. Yet, as you can see, the prior six principles all play a part in Avoid Waste.
When you think of it that way, perhaps this entire article can be re-purposed as a primer on how Agile attempts to avoid waste.