The House of Agile Quality is a framework concept that structures the central components for software quality in agile projects. It consists of a test foundation, three pillars (roles, approach, tools) and an umbrella of lean quality engineering methods. Teams use it as a checklist, maturity model and roadmap for quality improvements.
Key Takeaways
- The House of Agile Quality is divided into foundations, three pillars (roles, approach, tools) and an umbrella of lean quality engineering methods for a structured approach to quality in an agile context.
- Anyone starting an agile quality transformation should first clarify the approach pillar, because the choice of framework (Scrum, SAFe or others) directly determines which roles and tools are useful.
- Test data management is often underestimated: depending on the test level, synthetic data, anonymized production data or a nightly reset gold client are needed as separate strategies.
- The A3 method from lean management makes it possible to describe improvement ideas on a single sheet of paper with observations, effort, benefits and responsible parties and to implement them within a time frame of around eight weeks.
- The book is based on six to seven years of project experience and iterative feedback from training courses and workshops, not a purely theoretical concept.
What does the House of Agile Quality mean?
The House of Agile Quality is a model that describes how quality can be implemented in agile projects. The house metaphor serves as a simple image that holds the individual building blocks together and makes them understandable for everyone.
The model consists of five parts: a foundation, three pillars and a roof. Thomas Karl developed it together with Nico Lidl and described it in a book. Six to seven years of work lie between the initial idea and the publication, enriched with project experience and feedback from training sessions and workshops.
The foundation is called Testfundament. It contains classic methods and maturity models on which everything else is based. Between the foundation and pillars is a maturity model from 1 to 5, which serves as a roadmap.
The three pillars support agile quality
There are three pillars on the foundation: roles, approach and tools. Each covers a different area of quality work.
The roles pillar deals with employee empowerment. What new roles arise in an agile approach? And how do you adapt organizational structures so that they really fit the agile approach and are not just superimposed on it?
The approach pillar begins with the choice of framework. Scrum, SAFe, LeSS: a lot depends on this decision, because each framework has its own roles and basic setup. This raises the question of which test tasks are best suited to which roles. In large projects with dozens of teams, there is a second question: What can be tested within a sprint in one team, and what needs to be tested cross sprint or cross team to ensure quality end-to-end? Change management and a standardized language also belong here. Many new terms arise during a transformation and you have to define what a developer test means in concrete terms, for example, so that no misunderstandings arise.
The tools pillar covers the technical and procedural aspects. It ranges from the selection of test automation tools, test environments and test data to orchestration in the sense of a DevSecOps approach.
The umbrella stands for process quality, not just product quality
The umbrella of the model is called Lean Quality Engineering Methods. It separates two views of quality that are often mixed up in practice.
One view is product quality. This is traditionally the focus, and testers are good at it. The other view is process quality, which is particularly important in an agile transformation.
The model adopts methods from lean management for this purpose. The aim is to bring processes back to stability and a good level of maturity after a transformation and to incorporate continuous improvement.
How does the A3 method for process improvement work?
The A3 method is a continuous improvement tool from lean management. It uses a DIN A3 sheet with fixed boxes that structure an improvement idea.
The boxes state what the observation is, why the current situation is not optimal, what the improvement idea looks like, how complex it is, what it brings, which roles are involved and how long it will take to implement.
The completed sheet serves as input for an improvement committee, which decides on costs, benefits and effort. If the committee agrees, the person who identified the idea ideally takes on the implementation, provided it fits into a time frame of around eight weeks.
How do you handle test data in agile projects?
Start with a screening: At what level do you carry out your tests and what types of test data do you need for this? Do you need historical data? Does interface data need to be connected?
In practice, the focus is often first on test automation. It is only in the second step that it becomes apparent that the environments are not performant enough or that the appropriate test data is missing.
For technical tests of a single functionality, it is best to create synthetic test data, if necessary directly during automated test execution. For end-to-end testing later in the test cycle, there are other ways.
An overview of these methods:
| Approach | When to use |
|---|---|
| Synthetic test data | Technical testing of individual functions, often directly at runtime |
| Gold client with reset | Nightly reset to a defined dataset |
| Anonymized live data | If realistic data is required |
| Semi-synthetic system | Enrichment with anonymized data |
Which approach is suitable depends on the specific use case. The principle behind this is help for self-help instead of a one-size-fits-all solution.
Start by building in the middle of the house
Those who use the model typically start with the pillar approach. First, you clarify which methodology you are using and which roles already exist, because a Scrum approach is connected differently in terms of processes and roles than a SAFe approach.
The second step is to look at the complexity of the software. A small app has different requirements than a large SAP system that is connected to many other systems in the company.
From the pillar approach, you then make a left-right comparison: the roles on the left to empower people, the tools on the right to give them the necessary tools. Test-driven development is of little use if the right people with the necessary knowledge and tools are missing.
In the third step, there is feedback into the approach. The processes provided by a standard framework are described in addition. This allows new employees to be trained and the processes to be continuously scrutinized. This is easier if you have at least outlined them at a high level.
Tools are more than test automation
Tools are often equated with automation, but the model distinguishes between several categories. The first is test automation, which is closely linked to test data management.
Since its publication, the topic of AI tools has become increasingly important. The question is how such tools can be integrated and used in the quality process. There is also the topic of robotics in terms of DevOps orchestration.
Sven Löfke has contributed his expertise to the in-depth chapter on performance engineering. It deals with the various load and performance testing tools and the difference between stress testing and pure load testing.
The goal is an automated end-to-end pipeline that is rightly labeled DevOps pipeline and does not have twenty manual steps in between. To achieve this, it is worth deliberately keeping the range of tools wide and checking at which point which tool fits best.
Lean Six Sigma provides further methods for the roof
In addition to the A3 method, there are other lean methods under the umbrella of the model. One comes from the Lean Six Sigma world: Voice of Customer.
Voice of Customer fits in with the customer-centricity of the agile approach. It is used to define critical-to-quality key figures for a process. Particularly in the case of several teams or cross-company work, the approach first clarifies who the customer actually is, i.e. the next process step.
The critical factors that can be measured and used to optimize the overall process are derived from this. There is also a DMAIC approach to process improvement, which functions as a larger version of the PDCA cycle.
Stories make the textbook more than just theory
Each area of the company is preceded by a short story, told with humor and irony. They pick up on typical situations that can arise when dealing with improvement or transformation issues.
These stories lighten up the material and create recognition. Anyone who recognizes a situation from their own practice can more easily transfer the content to their own context.
The book first explains the concept with its five components and then provides a deep dive into performance engineering. It deliberately does not describe each component down to the last detail, but provides jumping-off points, such as literature references or a reference to the A3 method for a deeper introduction.
Our focus was to describe really hands-on things and not something theoretically abstract, which in practice means you have to spend three weeks thinking about how to transfer it to your own project context.
Thomas Karl
What’s next for the model?
The biggest follow-up topic is AI. A white paper is planned that describes how AI tools can be used in the context of Agile software development to support short sprints.
The topic of test data will also be covered in more depth, as it has become increasingly urgent. A blog on the book has been launched, and the next article will be dedicated to roles.
The focus there is on the transformation character: the path from a status quo, whether a classic waterfall world or an ad-hoc agile approach, to a mature state. To this end, training and employee development paths will be outlined.
