Category: Business Analysis

BACCM: Impact on Knowledge Area 2. Elicitation and Collaboration

BACCM: Impact on Knowledge Area 2. Elicitation and Collaboration

In previous articles, I have discussed how Business Analysis has suffered an identity crisis of sorts. But if there’s one area which people think is core to Business Analysis, it is most likely summed up by the Elicitation and Collaboration Knowledge Area. You’d think I’d be cheering for that. Not quite.

BABOK V3

Business Analysis involves so much more than determining and confirming requirements. Yet without Elicitation and Collaboration, much of the analysis effort could not even begin. In many ways, this is often a starting point for getting into the “what are we going to do” for this product, where Planning and Monitoring (KA-1, which I also wrote about previously) tends more toward administrative endeavors – determining how is the Business Analyst going to do their job.

The Elicitation and Collaboration Knowledge Area describes the tasks to be used to gather information and verify findings. Elicitation must be a multi-directional process, which is why it is paired with Collaboration. The ideas discussed from one stakeholder often influence discussions with others. As the saying goes, “Everyone is smarter than anyone,” and that saying could be a model for Elicitation and Collaboration. Involving everyone (or representatives of constituent groups) in the best way possible, whether by one-on-one interviews, focus groups, JAD sessions, surveys, or other means, is the primary task of this Knowledge Area. And the primary result of that effort is the gathering of requirements and supporting documentation. 

But it doesn’t end with the stakeholders as the sole focus of elicitation. Collaboration with the development team and other technical or support elements is also a critical aspect of this Knowledge Area. This additional feedback will make the resulting product successful. Without it, not so much.

So, with Elicitation and Collaboration in mind, we will look at how the Six Core Concepts apply.

Change

Here, the word “Change” refers to the scope of the analysis. It is the definition of what the analysis effort is intending to explore. During Elicitation and Collaboration, the analysis will collect and determine the characteristics of the “Change,” including impacts and concerns. Several factors can determine the techniques and depth of the Elicitation and Collaboration effort, including environmental factors, cultural factors, stakeholder’s interests, existing documentation and the nature of the change. So the Core Concept of “Change,” when applied to Elicitation and Collaboration, involves assembling all the details surrounding the requested “change.” I know that sounds a bit cyclic. Yet, when you get past that, the Core Concept of “Change” is the primary boundary and driver for the other six Core Concepts during Elicitation and Collaboration.

You may be thinking that all 6 Core Concepts are supposed to be viewed as equal within the BACCM. However, I didn’t elevate Change over the others. Change does provide a boundary and a driver for everything else. But everything else also helps define what Change is, so it all comes around.

Context

Context is always present and must be understood. 

Say someone built a great Lawn Mower. It’s Zero-Turn, rugged, has a 70″ cutting area, and has mulching capabilities. And – get this – it is Self Driving. Just lay back and drink your lemonade (or whatever) while it runs circles around your hammock. And when you think it doesn’t get better – get this – it’s Solar Powered. Well, technically, it’s battery-powered but uses a Solar charging station. So there’s no engine noise, no emissions, and no runs to the gas station with the smell stinking up your car. And since it’s a mulching mower, there are no cuttings to worry about. This mower won’t spray you with clippings while you’re drinking that lemonade in the hammock. It runs for 4 hours when it’s batteries are fully charged. It finishes your yard in 40 minutes. Attachments include a built-in edger and trimmer. Life is good! 

But the project which funded this great device was NASA’s next deep-space mission. As great as the Driverless, Solar Powered, Mulching, Edging, Trimming Lawn Mower sounds (whisper-quiet actually, so it doesn’t sound), it’s probably not a good fit for what NASA has in mind. Although many possibilities have been discovered in what NASA calls “the Goldilocks Zone” (not too hot, not too cold), we’ve yet to find vegetation on other planets. The time spent developing this machine was wasted and has delayed the multi-billion dollar space exploration project for a year. The developer of the super-mower just got charged with obfuscation of government funds and will likely serve ten years. 

Putting aside the silliness of the above scenario, the point does remain – Context can mean everything to the success or failure of the project. Whatever the team does must fit the context. Things like the platform, security, legal requirements, existing assets, existing capabilities and a host of other contextual factors affect the Solution. And there’s only one way to discover what the context is – Elicitation and Collaboration.

Need

