“Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.” – W. Edwards Deming

You could say the search for Quality is a bit like the quest for the Holy Grail – a journey towards an unattainable goal whose purpose, in the end, turns out to be the journey itself. And as corollary, it’s got to follow that if anything improves the journey, it improves the outcome.

At Quast we’re interested in the so-called Three Amigos approach because it is about improving the software journey. It dovetails with much that is built into the Quast DNA: namely that prevention is better than cure and that QA’s role is to view every step of the journey as an opportunity to ensure that quality is built-in from the off, because doing so:

costs much less than finding and fixing later,

makes delivery timescales more predictable,

produces higher quality results.

As an added bonus, as far as we’re concerned, it encourages cross-disciplinary discussion, clarity and a breaking down of silo walls. In other words, the Three Amigos should make the Agile approach work in a more agile way.

The aim is firstly to maximise shared understanding and the quality of requirements so that they form the best possible basis for all future phases; secondly to align everyone as closely as possible so they are crystal clear about what they are working towards. Crucially therefore, the amigos are encouraged to meet before development starts because once you start development, the cost of changing direction, or fixing defects, begins to multiply.

For the most part three voices are all that you will need:

business

development

testing

but in a results-focused approach, devoted to getting things right first time to avoid costly corrections later, anyone with valuable insight can be an amigo too and Three Amigos can easily grow to four.

It is too much to demand that representatives of any one of these specific areas knows every question that needs to be asked, let alone its answer. So without the Three Amigos, important questions can go unanswered, not out of negligence, but because people did not know to ask them in the first place. Thus, in the middle of developing a user story, a programmer will inevitably want to raise questions surrounding functionality, and a tester might wonder if something is really and truly supposed to work that way. Unless the source of the answer is at hand, the chances are the question will not be raised until it is too late.

By sharing three or more different perspectives on a project, the Three Amigos can raise their own concerns and discuss answers in real time, so to speak.

The business analyst / representative, or user, will be focused on what the business hopes to achieve through the build and within which specific parameters. The developer will be concentrating on the information needed to achieve this, and how the technology will operate. The tester will play devil’s advocate by raising concerns and anticipating problems, testing and negative testing the requirement. The key is that all are working collaboratively and sparking off each other.

It would be misleading, of course, to see the Three Amigos process as magic bullet. Software development is about the detail and in this, as in every aspect of the software development lifecycle, execution and process are vital.

At the same time, advocates of the Three Amigos do not recommend a prescriptive approach. As rough guideline, the Three Amigos should be collaborating during Sprint planning, then talking at every stage of the story – pick-up, development, on completion and demonstration. And the approach is about attitude as much as anything, along with engagement and open-mindedness. So think laterally and literally. Amigos are as inclined to go for shared coffee breaks or have impromptu get togethers as arrange meetings. Even consider slight changes in office layout – by moving desks closer at an early stage you might avoid banging heads together later.