This method aims to :
- design new features in the best possible way.
- ensure shared understanding of the feature.
I discovered this method a few years ago, and I was quickly won over. But before explaining in details who are these “3 amigos”, it may be better to analyze the default “watefall” process.
The default “watefall” process
- design of the feature : the Product Owner (PO) collects needs from his customers, then imagines a feature to meet these needs. This feature is then described in a (more or less) long and detailed specification, eventually with visual examples (Marvel, Figma, etc.).
- implementation of the feature : the feature specification is given to the development team. Sometimes, there can be a kick-off meeting (with developers and product team) to officially launch the implementation. The developers then implement the feature. Once it is done, the feature is sent to QA.
- test of the feature : the QA takes note of the specification, then tests the feature implemented by the developers. If everything is OK, the feature can be released. If QA finds bugs, it sends back the ticket to the developers, who will fix (or not) the QA feedbacks. Once done, the devs send the feature back to QA, and we start over until release into production.
With this process, we can easily find out some issues that can create friction or slowness :
- QA is not always included in the discussions during the feature design : QA cannot therefore discuss in advance the tests that need to be carried out, nor warn about scenarios that would have been forgotten by the product team.
- Following previous point, QA can also misinterpret the specification and then run irrelevant test cases.
- The developer cannot say anything about the designed solution : his role is then limited to a “mere performer”.
- During its tests, the QA may think that behavior is not the expected one. He will then discuss with the developers and / or the PO. In case the QA is right, the developer will have to rework the behavior (rework ==> loss of time). In the other case, it will represent a loss of time during discussions (and eventually with the change of focus.)
To get rid of these issues, the “3 amigos” are there for you!
The “3 amigos”
- put together, as soon as possible, our 3 friends: PO, dev, QA (hence the name of the method)
- for the PO, have a precise, but eventually not definitive, idea of the feature to be implemented
- PO provides the added value of the product: he knows what are the real needs, and can therefore choose the best solution to meet them
- Dev is the technical entity: he knows what will be easy (or not) to implement, and will be able to propose to the PO equivalent costless solutions. He can also estimate the workload and thus alert if the ratio (added value / cost) becomes too low
- QA provides the test part: he searches for all the weird usecases, and can already show which tests will have to be done, so that the developer can already take them into account, or even test them himself during development. He can also remind about the testability of the feature.
The main goal of this ceremony is to allow a better communication between people who are often separated. It allows a shared understanding of the feature, while minimizing the risks of rework, due to poor specification. Finally, note that this is a real application of one of the precepts of the agile manifesto “Individuals and interactions over processes and tools”: https://agilemanifesto.org/
What you must remember
- Waterfall process isolates QA, limits its contribution, and creates slowdowns and frustrations
- the “3 amigos” process
- includes PO, dev, QA
- aims to rework / complete the specification of the PO
- allows a shared and complete understanding of the feature