Basics of Agile part 3 – The Principles of Agile Business Analysis

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:

Agile Extension to the BABOK®  Guide – section 2.6

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 fully and combined together, they are powerful 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 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 that are clearly defined 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. Also, have all environmental factors have been included.

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 a lot of interaction. Your guesses about what is wanted must become hypotheses to be questioned, and eventually confirmed or adjusted through your interactions.

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 allow 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 initial 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 difficult to find.

Value can be fleeting. That is why we analyze, and why the analysis is repeated 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 will be performed 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 the seller stage the house, leaving some furniture in it 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 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 are able to see how the initiative is coming along and what is coming next. Yet if something is difficult, perhaps no one wants to admit something just is too difficult for the value gained. Developers often think they can solve any problem. That is just human nature for problem solvers.

Agile has a way to handle the problem. The short version is – knowing about added time or costs prior to performing work allows the Customer to decide whether a feature is developed, altered, delayed or removed.

A common scenario for how that works follows this path.

At some point during what some methodologies call “grooming,” the Agile Business Analyst or Product Owner have 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. In effect, this creates an opportunity to assess the value of the work against the value of the feature, aka a cost benefit analysis. If that assessment shows the function costs more than the Customer values, then perhaps it receives a lower priority, gets a revision to remove “gold plating” or it is eliminated from the work entirely.

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 change request to account for the additional time or resource requirements.

Stimulate Collaboration and Continuous Improvement

Personally, 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. Classic “chicken vs egg” conundrum.

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 end result better. All Collaboration therefore contributes to Continuous Improvement. This principle is a reminder to take advantage of that opportunity.

Collaboration does need to be stimulated though. Customers are busy, and it will take effort to convince them of the need to engage. Yet with Agile, gone are the days when the responsibility for the end-result is completely 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 expensive 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 can be not seizing the opportunity to change – an opportunity cost, that the work is not created efficiently, or it was produced quickly but does not function properly. All of these require revisiting what has been done, and creates a churn in the work.

The point of the previous 6 principles is culminated in an effort to avoid waste. Obviously 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 anyway?

I’m not opposed to asking what seem like obvious questions. In practice, the problem of Waste is not so simple. If it were, then we would have a lot less of it.

As I begin discussing waste, I believe it is important to 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 task.

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 to not 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. I was a Product Owner on my first Agile assignment when every few days one developer started reporting 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, it is important 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 a lot of time on Avoid Waste because of it is importance as a risk to the initiative. Yet, as you can see, the prior 6 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.

Next in this series, a study on how planning works in Agile.

Advertisements

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: