Setup

Whenever someone mentions the Three Amigos there is one thing that comes into my mind first: Martin, Chase and Short. I don’t remember enough to know if it was a good film. I remember laughing at it when younger. But I have less taste for cringe now.

The Three Amigos

You can find a definition from the Agile Alliance at their website, or this one from Kanbanize

Basically, get a BA (or PM), tester and dev before a new feature is being developed to talk about it giving their different perspectives, so you end with a better understanding of the piece of work that you are going to do, with agreed requirements.

In principle, great idea, but there are a few issues with it that bothers me.

The issues

Who is doing the work?

All versions of three amigos seem to recommend one person per specialty. Never the whole team. But is it the person/people that are going to be doing the job on that three amigos? Everywhere I have seen it implemented it always has the same dev on the three amigos (the tech lead), which means the rest of your team voices are unheard at the time 3A is happening. Of course, you don’t want the most junior person within the team on their own during this exercise, they could miss things. But if the person/people that will actually design the solution is not present when talking about it there will be always information missing, or misinterpreted. Language (English, Spanish, or whatever else) is not precise enough to convey exact information. That is why we have programming languages.

When is the work being done?

Furthermore, at what point are you doing 3A? Are you certain that the people that have talked about it are the ones that will do it? Some of the recommendations is to do 3A 2/3 sprints before you actually do the work. Holidays, unexpected system issues, sickness, new requirements … everything gets in the way of a well formulated plan.

If we use a typical 2 week sprint duration, that means some people are recommending do 3A up to month and a half before you do the actual work. Maybe there are environments in which everything stays stable for that long. But that has not been my experience in any company/client I have worked for. And that includes the understanding of the team about the system being developed.

Size of the team

All the different descriptions of 3A seem to insist on not using the whole team. But that goes against what I believe is the behaviour of a well performing team. A team needs to collaborate and communicate. 3A establish compartmentalization of communication.

A common concern seem to be the number of people in the meeting. But that raises flags to me. I am suspicious of any team with more than 6 devs, which usually means that the work being done is too heterogeneous. Also, limiting who can speak means lack of trust, and I prefer not to have a person I don’t trust on the team at all (or if I am not being trusted, is better for me to move somewhere else). Sometimes I can see that people do not collaborate, either because of communication is not free enough within the team, or because they lack the involvement, both things that need to be fixed.

Expertise and teaching

Not having the whole team means that you are discarding people knowledge and expertise. A single senior person can easily forget to ask a question, or make an assumption based on their previous experience. It happens to all. Some more seniors reduce the chance of assumptions being left unchallenged. Junior people can come with questions that could force a more senior person to reevaluate their ideas.

Furthermore, having only the minimal amount of people removes chances for the rest to learn and to get distribution of understanding. Learn about the system, about the domain, about the company, about the information that you need to gain. Most of it you can learn, but on larger timescales than otherwise you could have.

Coding is design

One of my shticks, a defining idea, is that coding is designing. And because you are designing, you discover information, roadblocks, uncertainty as you are working on a piece of code, which requires further thinking on how you wil approach the issue at hand (one of the reasons why working on pair or ensemble is a better proposition than the solo programmer). 3A happens on an idealized state, with the wishful thinking that you can discover everything before you start coding. That has never been the case (except in very edge cases). The talk should start when you are ready to start coding, and continue through the whole coding until the requirement is considered done. Tests are developed together with the code (automated or manual). PMs and BAs should be answering questions and looking for information as you require.

No talk at all?

Does that mean we don’t talk at all about a requirement until we start working on it. Well, no, of course not. As soon as a requirement comes a quick discussion can happen, just to put pins on possible ideas, questions, and to make sure that we know who in the company has the knowledge that we will require (nothing worse than having questions and the only person that can answer them has just left on a two week holiday … or worse, left the company). Furthermore, an initial discussion about the requirement will inform how the current architecture will support the requirement: no changes, some little changes, full rethink. But don’t action anything at that point. Requirements come and go, get pushed back, get superseded, or change beyond recognition. A requirement that you are not going to be working on as soon as you talk about it goes straight into the YAGNI category. That initial talk is what creates the cards/post-its/tickets/what-not in the sense of a reminder of a discussion that needs to happen.