One could take the view that “Need” would refer to “why do we need this change.” That would be an incomplete view of what Need means to Elicitation and Collaboration. A better understanding would include every aspect needed for the change to be successful. That would include everything from process redesign, to resources, to systems design and implementations and more, in the detail that defines the Need, or requirement, completely. So, the Core Concept of “Need” forms the backbone of the requirements that we are attempting to identify and define. This is tied closely to “Change” in that one could say that the collection of all the identified Needs are required to enable the Change to become a reality. To make the point a little more directly as it relates to the Knowledge Area, Elicitation and Collaboration is not complete until all of the Needs have been fully defined.

Solution

The focus of this Knowledge Area is to collect the information, to translate into ideas, refining those ideas into requirements, finally communicating and confirming those requirements into the Solution. We started with the desire for a “Change” – which could be viewed as a response to a business need (or high-level requirement). The Solution is the end goal – it answers, “What are we going to do about it?” Any solution which was not derived from a full understanding of all of the other Core Concepts will be incomplete. So, Solution is the output of Elicitation and Collaboration.

If the goal was to help the disabled live in their homes in a self-sufficient manner, including enabling them to maintain their yards, one part of the solution could be a self-driving, solar-powered, mulching, edging and trimming mower.

Yes, I had to find a way to re-use that product. But this isn’t a complete solution to the stated need. All analogies have their breaking point.

Stakeholder

One of the primary sources for information on the Needs for this Change, the Stakeholders are the ones who must sign-off on the requirements, as well as on the final product. As such, it is necessary to gather their thoughts, concerns, and insights. It is also important to collect what will satisfy them, that the proposed solution is the one which will meet their expectations and needs.

Value

Through Elicitation and Collaboration, consultation with various stakeholders will help to define “Value” for the change. Defining Value doesn’t just stop at determining what is relevant to the stakeholders. It involves understanding how value relates to the change as a whole. And it also involves using the Value of the proposed solution as a benchmark measure of the success or shortfall of the implementation. In other words, Value determines whether the Solution is the right one, whether it meets expectations, and whether it was implemented in the right way. Without Elicitation and Collaboration, the analysis would have no actionable guide for this.

BABOK v3, ch4

BACCM: Impact on Knowledge Area 1. Business Analysis Planning and Monitoring

BACCM: Impact on Knowledge Area 1. Business Analysis Planning and Monitoring

In 2015, IIBA published it’s Business Analysis Body of Knowledge (BABOK) v3, which places a high emphasis on developing the BA Core Concept Model (BACCM). The BACCM is a significant part of testing for certification. So to better understand the BACCM and how it relates to the Knowledge Areas, I will attempt to explain how the BACCM ties everything together.

According to BABOK, v3, the following table represents the application of the Six Core Concepts to the Planning and Monitoring Knowledge Area.

BABOK v3

First, some basics. The Planning and Monitoring Knowledge Area is concerned with setting the guidelines of how the analysis will be done, as well as how the effectiveness of the analysis will be measured. Putting it another way, it’s deciding how we will analyze the analysis. I know, redundant. But how else will we know if we are working our plan, or if our efforts are practical and efficient? So for the Planning and Monitoring Knowledge Area (the focus of this article), it is in this context that the Six Core Concepts of BACCM are being applied. So let’s expand the relationship between these concepts and Planning and Monitoring.

Change

In applying the Core Concept of Change to the Planning and Monitoring Knowledge Area, the business analyst considers how changes will be made to the plan and monitoring documents. If Planning and Monitoring need revision, how will that revision occur? Just as a project should have a change request process, so should the analysis.

For example, in the middle of analysis, a new regulation has been enacted requiring additional information to be captured and analyzed if your company exceeds some threshold. The additional data will likely require changing the analysis approach because there will be a requirement to measure the company against that threshold. This new requirement forces an alteration to the plan.

How will such a change be requested and approved? How will the change in the plan be incorporated with existing plan documents? Of course, this will affect the project solution at some point, but for the Planning and Monitoring Knowledge Area, the project solution is not the focus. The effect will be documented in the “Business Analysis Approach” document (BABOK v3, 3.1 Plan Business Analysis Approach) as well as the “Governance Approach” document (BABOK v3, 3.3 Plan Business Analysis Governance Approach).

Need

In applying the Core Concept of Need to the Planning and Monitoring Knowledge Area, the business analyst is determining the best approach for conducting the analysis. The primary consideration is in the context of the change and includes:

  • How to best get the information needed for the analysis and how to represent the results? 
  • What are the tools and techniques needed? 
  • Why are these better than other options?

The Business Analysis Approach, Stakeholder Engagement Approach, and Governance Approach all impact Need. Need then affects the “Information Management Approach” document (BABOK v3, 3.4 Plan Business Analysis Information Management).

