Some learnings from using the complementary Agile practice of the 3 amigos in the face of change and adversity.
The ‘3 amigos’ allow for different perspectives from the business, development, and testing communities to come together to ensure there is a shared understanding of User Stories across the team.
The practice can include more than three people. Three to four amigos will work quicker than a large team, but above all, the right people with the knowledge and the decision-making authority need to be present. Once clarity is achieved on the User Story, it should be communicated to the rest of the team.
This is a practice that I’ve enjoyed introducing to newly formed teams I’ve worked with, to discuss the more complex stories we couldn’t get through in Backlog Refinement.
When this practice is going well, Scrum Masters experience a warm glow on seeing the amigos breakdown the complexity, gain clarity and start working towards well-understood acceptance criteria.
What happens when you face challenges with this practice in the form of certain behaviours or team dynamics that are starting to impact the quality of your product?
This post explores a few learnings based on my own experience, through instilling this practice within teams.
In one of my lifetimes as a Scrum Master, my team went from a situation where we had a fully engaged Product Owner who was attending all relevant Scrum Events, to a dramatic drop in availability.
My team was building a mobile app with national exposure. Release dates were published. Our stakeholders were watching progress with keen interest, but we just couldn’t get the Product Owner time we needed.
To get the team together, I took the opportunity to book an offsite space for the Retrospective. Our Product Owner accepted, to my relief!
At the Retrospective, the team vocalised their frustrations and the Product Owner explained he was trying to get to grips with 3 other projects by reducing meeting time. Now that he had understood the demands and complexities of these projects, he was happy to delegate a couple of these to another member of his team, to allow his focus to return to our project.
I was fortunate that our Product Owner had thought of a Plan B, however, I still walked away with a few lessons….
Act early: Check in with your all your stakeholders regarding resourcing regularly. Don’t do what I did in this scenario and act only when the availability of your Product Owner starts dipping!
Get to know the Product Owner community: Whether it is through scheduled meetings or lunch and learn sessions, I’ve found it’s important to get to know the community and their product specialisms. This allows you to put forward solutions for back-up Product Owners, should you need them to support you, and be part of the resourcing conversation well ahead of time.
Occasionally pick an offsite setting for your Retrospective: Getting away from the office even for an hour, allows your team time away from distractions, and gives them the opportunity to share their challenges and or frustrations, in an informal setting.
I was leading a Scrum Team in an agency environment. The team’s project was to deliver re-branded websites for a household brand across 14 markets globally. We had 6 months to complete the project.
Customisations for the individual markets were coming in thick and fast. We used the 3 amigos principle to get to the bottom of complex requirements promptly, then planned them into a release so the market would know when to expect them.
By month 2 of the project, our Tester wasn’t turning up to the 3 amigos sessions to discuss the customisations.
Over coffee, I learned that she was exhausted, but didn’t want to be seen as a team member that couldn’t handle the pace or volume of work.
What I thought was a lack of motivation, really wasn’t. This got me thinking about how many other team members were also feeling like they were treading water and how long it would be before the quality of the market releases would dip. It was time to get some perspective on the working hours and readdress the balance so they could perform at their most optimum….
Scrum Values: My take on the values is that they are there for the protection and nurturing of the Scrum Team. I re-surfaced these and had a discussion with the team on what each of the values meant to them so they could form a Working Agreement on how they wanted to operate. The team started to open up to each other and new ways of working. They knew that they needed to be working at a sustainable pace. Those overworked spoke up, we mapped out the excess work and made a case to the Account Director for extra funding and onboarded additional team members.
Take another look at your estimations: We were barely using 5% of the time on Backlog Refinement which was rushed, and this was resulting in an underestimation of the testing effort. The team decided to expand that to the 10% rule of thumb. They would then review the estimations during the Retrospectives and agree on how they could improve estimating and take their learnings into the next Sprint Planning.
Imagine my surprise and feeling of dread when our Product Owner walks into the Daily Scrum on day 1 of a Sprint and says,
“Hey Nisha, it’s great that we can add some last-minute stories to reduce the tech debt.”
Without talking to anyone else on the team, our Development Lead, aka the Lone Ranger, was using the 3 amigos sessions to convince the Product Owner it was a good idea to add stories after the team had already agreed scope for the forthcoming Sprint.
These stories would magically appear on the Sprint Backlog and the Development Lead would convince the team that he could easily manage the stories and complete them with plenty of time left for testing.
For fear of getting on the wrong side of the Development Lead, the team agreed. However, I noted murmurs indicating they weren’t comfortable with not having assessed impact on code they were working on, or the testing effort.
I decided that I wasn’t going to confront our Lone Ranger, I wanted to let the Sprint play out to see if we could deliver on our commitment. To encourage self-organisation, I wanted the team to surface this problem during the Retrospective and come up with a solution for unplanned work.
Two days before the end of the Sprint, the Development Lead announced that he was planning to check in a significant amount of code for the technical stories.
Bear in mind that this code hadn’t been peer reviewed and none of us knew for certain how much unit testing had been done. The team wasn’t having any of it. Objections started from the testers and rippled through the team. Let’s just say it was a ‘Spartacus’ moment.
The team populated their activities on the Retrospective Timeline and when it came to rating the activities as ‘Good, ‘Bad’, or ‘Needs improvement’, the majority of ‘Bad and ‘Needs Improvement post-its’ were found by the unplanned technical stories.
The team explained they wanted to deliver on their Forecast and wanted to be able to trust that they wouldn’t be surprised with unplanned work. The Development Lead expressed concern that the impact of not reducing technical debt could eventually lead to a degradation of performance.
The outcome was a sensible agreement that once the scope of the Sprint was sealed at the end of Sprint Planning, new stories were not to be introduced, without re-negotiation between the Product Owner and Development Team as more is learned. If the team members completed their work, they would help the team to finish the Work in Progress.
No one disputed the need to undertake work to reduce technical debt, so the team agreed they would speak to the Product Owner and agree to set aside a sensible percentage of their capacity to that effect.
Working Agreement: When you’re forming a Working Agreement with the team, decide what your team’s policy is going to be on unplanned work. It doesn’t matter if the policy is adapted later. Having a starting point is better than nothing.
Retrospectives: Facilitated well, Retrospectives can have so much value and I’m working on improving my skills. I’ve found that keenly observing the team behaviours and responses to challenges during the sprint gives valuable clues into how the session can be facilitated and the exercises you can use. For me, the overall goal is to create a safe environment for the team to speak freely, with sensitivity and a sense of confidence to raise actions themselves for addressing obstacles they experience.
“You improvise, you adapt, you overcome”
Clint Eastwood, Heartbreak Ridge
Applying the simple practice of the 3 amigos brought up some key challenges for me which encouraged me to train my gaze toward the team dynamics to get the best out of the practice.
My own servant leadership qualities were developed by creating opportunities for the teams to decide how they would like to address challenges. This allowed space for reflection and ownership for the remedies put forward, setting them back on track to realising their Rockstar status in delivering value to the business.