The 3 Amigos - A new old way to collaborate
‘Power of 3’ / The ‘Triad’ / the 3 Amoebas
Introduction
Also known as the ‘Power of 3’ / the ‘Triad’ / the 3 Amoebas.
The 3 Amigos (3A) is an incredibly powerful tool in a team’s approach to continuous testing and the delivery of a high quality product.
The other title could be:
‘A method of creating opportunities to mitigate the chance of non-compliant behaviour introduced via misunderstandings on what is built before they have a chance to manifest themselves in the codebase and cause friction for customers’…
but that doesn’t roll off the tongue like ‘3 Amigos’
A 3A session will generate buy-in from people who have traditionally been excluded from the process of knowing what they’re building, we trust the team to do the ‘how’.
In this post, I’ll explain what a 3A aims to achieve, why it’s beneficial, who should join, and how a typical session works.
My criteria is my own successful model from the past.
However, it’s just one approach.
I’m sure many other effective models exist out there.
Which brings me to the What.
Outcomes
It covers these main questions:
Do we understand the problem we are trying to solve?
Use the structured discussion format.
How do we know if the problem has been solved?
Usually in the form of testable ACs.
What are the risks involved in delivering the story?
Identification of these can focus the team.
Mitigation(s) can be identified.
Allocation of effort can be identified.
A quality deliverable is put front and centre.
'What-if?' questions should be the primary approach.
The What
The 3 Amigos in software development has been around in some form or other for a while.
The earliest reference I’ve been able to find is from George Dinwoodie’s blog.
It mentions a presentation called "A Lingua Franca between the Three (or more) Amigos," posted on Thursday, February 25, 2010.
Not much about the mechanics of the 3A in that presentation.
It’s a great reminder that there were individuals who were articulating the need for greater communication and collaboration in software development during the period when Agile and BDD were gaining mainstream acceptance.
This was before the legions of snake-oil Agile spawning to repackage what is (and should be) a relatively logical, lightweight approach to software development.
This brought me to a great stickyminds article from 29 November 2011 called The Three Amigos: All for One and One for All.
I’m sure that if there’s an earlier reference, I’ll be corrected at some point.
At the time of writing this, that’s over 13 years.
I’ve been a strong advocate of the 3A for the past 10 years.
The implementation and subsequent refinement of this into teams I’ve worked with has increased the ‘quality’ and value of the resultant deliverables.
Every.
Single.
Time.
The 3A is as simple as it gets.
3 stakeholders with a vested interest in delivering a piece of functionality gather to discuss a user story with the simple intent of creating a shared understanding of the user story / desired functionality / feature.
This shared understanding is illustrated in several ways:
Concrete examples of the behaviour or feature usage of the functionality
[Example Mapping in BDD-speak]
A more well-rounded user story.
Fewer assumptions and misunderstandings about what the feature is supposed to do.
Testable acceptance criteria.
Quicker refinement event.
The Why
The root cause of ‘most’ defects I have encountered (YMMV) has not stemmed from the implementation-side or code-side of features.
They may have manifested themselves in the implementation, but that’s not where the misbehaviour was seeded.
‘Most’ have occurred due to misunderstandings that have embedded themselves into ways of thinking.
Into those places where A ‘knew’ what B was thinking.
Into those places where everyone thought everyone else was on the same page via some as-yet-unproven telepathic ability.
Into those places where the obvious morphed into the not-so-obvious after the fact.
Long before a line of code had been written.
Long before a test case had been consigned to the land-fill of straight-jacket thinking.
Mistakes happen, always do, always will.
People are going to people.
With all the hype surrounding Artificial Impediment Intelligence, I would hazard a guess that the majority of software is still developed by humans with all the attendant human frailties.
The defects I’ve encountered have stemmed from a misunderstanding of what is being built, not how it’s done, this lack of understanding leads to mistakes in implementation.
Building the right thing vs Building the thing right
Dev teams are full of clever people.
One issue is that they often believe other clever people think just like them.
Alignment on what needs to be built tends to be a given, right up until the point that it isn’t.
The 3A can bring this alignment.
It allows the smart people to focus on building the thing right because they understand how to build the right thing.
It is not a panacea for your quality ills.
It is not a silver bullet.
It requires commitment, openness, and a willingness to challenge.
As John Ferguson Smart articulates with clarity here.
One to request, one to suggest and one to protest
It has been traditionally implemented (YMMV) as one of the tools used as part of applying the principles embedded in a mature Behaviour Driven Development (BDD) approach.
I’m not aware that it’s a core part of BDD practices, it just so happens to appear tailor-made for the Discovery-Formulation ‘structured conversation’ phases of a BDD approach.
I haven’t seen it implemented outside of usage of the principles of BDD but I have no doubt it could seamlessly fold into any of the other development models and approaches available.
Collaboration + Collaboration === Collaboration
It dovetails perfectly into teams that have adopted an Agile approach.
Those teams that Are Agile, not those who Do Agile
As with any other development tool, it can (and frequently is) implemented poorly, resulting in sub-optimal results for all concerned.
The Who
The Three Amigos represent key stakeholders in the system being developed:
- The Business (or Product Owner in Scrum)
- A Developer
- A Tester
These three reflect the expert views on what the system should do. They cover what can be implemented, what cannot, and potential issues or misunderstandings.
Or, in nerd-scrum speak, the Developers and the Business.
There are nominally 3 people — A representative of the business (Product Owner / BA), a representative of the coding function (Developer) and a representative of the test function (Tester/QE/whatever new titles a company decides to allocate to their testers for that morning)
You can (and should) involve other specialisations (DB / Network / DevOps / Designer / Person x) if you require it.
Just be aware that for each additional person, the lines of communication will increase exponentially, this in turn increases the chances of misunderstanding and miscommunication.
One of the very anti-patterns that the 3-Amigos is designed to mitigate.
The How
The 3 Amigos is lightweight by design.
The points below could be considered good practice and adoption of these will help to minimise / prevent defects from being introduced into the deliverable.
I’d encourage each team to find a method that works for them, as long as the primary questions detailed in the outcome can be articulated.
Use the WHeReAS mnemonic as advocated by the Rapid Software Testing (RST) course delivered by James Bach and Michael Bolton
Each specialisation is encouraged to contribute towards a meaningful discussion that results in a shared understanding of the desired functionality prior to refinement by the team as a whole
It is a chance to ask questions about:
the value statement / background / description contained within the story
the test data
the testing activities required to meet the team’s DoD
The use of an independent, critically-focused mindset to uncover and drive out assumptions.
The use of subjective terms 'quickly' / 'like' / 'similar'.
These are common flags that would deserve closer inspection and discussion to uncover the intent.
The story should be approached with a detail-oriented mindset (to a point).
Teams may face a real risk of paralysis-by-analysis, especially in the early stages of adoption.The QE will be primarily responsible for an initial sense-checking of syntax and titles.
How can statements be misconstrued?
Can claims be shown to be true?
Can claims be falsified?A natural by-product of this approach is that a quality-driven mindset embeds into the team as a whole as they get more familiar with the sessions.
Initial Acceptance Criteria (ACs) can be defined as part of the process.
It's important to understand that the primary purpose is to reveal surface assumptions and create a shared understanding of the required functionalityACs defined after the 3 Amigos run the risk of:
What was understood at the time of the discussion becomes a fading memory and people are wired to subconsciously fill in the gaps, resulting in inaccurate AC(s).
Context switching from a task can lead to inaccurate ACs.
Defining ACs at the last minute leading to rushed, poorly defined ACs.
Ownership issues can cause the anti-pattern where only the QE function controls 'quality'.
ACs can be defined following the behavioural approach (Given, When, Then scenarios using Gherkin syntax)
They can also be laid out in a simple 'expected input/output' format in a table or text.
or
A simple 'expected input/output' format expressed in a table or textUI elements benefit from a simple visual inspection.
There is no behaviour present within the display of static elements.
If the display of a particular element is expected as the resultant of an action this would be contained within a 'Then' statement.Behavioural activity (I want to do x to see y) benefits from the Gherkin approach.
It helps in creating a shared understanding of the expected functionality from a business and user perspective.Using examples of the expected behaviour helps to illustrate rules and constraints.
Thinking in terms of 'Demonstrate that...' can also be useful.
It’s important not to get hung up on a specific, prescriptive means of writing ACs, as teams can spend longer discussing minutiae than actual success conditions.
When discussing the story, asking the question ‘Can you give me an example’ helps to frame the expectations in a meaningful way.
Commonly referred to as Example Mapping.Team members build their understanding together by asking questions about the examples.
"what if..."
"what else..."
"so that means..."
This helps them come up with potential solutions.During the 3-Amigos:
The Developer will be thinking about technical constraints and possible solutions.
The QA will be thinking of edge cases and testability concerns.
The PO will be addressing business rules, constraints, and assumptions.
Nothing stops any of the three from positing questions aboutthe other areas outside of their specialities.
It is recommended that there is business involvement.
This will help to ensure that the generated ACs meet with the expectations of the business.
If the business cannot attend, it does not automatically mean that ACs cannot be generated.
It does mean that the business will need to inspect the ACs at some point before implementation to ensure that the teams’ understanding maps to theirs.Defining ACs upfront also increases the engagement of the developers as they can implement and test their implementation against the defined criteria, which will help ensure that the code delivers against the business expectations
Initial sessions may appear to be prolonged; this is a natural by-product of the team members getting used to the close collaboration and efficiency of communication a 3 Amigo session demands.
The pay-off is measured in:Reduced context switching during a sprint to address formal defects.
Reduced time spent on the defect lifecycle while addressing each phase of a formal defect cycle.
A typical defect cycle (for a single defect) usually results in around 2 hours of work.
A typical defect cycle (for a single defect that requires an automated check) usually results in around 2+ hours of work.
As team members get more well-versed in this approach, the time taken for each session should decrease to around 30-45 minutes.
If a session spans an hour, it can be useful to have a 5-min break in the middle to allow teams to reset.
The 3 Amigos should initially be held at the same time each day following a stand-up.
This builds a useful cadence.
It avoids context switching due to day-to-day development activities which can decrease engagement and reduces meeting fatigue.
Conclusion
Highly collaborative 3A will improve the quality of the delivered feature / feature-set.
Honest and critical 3A demand high levels of transparency.
Structured and open 3A will assist in mitigating risk.
A highly-skilled QE is invaluable, someone who can adopt a critical-mindset towards the feature and adopt a critical-mindest to the thinking of the other domain experts in attendance.
Critically evaluating != Being rude or dismissive
The time taken to understand the feature more than pays for itself over the course of a sprint by reductions in:
Misunderstandings
Observable defects
Attendant rework.