Extreme Programming (XP) is a lightweight engineering approach that grew in the 1990s. It was popularised by Kent Beck as a way to make teams more responsive to change through short iterations, continuous feedback, and disciplined engineering habits. It is a pragmatic, human-centred software practice that prioritises simple design, frequent feedback, and close collaboration, so teams can deliver working software more quickly. It could be argued that all modern software development practices have some roots in XP. XP emphasises a small set of practices that work together to reduce risk. Key practices include pair programming, test-driven development, and continuous integration. Simple design to avoid unnecessary complexity, and frequent small releases to keep feedback fast. These practices are deliberately social as much as technical because the aim is to make quality a shared, everyday activity rather than something done at the end. XP helped shape the thinking behind the Agile Manifesto by showing that lightweight, people-focused practices could replace heavyweight processes and documentation. Several XP proponents were part of the group that drafted the manifesto in 2001. The influence is visible in how modern agile teams treat iteration, collaboration and quality as inseparable parts of delivery rather than optional extras. In modern software development, XP’s fingerprints are everywhere.

Develop the mindset and practical coaching techniques that help teams build shared responsibility for continuous quality

The number of the beast is said to be 666. So I must be a beast at collecting stars as that’s my count before I post this memory.

Explore why questioning systems and trusting your judgement still matter in quality engineering and testing.

I’ve passed 1,000 activities in the MoTaverse community and thought it was worth celebrating.

The Twelve Days of testing On the first day of Christmas, testing gave to me. A bug that delayed release. On the second day of Christmas, testing gave to me. Two testing tools and a bug tha...

A quality narrative is simply a story that explains what your testing and quality work actually mean for the product, the team, the company, and the people who rely on it. It’s not a long report or a wall of numbers and metrics. It’s a way to take what you see every day and turn it into something relatable. It could be risks, patterns, wins, surprises, or any other value-added work you do. You don’t need to drown anyone in data. A couple of meaningful metrics, paired with a clear example from a recent change or release, is usually enough. The aim is to connect the dots. Here’s what we found, here’s why it matters, and here’s what we might sensibly do next. When you speak in the same language as your product teams and leadership, the conversation shifts from reporting to collaborating. Start small. Pick one or two areas that matter most to your organisation right now. Gather a few insights. Share a concise and simple update. Then iterate. A quality narrative should grow with your context, not become a burden. Most importantly, it’s not a shield or a promise. It’s a practical tool to make your testing and value visible. It builds trust, helps teams make better decisions, move with greater confidence, and understand how quality fits into their work every day.

MoT Leeds hosted a panel discussion on Leading with Quality, which sparked a lively debate on several topics. The unexpected one was which AI had written the questions! It didn't, it was all me. He...

First I missed capturing 404 stars. Now I missed 500. So I’m celebrating 513 instead. Great problem to have.

Emily is delivering a talk called how raising quality bug cards prepares you for becoming a quality leader

DevOps is a way of working that brings together development (Dev) and operations (Ops) teams so they can build, deliver, and improve software through close collaboration and shared goals. It breaks down the barriers between development and operations so that everyone involved takes responsibility for quality and delivery.At its heart, DevOps is about creating faster and more meaningful feedback loops. When teams work together from ideation to release, they can spot issues sooner, learn from real users, and respond more quickly to change.For example, instead of developers waiting weeks to hear if a new feature performs well in production, they can work alongside operations to understand what happens much quicker.This shared approach builds trust, speeds up learning, and reduces waste. DevOps helps teams focus on outcomes rather than handovers, creating an environment where improvement is constant and communication keeps quality at the centre of everything.