Three Amigos… Who?
Nope, not these three!!
Some people in the technology field are familiar with the term “Three Amigos” (Three Friends in English). I first came across an automation test discussion with my husband, who is a test engineer, and our friend, who is now a principal engineer.
They were explaining that every team has “three friends” that work together daily to achieve better product quality by debating new ways to develop and test and other good practices to follow even though ‘three’ does not always mean only three people.
It got my attention to understand why people usually consider only these three roles as the “Three Amigos.” So I started my research.
In the book “Agile Testing” by Lisa Crispin and Janet Gregory, they named this practice as “The Power of Three,” which stands for product experts, developers, and testers.
I also read in a few places that during the sprint the product specialist discusses the what, developers (most of the time only tech lead) discuss the how and testers discuss scenarios and tests to cover.
Well, nothing against they talk about the product. They should be talking. But I don’t agree to have only a few people. I’ve always evolved in every product discussions the whole team. Primarily to provide transparency in what’s going on. And that makes me feel more comfortable in creating something that the group owns too.
As a Product Manager is my duty to share every step and detail of the product with my team, especially, trust and make them feel as owners by having autonomy during the whole process. That being said, I must carry good practices along our journey together.
What would be these good practices?
- Empowerment: Team has a voice, and I listen to each opinion to take into consideration for our product.
- Refinement: When we get together to discuss upcoming features considering design, stories, and development, and review our roadmap and release plans as necessary. I like to use different techniques in a way to get people’s attention, and it helps to achieve meeting objectives into a timebox frame. Also, we all listen to each other’s opinions and concerns.
- Acceptance Criteria: For this case, I like to consult the test engineer (QA) and the designer about the acceptances that I wrote for next sprint stories. I always get useful insights from them because it is more than usual the PM forgetting few minor details, and you must be humble enough to recognize it and be open to others’ insights. Likewise, the team has total autonomy to take their own time to read the backlog and give feedback.
- Product & Continuous Discovery: If we have new product or new features, we — together as a team — brainstorm our ideas and debate getting to a common-sense using techniques to help. Also get the team close to users to create empathy for those who will use our product and to understand their habits, pains, necessities. Even though it is hard the whole team participates in Continuous Discovery due to sprint tasks, it is essential they feel part of it by getting all the updates, open participation to the usability testing and provide insights.
- Quality and sense of urgency: The team must embrace product quality as everyone’s obligation. Not only the test engineer is responsible for testing, but each person responsible for product development has to make your part on quality. And develop a sense of urgency when needed to accomplish plans, deadlines, etc. Sometimes we have to make a team effort to fix issues, whatsoever, important is to evolve everyone and get the community feeling.
These and a few more.
It is only possible to create a product if you get a team to work on it together. The development is everyone’s responsibility. And it does not make any sense for the PM to take credit alone, as the Product Owner is part of a Scrum Team and we are running the same marathon to achieve the same purpose.
Scrum Team means:
- Product Manager: The person responsible for the product vision, strategy, roadmap, backlog management, and everything related to it.
- Scrum Master or Agile Coach: The person who monitors and measures our team progress, protects the agile framework and coaches as necessary, helps removing obstacles for our team and many other activities.
- Dev Team: This stands for Programmers, Testers, Operators, and Designers. They make the magic happen by creating and developing our product.
As you can see, we got three different roles in the Scrum Team. Some people might say that the Scrum Master/Agile Coach doesn’t play a role which discusses product. Wrong! Have you ever read the Scrum Guide?
Every SM that I worked with helped as much as anyone else in our product decisions. Not only providing ideas during brainstorms but helping me as PM ensuring that our team got all the PBIs, criteria, and goals right to deliver better quality and to improve the teamwork towards our goal.
(Btw, totally different than micromanaging. #getthistip)
Looking at these roles, we see three types of jobs that are swimming in the same ocean, and we have to get to the beach altogether. So, using the terminology by Lisa and Janet, we got “The Power of Three” on each three roles in our Scrum Team.
Being more philosophical about it, ‘team’ means “come together to achieve a common goal.” Saying that we cannot divide our group only in product experts, developers, and testers for the ones to debate about our product quality and all.
The practices that I shared above are incredible examples of how to make the Three Amigos work. Be sure your team is willing to be part of the product not only coding or doing what each role is meant to do, but also using these differences and capacity, these unique specializations in product’s creation by getting all contrasting mindsets and turning into the same goal. Where every opinion counts and is listen.
If a programmer or anyone else cannot participate in a meeting, afterward explain what happened to him/her, so everyone stays on the same page. Transparency is a crucial Scrum Artifact, so ensure this follows throughout the project without exception.
Remember, any individual still has his/ her job to get done as respective roles, BUT they must have autonomy in how they want to do their work.
Every person can contribute to success. Just let it open for the whole squad to have the opportunity to cooperate and feels as they belong, feels as owners.
(Please notice that I’m not native in English and I apologize for mistakes)