The House of Agile Quality is a framework that organizes the key building blocks of software quality in agile projects. It consists of a test foundation, three pillars (roles, approach, tools) and a roof of lean quality engineering methods. Teams use it as a checklist, a maturity model and a roadmap for improving quality.
Key Takeaways
- The House of Agile Quality is built from a foundation, three pillars (roles, approach, tools) and a roof of lean quality engineering methods, giving teams a structured way to tackle quality in an agile setting.
- Anyone starting an agile quality transformation should settle the approach pillar first, because the choice of framework (Scrum, SAFe or another) determines which roles and tools make sense.
- Test data management is often underestimated: depending on the test level, you need synthetic data, anonymized production data or a gold client reset every night, each as a separate strategy.
- The A3 method from lean management captures an improvement idea on a single sheet, with observation, effort, benefit and owners, so it can be implemented within roughly eight weeks.
- The book draws on six to seven years of project experience and iterative feedback from trainings and workshops; it is not a purely theoretical concept.
What Is the House of Agile Quality?
At its core, the House of Agile Quality answers one question: how do you put quality into practice in agile projects? The house is a deliberately simple picture: it holds the individual building blocks together and makes them easy for anyone to grasp.
The model has five parts: a foundation, three pillars and a roof. Thomas Karl developed it with Nico Lidl and wrote it up in a book. Six to seven years passed between the first idea and publication, time the authors used to enrich the model with project experience and feedback from trainings and workshops.
The foundation is the test foundation. It holds the classic methods and maturity models everything else builds on. Between the foundation and the pillars sits a maturity model with levels 1 to 5 that serves as a roadmap.
Three Pillars Carry Agile Quality
Three pillars stand on the foundation: roles, approach and tools. Each one covers a different part of quality work.
The roles pillar is about enabling people. Which new roles come with an agile way of working? And how do you adapt organizational structures so they genuinely fit that way of working instead of being pulled over it like a cover?
The approach pillar starts with choosing a framework. Scrum, SAFe, LeSS: a lot hinges on that decision, because every framework brings its own roles and its own basic setup. That leads to the question of which testing tasks fit which roles best. Large projects with dozens of teams add a second question: what can one team test within a sprint, and what has to be tested across sprints or across teams to secure quality end to end? Change management and a shared vocabulary belong here as well. A transformation produces lots of new terms, and you have to pin down what, say, a developer test actually means, or misunderstandings follow.
The tools pillar covers the technical and process side. It runs from choosing a test automation tool through test environments and test data to orchestration in the sense of a DevSecOps approach.
The Roof Stands for Process Quality, Not Just Product Quality
The model’s roof is called lean quality engineering methods. It separates two views of quality that often get mixed up in practice.
The first is product quality. That is the traditional focus, and testers are good at it. The second is process quality, which matters most during an agile transformation.
For this, the model borrows methods from lean management. The goal is to get processes stable again after a transformation, bring them to a good level of maturity and build in continuous improvement.
How the A3 Method Drives Process Improvement
The A3 method is a continuous improvement tool from lean management. It uses a single A3 sheet with fixed boxes that give an improvement idea its structure.
The boxes capture the observation, why the current situation falls short, what the improvement idea is, how much effort it takes, what it delivers, which roles are involved and how long implementation will take.
The completed sheet goes to an improvement committee, which weighs cost, benefit and effort. If the committee approves, the person who spotted the problem ideally takes on the implementation, as long as it fits into a window of about eight weeks.
How to Handle Test Data in Agile Projects
Start with a screening. At what level do you run your tests, and what kinds of test data do they need? Do you need historical data? Does interface data have to be connected?
In practice, teams usually focus on test automation first. Only in a second step do they notice that the environments aren’t fast enough or that the right test data is missing.
For technical tests of a single function, synthetic test data is usually the best choice, sometimes generated right during automated test execution. End-to-end tests later in the test cycle call for other options.
Here is an overview:
| Approach | When it makes sense |
|---|---|
| Synthetic test data | Technical tests of individual functions, often generated at runtime |
| Gold client with reset | Resetting to a defined dataset every night |
| Anonymized live data | When you need realistic data |
| Partly synthetic setup | Enriched with anonymized data |
Which option fits depends on the specific use case. The idea is to help teams help themselves rather than hand them a one-size-fits-all answer.
Start in the Middle of the House
Teams applying the model usually start with the approach pillar. First you clarify which methodology you follow and which roles already exist, because Scrum ties processes and roles together differently than SAFe does.
In a second step, you look at how complex the software is. A small app has different needs than a large SAP system connected to half the company.
From the approach pillar, you then work your way left and right: roles on the left, to enable people, tools on the right, to give them what they need to work with. Test-driven development doesn’t help much if you lack people with the right knowledge and the right tools.
The third step feeds back into the approach. The processes a standard framework brings along get documented on top. That makes onboarding new colleagues easier and keeps the processes open to questioning, which works far better once they are sketched out, at least at a high level.
Tools Are More Than Test Automation
Tools are often equated with automation, but the model distinguishes several categories. Test automation is the starting point, closely tied to test data management.
Since the book came out, AI tools have become far more important. The open question is how to integrate them into the quality process and put them to use. Robotics also comes into play, in the sense of DevOps orchestration.
Sven Löfke contributed his expertise to the in-depth chapter on performance engineering. It covers the various load and performance testing tools and the difference between a stress test and a plain load test.
The goal is an automated end-to-end pipeline that deserves the name DevOps pipeline, without twenty manual steps wedged in between. That is why it pays to keep the range of tools deliberately broad and check where each tool fits best.
Lean Six Sigma Adds More Methods to the Roof
Besides the A3 method, the roof holds other lean methods. One comes from Lean Six Sigma: Voice of the Customer.
Voice of the Customer fits the customer focus of agile work. It is used to define critical-to-quality metrics for a process. Especially with several teams or work across company boundaries, it first clarifies who the customer actually is, namely the next step in the process.
From there, you derive the critical factors that can be measured and used to optimize the process as a whole. A DMAIC approach to process improvement completes the picture, working as a larger version of the PDCA cycle.
Stories Turn the Book into More Than Theory
Each area of the house opens with a short story, told with humor and irony. The stories pick up typical situations people run into during improvement or transformation work.
They lighten the material and make it recognizable. If you spot a situation from your own work, carrying the content over to your own context gets much easier.
The book first explains the concept with its five components and then goes deep on performance engineering. It deliberately does not cover every component down to the last detail. Instead, it offers jumping-off points, such as literature references or the pointer to the A3 method, for readers who want to go further.
“Our focus was on describing things that are genuinely hands-on, not something theoretically abstract where you first have to spend three weeks figuring out how to bring it into your own project context.”
(Thomas Karl)
What’s Next for the Model
The biggest follow-up topic is AI. A white paper is planned on how AI tools can support short sprints in agile software development.
Test data will also get deeper coverage, because the topic has become more pressing. A blog on the book has launched, and the next article is about roles.
That article focuses on the transformation itself: the path from the status quo, whether a classic waterfall world or ad hoc agile, to a mature state. It is meant to lay out training and development paths for the people involved.
Frequently Asked Questions
What is the purpose of a maturity model when building quality into agile projects?
It makes it possible to plan the path from the current state to a mature state of quality. In the House of Agile Quality, a maturity model with levels 1 through 5 sits between the test foundation based on traditional methods and the three pillars. It serves as a roadmap: A team can see where it stands and align its next improvement steps accordingly, rather than randomly initiating individual measures.
Why does test organization depend on the choice of agile framework?
Each framework comes with its own roles and basic setup, and the distribution of testing tasks depends on these. A Scrum approach is structured differently in terms of processes and roles than SAFe or LeSS. That’s why the methodology is clarified first, and then the question is asked: which testing task fits which role? In large programs with dozens of teams, another consideration is what is testable within a sprint and what must be tested across teams.
Why isn’t it enough to focus on product quality in agile projects?
Because during an agile transformation, process quality suffers the most. Product quality is the perspective that is traditionally the focus and one that testers master well. The second perspective concerns the processes themselves: After a transformation, they must become stable again and reach a high level of maturity. To achieve this, the model draws on methods from lean management and embeds continuous improvement.
How can an improvement idea be structured so that it is actually implemented?
Using the A3 method from Lean Management. A DIN A3 sheet with fixed boxes documents what was observed, why the situation is suboptimal, what the idea entails, its effort and benefits, which roles are involved, and how long implementation will take. The sheet is submitted to an improvement committee. If the committee approves it, ideally the person who proposed the idea implements it, provided that about eight weeks are sufficient.
When is synthetic test data appropriate, and when should anonymized production data be used?
Synthetic test data (which can also be generated directly during automated test execution) is suitable for technical tests of a single feature. For end-to-end testing later in the cycle, other approaches are worth considering: a gold client that is reset nightly to a defined dataset, anonymized live data when realism is important, or a partially synthetic environment enriched with anonymized data.
How do you define measurable metrics for the quality of a process?
Through the Voice of the Customer approach from Lean Six Sigma. This approach first clarifies who the customer is, that is, the next step in the process. This is not always obvious, especially when multiple teams are involved or when working across companies. From this, measurable Critical-to-Quality factors are derived. For the actual improvement, DMAIC, a more comprehensive version of the PDCA cycle, is used.
Besides test automation, what else belongs in a tool strategy for quality?
Significantly more than the term “automation” suggests. This includes test data management, test environments, and orchestration in the spirit of a DevSecOps approach, as well as load and performance testing tools. Since the book was published, the question has arisen as to how AI tools can be integrated into the quality process. The goal remains an automated end-to-end pipeline that does not involve twenty manual steps.
