How to be agile without sacrificing quality

Kevin Fish and Steve Isbell reveal how BGL Tech embeds quality practices into its change delivery cycle:

Photo by Hermes Rivera on Unsplash

Agile is just about going fast. MVP is an excuse to put bad code live. We’ll get faster by skipping testing.

If you’re working in an agile environment these statements will make your skin crawl. Unfortunately, these are things we’ve heard and/or seen before.

Slow down to speed up

Let’s tackle these myths individually:

1. Agile is all about going fast

Well yes and no. Agile to us is about efficient, iterative, quick to market delivery. Done right would you perceive this as fast? We guess so. However that speed is not created by skipping quality — quite the opposite, in fact.

2. MVP is an excuse to deliver bad code

We’ve spent a while trying to understand what would prompt someone to say this? Perhaps they’ve had a bad experience where MVP meant putting changes live quickly without following appropriate engineering practices?

Ultimately MVP fits into one of two categories:

A. Out of a larger set of requirements, you want to initially focus on what is going to deliver the most value.

B. Looking for a quick test and learn before committing to a bigger delivery.

Either way if MVP truly is being used as an excuse to put bad code live it may achieve that fast-paced delivery that agile talks about...this time. The downside, of course, is the technical debt that comes with that bad code which will definitely slow you down in the medium to long-term.

3. We’ll be faster by skipping testing

So we spend time in refining a story, time developing and time testing. If we get rid of the latter then we’ll be quicker. Well, maybe. But probably not.

Sure, you’ll have removed an amount of time on a specific task (or set of). What you’ll probably have done, however, is created a whole new set of tasks.

The product isn’t doing what the product owner wants, we need to re-work it. The service hasn’t delivered to the customer what they expected, we need to deal with a complaint (and fix it). Bugs, re-work, waste, operational overhead all from “saving time” not testing and ensuring a quality delivery.

So how do we ‘do’ quality

Steve talks about this here but let’s discuss some key points.

Firstly, our principles:

• Quality is everyone’s responsibility. Every single person in our delivery teams is focused on the quality of the delivery, not just delivering a change to the requirements on time.
• Anyone can call out if the quality isn’t right and their voice will be heard.
• Teams own their change through to live and are accountable for fixing issues that arise from their change.

Next, our working practices:

• Collaboration: This comes in various forms but, put simply, everyone in a delivery team works together to understand the business need. They then define, create and test the solution together, checking in with the change owner throughout the process to ensure the delivery meets the business need.
• Agility: We have an agile maturity framework which defines what agile means to us. We then use it to continuously improve while keeping consistency across our many delivery teams.
• Engineering: Technical excellence is fundamental to our software delivery, so we have common approaches for all elements of design and build in order to be sure the solution is appropriate and isn’t introducing unnecessary complexity or technical debt into our systems.
• Assurance: We have design and quality assurance practices for all change, so expertise across our teams can be utilised and quality is ‘baked’ in early.

And in practice

It’s all about shifting quality left and minimising surprises. In teams we do that in a few ways:

1. We run inception meetings where all interested parties meet to understand what we’re trying to achieve, what business and technical outcomes we should be monitoring post release.
2. We ensure all changes are refined during three amigos by following the INVEST framework, ultimately leading to a clear understanding of what is needed.
3. We ensure the the team agrees what test scenarios need to be satisfied using the acceptance criteria as early in the process as possible.
4. We use test automation where possible. While test automation on web journeys has been around for ages, we’re also facing into the challenge of introducing this into our legacy backend systems.
5. Creating a culture where quality is the responsibility of all. Who is the tester in our teams? Everybody is. We have quality engineers who are responsible for designing our test approach but ensuring a quality product is everyone’s responsibility.

Senior Quality Engineer Chris talks about his this in his blog here.

What’s next?

We’ve established a good foundation of quality in the teams at BGL Tech. Going forward, one of our focuses is to look at how we increase our flow and reduce our sprint cadences while maintaining the same standard of quality.