Note: This is the 3rd installment in the Scrum Hacks series.
What is Three Amigos?
Three Amigos is a collaboration technique used as part of the scrum process to define:
- what to do
- how to determine that it’s been done correctly
It requires the collaboration of the three primary perspectives in a development team:
- Business (represented by the product owner)
- Quality Engineering
What Three Amigos is not
Don’t confuse Three Amigos with backlog grooming. Both meetings are about defining what to develop and build, however, backlog grooming involves the whole team, happens on a regular schedule, and doesn’t generate any testing scenarios. Despite all the discussions that occur during backlog grooming and sprint planning, it’s still possible to have a fuzzy understanding of what is to be built afterwards. The Three Amigos is a much smaller group, it happens on demand, and generates test scenarios as output.
Why should you try it?
- tired of changing requirements…
- not excited about getting code drops to test in the last two days of your sprint…
- a believer in building in quality right from the start…
then you should definitely give this technique a try and witness a great transformation in how your team operates.
Who attends a Three Amigos?
The “Three” in Three Amigos refers to these three roles:
- the Product Owner
- the Developer writing the code
- a Quality Engineer
It’s not just the number of people involved. Sometimes it’s Four Amigos when a member of the UX team is involved.
What is the expected outcome?
A Three Amigos results in :
- a clear understanding of the functionality to be delivered
- clear acceptance criteria
- documented test scenarios that verify the code functions as intended
When to do it?
Three Amigos should happen as soon as the developer picks up a story from the sprint backlog. The timing is a key element in ensuring the Three Amigos success.Three Amigos facilitates building quality in from the get go, rather than trying to add it at the end.
Why do it?
- to build a shared understanding of what to build and how it’s supposed to work amongst the team members
- to identify any misunderstandings, assumptions and confusion before coding starts
- to let learning happen sooner in the process
- to shorten the feedback loop between Product Owner, Developer and Quality Engineer
- to provide developers more visibility into what they’ll be to developing and any associated challenges
How did we first embrace it?
Well, we weren’t very good at it when we first started Three Amigos. We treated Three Amigos just like another scrum ceremony that had to be followed, and we weren’t too excited about it. But once we figured out the value it brought us, it quickly became an indispensable tool. The increased clarity and cooperation amongst the team translated to increased sprint velocity. Three Amigos has become so ingrained in our process that it is now a habit.
When did we see the value?
We saw the value of Three Amigos whenever we didn’t use it. Sometimes we either forgot to do it, or we delayed doing it until development was almost complete, or we skipped it altogether because we assumed that the requirements were clear, self-explanatory. In some of these cases, we noticed that a disconnect occurred between developer and QE, resulting in functionality that did not match QE’s testing assumptions – precisely what Three Amigos is designed to eliminate.
What did we discover?
Everyone is responsible for Quality, not just QE personnel
With Agile moving towards breaking boundaries between Developer and QE roles, developers are also contributing to automation tests. This makes adding QE guidance during Three Amigos extremely valuable, helping to maintain the QE perspective in all testing, no matter who’s writing tests.
QE now develops tests in parallel with development
With QE involved early in the process, there were times when the automation tests were ready and we were actually waiting for a code drop to run the tests against. This happened more often with service tests than UI tests. This had the added bonus of getting our developers to think about and finalize the service contract, and to develop endpoints with mock responses that QE can consume in automated tests.
Reduced Defect Backlog
Because Three Amigos exposes developers to all possible testing scenarios, they can handle them proactively, resulting in fewer defects being created during testing.
What works for us?
While there are various interpretations of the approach, we have adapted this technique to suit our team’s needs. For our team, Three Amigos:
- is more of an informal conversation than a time boxed meeting
- happens in small groups (sometimes it is a Two Amigos, and we circle back with our Product Owner with any open questions)
- happens on demand, reducing the overhead of more meetings
- means more brainstorming to flesh out test scenarios and acceptance criteria.
- is documenting acceptance criteria and test scenarios in quick sentences (in a lot of instances using Gherkin syntax which translates easily to cucumber spec) and pasting vital information into Jira stories
- sometimes it evolves into a much deeper conversations, uncovering issues that become new topics for our Technical Design meeting
What to keep in mind?
- Think of Three Amigos as an attitude for a conversation that needs to happen
- It doesn’t have to be an unattractive recurring meeting. Just walk over to the other person’s desk and start a conversation
- If you do not document the outcome, you lose the very purpose for even attempting Three Amigos
- Keep it simple and crisp. While a whole lot may not be achieved in the first few attempts, soon you will find a pattern that works for your team
Want to read more? check out this article introducing Three Amigos.
Sometimes we need a cool name for a process to have teams adopt it. Three Amigos makes so much sense, I wonder why they didn’t invent it earlier…
When I joined the teams, the ‘traditional’ approach was apparent – UX tended to meet with the product owner and hand the team a design during backlog refinement and sprint planning; the dev picked up the story and wrote the code during the sprint and then QA developed test cases and ran tests towards the end of the sprint….talk about a “hand- off” mentality. There was not much in terms of collaboration. Actually we often confuse meetings for collaboration – the mere fact that we are meeting for backlog refinement doesn’t mean we are collaborating.
Three Amigos is truly a collaborative meeting: it is pull-oriented; we meet when needed – and we bring on board the team members who actually deliver the specific story. The results are – a collectively clear understanding and specific test cases. The benefit – preemptive meeting – true quality assurance that prevents defects being introduced into the code.
It’s true that Dev and QA can always meet and discuss, and have the product owner join them for clarification; however calling it the Three Amigos gives the process a label that translates to a clearer, shared expectation regarding its outcome…