Leveraging Agile to Improve Quality

In a fixed-time, fixed-cost, fixed-scope environment, time and cost estimates are often wrong and the pressure to deliver and get things into market faster intensifies. When this happens, the delivery teams need an outlet and quality is usually the first thing to go because, in a world of fixed constraints, it’s the one thing that the delivery teams can control.

Quality is the lever that gets pulled when your organization is operating in an unsustainable way.

Many a company has hypothesized that Agile methodologies would help them solve their quality issues. They thought that if they could just improve team-level communication or get better alignment across multiple delivery teams that they would begin to see improvements.

Many a company have also quickly realized that Scrum and SAFe turned out to be insufficient. No amount of daily standup meetings or big room planning was going to solve their quality issues, so they assumed that either they did something wrong—or that Agile doesn’t work at all.

Paving the Way for Quality with Agile

The problem is that, at scale, in multi-team, dependency-riddled organizations the performance of the individual teams is almost irrelevant—which is why when Agile methodologies are relegated to a team-level activity, it almost never works.

It’s not until we leverage larger, vertical slices of the organization and begin integrating the work the teams are doing with an upward intentionality that we begin to see real improvement in quality.

But this takes a certain set of conditions. It takes the 3 Things:

• Teams
• Backlogs
• Working Tested Product

Basically you need to create an environment where you have a well-articulated backlog that flows into a team that consists of six to eight people that have everything they need to deliver a working tested increment of product—an increment of product that actually works and is valuable to the business.

The Impact of Agile on the System of Delivery

So, what we’re looking for are cross-functional teams, clear backlog, good acceptance criteria, work broken down as small as possible, so that we can integrate the Dev Teams and QA Teams as we go and create feedback loops throughout the life of the Sprint.

When you have the developers, QA people, and the PO all collaborating on the acceptance criteria and getting to a clear definition of done, you can begin to imagine a world where the teams are cycling through building test cases, coding, validating, and fixing defects more quickly and getting to done faster.

Then we can walk into the Sprint Review with a high degree of confidence that the product is going to work, that it’s suitable to its intended purpose, that it meets the acceptance criteria, and that the PO will sign off on it.

Without the 3 Things, you can’t have super-clear acceptance criteria.

This means you can’t get to a solid definition of done.

The inability to get to a definition of done means that the teams won’t know what they’re going to go and test against so that they can get to a demo and understand when they’re done-done at the end of every Sprint.

Scaling Agile to Improve Quality

One of the biggest things that impact an organization’s ability to move fast—to be Agile—is having the ability to make changes without the risk of breaking anything in the system of delivery. The only way you can create the safety for the organization and the teams to move fast is by connecting execution to strategy through super-intentional upfront planning and tight decomposition between the various layers of governance.

Most large organizations are dealing with multi-layered governance models that look something like a delivery tier on the bottom, a portfolio tier at the top, and a program/product tier in the middle.

Each tier is focused on its own type of quality assurance. The delivery tier focuses on things like craftsmanship, unit testing, TDD, etc. The program/product tier is focused heavily on does the product meet the acceptance criteria, does it have bugs, or defects—things like that. And the portfolio tier is focused on things like will this product be embraced by the market? Will people use it? Will people pay for it?

So, in a multi-tier, multi-team Agile environment, the idea is that Epics will move through the portfolio queue in three to six-month batches. These are the things the business actually cares about—investment initiatives that have dollars attached to them and are expected to get a return.

Epics get decomposed into Features for the program/product tier and those Features have acceptance criteria of their own. The Features get decomposed into User Stories for the delivery tier, and those have their own definition of done.

Having this level of intentionality around creating smaller batches of tightly aligned value streams not only enables your organization to move fast, but it also improves the quality of the system and the product, too. The downward decomposition and upward integration of work, with tighter feedback loops between the layers of governance, creates an inherent quality within the system of delivery itself.

But it all starts with the 3 Things. After all, the key to unlocking enterprise Agility is really solid, well-executed team-level Agility. Pair that with enhanced execution at the higher levels of the organization and the sky is the limit.