# Why this matters
# What inspired the change
Conversations with three practitioners—Stuart Day, Stuart Thomas, and Nicola Sedgwick—introduced concepts that shifted the author's thinking about Continuous Quality and collaborative Quality Strategy. Rather than copying a single solution, the author adapted concepts into a working approach tailored to their team.
# How the team translated ideas into action
The team used a short, focused set of activities to turn discussion into output:
- A hands-on session used LEGO and a full whiteboard to challenge assumptions and generate concrete ideas about what quality means for their product and processes.
- They mapped "what good quality looks like" across the DevOps loop, rather than confining quality to a single stage or role.
These activities turned abstract language into artifacts the team could use while building their Quality Strategy.
# Which frameworks were used and why
Model provided a broader view of testing responsibilities and perspectives within a product or organisation. The Quality Radar offered a way to examine different dimensions of quality—making it easier to see gaps and overlaps when plotting quality across development stages.
Overlaying the two models produced a clearer map of areas to address and helped the team prioritise where to focus time and tooling.
# Resulting practice changes
The author reports the work is actively shaping the Quality Strategy the team is building. The practical outputs included:
- Shared language for what quality means at each stage of the DevOps loop.
- Visual artefacts (whiteboard maps and LEGO prototypes) to anchor discussions and decisions.
# How this reflects community value
# Practical steps you can replicate
- Run a short workshop with physical or visual prompts (e.g., LEGO and whiteboards) to force concrete outputs.
- Choose two complementary frameworks to overlay—one that maps perspectives and one that tests dimensions—and use them to highlight gaps across the DevOps loop.
- Turn the outputs into a living Quality Strategy document the team can iterate on.
# Closing note