Why Do We Use Embedded Quality Advocates in Agile Application Development?

Software testing used to be the final stage of waterfall development, often carried out by an isolated "testing group." It was time-compressed, often frustrating and did not provide much value to the development team or to the customer. The testers felt isolated, the programmers felt attacked, no-one was having fun.

We work differently now.

Our application development process has quality built-in through all steps of the process, not just in a "testing phase" after the code is written.

Quality Advocacy is a different kind of discipline that's adapted to agile software development. A quality advocate starts on the project when the other roles do: developer, product owner, user experience. We build trusting relationships with the rest of the team, and our successes and failures are as a unit, not as individuals. When you have high trust between team members, a found defect isn't cause for recrimination or blame, but for learning and improvement. The quality advocate is not the only person on the team thinking about quality because it's a whole-team concern, and the quality advocate is the expert and mentor.

We are committed to: delivering value early and often, short feedback loops, no knowledge-silos and experiment-driven decisions.

Delivering value

"Value" is defined by the client, and by the team. We want to deliver value early and often. This could be as simple as getting a blank "hello world" web app stood up, or as complex as changing out a payments processing back-end on a pizza app on Android. Whatever it is, delivering value means we have finished something that provides a benefit to the client, and each delivery shows quality and polish.

Short feedback loops

If you're going off-track, it's better to find out after a day than after a month. It cuts the amount of re-work and waste in the process. An embedded quality advocate can ask questions of the whole team, in real time. We simply call for a "team turn around," a short all-hands team meeting where everyone pauses to answer a question, clarify a requirement or steer around a potential hole in the road.

No knowledge silos

Quality advocates often work in pairs. We work with developers on both coding and testing tasks. We work with user experience consultants, delivery engineers, product owners and business analysts. This breaks down the "only Susan knows how to do X" problems by sharing responsibility. In the same way that you have shared code ownership, we also want shared ownership of the domain-knowledge the team has learned.

Experiment-driven decisions

It's the basis of the scientific method: define the situation, take some measurements, conduct an experiment, take those measurements again. We are happy to experiment with our process, our tools, and about anything you can reliably measure. This keeps us from getting stuck in a groove and ensures we have fresh ideas and perspectives. Those experimental results are shared between teams to help us all learn.

Embedded quality advocacy helps a team deliver better software to our clients, and helps each role learn from each other to continually improve.