上QQ阅读APP看书，第一时间看更新

The power of four amigos

Gojko Adzic named the solution to the conversation size problem the three-amigo meeting after the American western comedy from the 80's ¡Three Amigos!, a comedy showcasing the results of miscommunication in hilarious ways.

The three-amigo meeting involves the business representative, the developer, and the tester. I think that the UX expert should be the fourth amigo, to represent the users' needs.

The equation is simple. A business representative, usually a product owner, introduces the opportunity, the stories and optionally presents the initial scenarios, basically telling the other amigos what the business needs. Then, the UX expert will champion user needs, essentially representing the users in the meeting room.

The developer will bring the existing infrastructure and technical constraints to the table, often playing the devil's advocate. The developer will fight against adding unnecessary complexity to the software, eliminating ideas that might sound great, but would eat up precious development resources. The tester will consider how the story might be tested. Often, the tester will bring new scenarios or edge-cases, which will help to eliminate bad ideas that slipped through the other three-amigos.

Sometimes, the four-amigos can be three or even five; don't worry about the number. The key learning is to constrain the number of people to a handful, who can work together and discuss the project in a meaningful way.

When I worked as a consultant for a ride-sharing start-up (similar to Uber, but this was a different start-up); they always invited a domain expert, a guy who used to run a taxi company for years. He knew all about the taxi industry, regulations, and often came up with really clever scenarios. The three-amigo meetings had five people, and it worked great. On the other hand, for another start-up, when the two-amigo meeting was just the founder and me, the communication was much less fruitful--having a third person really helps. When I suggested inviting another senior developer, the founder (also being a full-stack developer) was not sure if that was needed. He thought that this would take developer hours from the other developer, hours for which he was paying from a very limited budget. After the first truly three-amigo meeting, he was convinced. As a side-effect, the senior developer was more engaged with the project and more enthusiastic. He still had the same share in the company as before, but now he felt that he could shape the future of it. This, among many things, contributed to the success of the app.

It's worth nothing that tech-amigos and business-amigos often have a hard time understanding each other. Moreover, business-amigos will not understand most of the techy discussion the tester, the developer, and the tech-savvy UXer will have. They might feel excluded and start finding excuses to avoid the amigo meetings. This goes the other way around too if you have a business domain expert, a business analyst and another business representative, the tech-amigos will be bored, and they will feel that the discussion had little or no actionable items for them, rightly so. For complex projects, you might need two, focused discussion groups, instead of just one. There should be a person present in both groups. Ideally, this person is the product owner, but not necessarily. The goal is to have the two discussion groups working in sync to create a great product.