Solution

In applying the Core Concept of Solution to the Planning and Monitoring Knowledge Area, it is again important to remember we’re analyzing the analysis. This can take you in two directions:

  • How do we determine what kinds of analysis should be performed? This is the Planning part.
  • How can we determine the impact of the analysis on the resulting implemented solution? This is the Monitoring part.

In dealing with Monitoring, we can ask questions like the following:

  • How do we know if there were items missed?
  • How do we know if we’ve added too much?
  • If there are errors in the implemented solution, are those resulting from the analysis, the requirements, or the implementation? 
  • How do we identify if there are there missed changes, need unrepresented or uninformed stakeholders? 
  • Did it achieve the expected value?

As it relates to Planning and Monitoring, the Solution joins with the Need as influencing everything. Need focuses on the motivation – Why are we revising our Planning and Monitoring documents. On the other hand, Solution focuses on execution – How will these documents be changed.

Stakeholder

In applying the Core Concept of Stakeholder to the Planning and Monitoring Knowledge Area, we need to understand what the stakeholders need to see from the analysis. Doing this analysis during the Planning and Monitoring Knowledge Area could reveal that individual stakeholders need a high-level view, while others need greater detail. Some may need to see technical aspects, others need a financial assessment, and others need to see that everything is going according to plan. Understanding the full set of stakeholders needs dovetails well with the Need core concept. You cannot fully understand Need unless you understand Stakeholders. This will impact the “Stakeholder Engagement Approach” document (BABOK v3, 3.2 Plan Stakeholder Engagement).

Value

In applying the Core Concept of Value to the Planning and Monitoring Knowledge Area, we need to know what is valued by Stakeholders and how to demonstrate that the value is achieved. As such, Value is an integral part of the other concepts of Change, Need and Stakeholder. as well as the primary driver for how the Solution will be measured.

Here, the question is, how is Value determined. Planning and Monitoring will be concerned with the value equations for the final product, as well as how to confirm the potential value will be verified. But it will also be concerned with the impact of the Analysis effort on value.

Context

In applying the Core Concept of Context to the Planning and Monitoring Knowledge Area, we need to ask Why. Why is this change to the Business Analysis plan required? Why do the stakeholders value certain items? Why is this analysis required?

When we discussed the Core Concept of Change, we gave an example involving a new regulation. Understanding the new law would provide the context.

With the perspective of the BACCM, we have a framework for understanding the various aspects of Planning and Monitoring. And that framework can be leveraged to produce a complete set of plans for this Knowledge Area.

BABOK v3, ch3

Role of Agile Analysis

Planning

There are multiple ways you can look at planning, and each may apply to each Horizon. Here are a few that have been applied over the years. I’m sure there are others.

Types of Planning
Agile Extension to the BABOK®  Guide – pg. 3

First, there’s Iterative Planning. Any discussion about Agile has to mention Iterations as part of its structure. And in planning, it’s no different. On a recurring basis, the Agile Business Analyst reviews, refines, and prioritizes the work based on the latest insights.

Then there’s Adaptive Planning. The very word “Agile” implies change or flexibility. Priorities change. Needs change. So we have to Adapt. Agile will continuously be looking at what is going to deliver the highest value and striving to work on that next.

Then there’s the combination of Both. In this type, Iterative and Adaptive planning are combined. Priorities are repeatedly set, based on the latest available information.

Prioritization

So, How do we know what is the Priority? How do we know what to Adapt? The answer is, “Feedback.”

To get feedback, the Agile Business Analyst forms communication between a lot of different folks within or external to the organization.

Sources of Feedback
Agile Extension to the BABOK®  Guide – pg. 3

Identify the customer. Most often, of course, this is the primary individual or group who needs to be consulted. They may be internal – associated with some support process within the organization. Or External, classically represented in retail as the buyer of a product. It may be a group too broad to handle, especially for retail. This is often performed by a lead person or a group that serves as the voice of the customer.

The Analyst may observe or get information from sources, some of which might not be included in the organization chart, such as Competitors. These may be hostile witnesses, as they don’t want to give up a competitive advantage. But there are ways to know what a competitor is doing. In retail, all you have to do is walk into their store. Or maybe read their Advertisements. 

Partners are groups that, for one reason or another, are on your side. Because they deal with things that your organization may not directly see, they can be a great source of information that can inform some of your initiatives.

Investors are often self-appointed experts. They can be for you, or they can turn against you. Managing their expectations in specific environments can be the difference between the success and failure of the initiatives.

