The 3 Amigos in agile
I’m exploring the 3 Amigos in agile at the moment, as I feel it may be in need of a makeover. But first, the traditional view of the 3 Amigos. I know, there’s already loads of articles on the 3 amigos, but I thought it might be useful to understand my perspective. If you are well versed in 3 Amigos you’re just going to have to wait for the next post, otherwise if you feel like a nit pick or you genuinely want to know my thoughts on 3 Amigos, please read on.
Incidentally the earliest write up the 3 Amigos seems to be by George Dinwiddie in 2009. I reached out to George who confessed he was the originator of the idea, though at the time it was done within a company in subterfuge so a big deal wasn’t made of it. A similar concept but not called 3 Amigos can be found in the Jim Shore ATDD model by Elisabeth Hendrickson (p17).
What is the 3 Amigos in agile?
The 3 amigos in software development is a collaborative event that takes place prior to software development. It assists in deepening a shared understanding of the feature* that is about to be developed.
*for the purpose of this post I’m going to use the word feature, but it could be any piece of work: a story, a task an epic.
The 3 Amigos typically consists of a product owner, a software developer and a tester. These 3 roles provide different perspectives on a piece of work. The product owner is thinking about the impact of the feature, the software developer is thinking the optimal solution when building the feature, and the software tester is thinking a) how to test it, and b) implicit assumptions being made in the scope of work.
Output and Outcome in 3 Amigos
The output of these sessions is often a set of agreed acceptance criteria from which tests can be derived. The outcome is shard understanding on the feature, the why and the context within which the feature resides.
The Role of Software Tester in 3 Amigos
The role of software tester in this event is often to ask clarifying questions. I broadly put my questions into two categories. Business type questions – where I question the feature being designed. For example, I look that downstream and upstream systems have been considered. Or I think how might this feature impact other parts of the already existing system. And, if I don’t already know, I seek to understand the why behind the feature to get a better understanding of desired outcome.
The other type of question I ask is about technical risk. These I tend to direct to the software developer. I ask about security, or backend integrations. I ask about already existing api’s and the impact it might have. Knowing the technical risk, helps me decide if additional testing is required. So along with the functional acceptance tests, I can recommend additional types of testing.
In this way, I hope to uncover ambiguity and implicit assumptions that may have being made. I’ve also deepened the shared understanding not only of what is being built, but the context within which the feature resides. From a shift left perspective, I’m preventing bugs from being developed reducing rework and preventing nasty surprises later in the delivery lifecycle.
I’m sure many software testers reading this are in agreement and do something similar. The approach may be slightly different, and maybe it’s called a different name. What’s important, is that this type of collaboration is happening early on that is generating value.
Next up, the new 3 amigos, consisting of a product owner, a software developer and an ops person, why we need it and the value it could potentially bring.
Other content on the same topic:
Anne-Marie Charrett
Comments ()