Subject Matter Experts are your internal sources. These should know the issues better than anyone. It is essential to see them embracing the changes, as often they are the customer. Other times, they are responsible for some of the technical requirements necessary for success.

Regulators, or the legal environment, is often the motivation for change. They may force an artificial priority. For example, if the IRS comes up with some new regulations concerning one of your company’s business practices, it becomes crucial to meet those demands. Your Board does not want the embarrassment of an IRS adverse finding.

Agile Analyst Activities

So, looking at a High level, how can you group the functions that an Agile Business Analyst performs?

Activities Enabled by Agile Business Analysis
Agile Extension to the BABOK®  Guide – pg. 4
  • Linking of Strategy to Initiatives to Resources
  • Elicitation – discovering, communicating (two-way), and interpreting the findings.
  • Clarifying – ensuring that the understanding of the Analyst is correct. Communicating who this is for, who this is by, and determining impact.
  • Helps Decide – priority of initiatives, features, and development work Items. Also, help decide approaches and providing information on trade-offs from one path to another.

This page may contain affiliate links. I may receive commissions for purchases made through links on this page.

What is Agile Analysis?

Agile Business Analysis begins with a basic concept of the simple feedback loop shown here. No matter what flavor of Agile you are using, everything you do in Agile can be boiled down to an application of this feedback loop.

Inspecting and Adapting

Feedback Loop
Agile Extension to the BABOK®  Guide – pg. 3

In Agile, you are either inspecting or adapting. Either you are gathering information based on data, interviews, research, or other sources, or you are taking the information and determining what to do about it. This simple feedback loop is applied to all levels of planning in the organization.

Planning Horizons

When we talk about levels of planning – that is what the Agile Extension® calls a Horizon. IIBA breaks it down into 3 Horizons

Three Planning Horizons
Agile Extension to the BABOK®  Guide – pg. 3
  • Strategy – Looking long-range to determine opportunities and risks and come up with potential needs or opportunities.
  • Initiative – Reviewing the opportunities and needs identified by Strategy, and determining a broad approach to meet that challenge
  • Delivery – Actually performing the work defined in the Initiative horizon.

Commonalities

Each Agile framework has certain things in common.

Commonalities of All Agile Frameworks

There is a heavy emphasis on incremental delivery.  In this case, I don’t just mean the final product from the Delivery Horizon, but incremental delivery of whatever outputs are appropriate for each of the horizons.  Whether that is potential initiatives at the Strategy Horizon, Product Plans for the Initiative Horizon, or Working Software at the Delivery Horizon, all of them are delivering something.  And they do this in recurring periods – at a cadence.

All Agile approaches prioritize effort based on value. They may disagree on who and how value is determined, but whatever the value proposition is, that is the basis for prioritized work. For example, a manufacturer might view value as Quality Control. Another might see it as Time to Delivery. A third might view it as Revenue. And there can be a debate on which of those is right. But whatever comes out must be meeting an agreed-upon priority.

All employ an iterative approach. So what is produced in each iteration?  The answer is just a little more than you had the previous iteration.  All flavors of Agile deal with Small Slices of the solution.  And they all have the idea that at the end of each iteration, that work is ready to go.

All agile frameworks promote rapid delivery. In Agile, there’s no more of this waiting until the entire thing is finished and testing it then, finding errors at the end, and having to rebuild large sections. You build a small chunk, check it, and roll it out. And it works when it is built.

It has been tested and approved, which allows rapid feedback.  If it isn’t accepted, you find out almost immediately, before building more on top of something that doesn’t work.

And again, adapting to change.  This goes back to iterative and adaptive planning.  All flavors of Agile have some form of this built into them.

Agile Analysis understands the value of feedback because of its effect on several important aspects of work.

  • Feedback guides the discussion of value. There are many ways that value can be determined. The first thing we need to know as an Agile Analyst is what determines value in the context of your work, company, and customers.
  • Feedback guides Prioritization.  I include this as a separate item because the value equation may change over time. The only way the Analyst will know is from feedback about the change.
  • Feedback informs about Opportunities. But even then, having the information is one thing. Knowing what to do with it is something else.
  • Change is revealed through feedback. It’s important to understand that the change might be because of data. Often when we think of feedback, we are meaning Human Interactions. But often, it’s not people that tell us of the need for change; it is data or other information.
  • Feedback minimizes Uncertainty and Waste.  If we build a means to monitor and tie results to possible responses into all of our business processes, including our development cycles, our time to perform corrections will be lessened.

This page may contain affiliate links. I may receive commissions for purchases made through links on this page.

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

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 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.