Join the Mastering Agility Discord community!
Photo by Alessandra Verre on Unsplash
This article was co-written by Sabrina Love.
Meet Team Sauron. Sauron is a Scrum Team working at Magnum Opus, a company that creates biometric security machines. This team specifically is creating facial recognition software with highly sophisticated cameras. The team consists of the following people:
Product Owner - Ruben Blackstone
Scrum Master - Rafaela Higgins
Developers - John Doe, Joanna Doe, Anna Nonimous, No Wan Noes, Patty Kong
They have successfully delivered increments for 15 Sprints, but they have been struggling in the last three Sprints.
In the refinement session, the team runs into the same issues they have in the previous Sprints: they don’t have the right skills to address some of the upcoming work having to do with more advanced facial recognition software. Ruben, the Product Owner, is the first to recognize this impending impediment. The team has tried to refine these items before but they always seem to get stuck and ultimately agree to do some research offline. This is the third time they’ve tried, and now it’s becoming increasingly more risky to continue on the current path. Ruben presented the current state of the roadmap and Product Backlog that demonstrates an increasing amount of functionality depending on the missing skill.
Ruben raises his concern to the team; he’s worried that there are missing skills on the team that will prevent him from being able to do his job and maximize the value of the product they are building. A few Sprints have gone by where Ruben has acquiesced to the team’s request to do more research before diving into the advanced features. But they haven’t shown meaningful progress yet, and Ruben’s stakeholders are starting to get antsy. Which means Ruben is starting to get antsy. He needs a solution to this problem before the team runs out of funding. To Ruben’s credit, he presents the problem to the team and gives them the opportunity to figure it out.
The following week, the team reconvenes, and they have some proposals for Ruben:
- - - proposal #1 - - -
“Euhm, why don’t we just hire another team?!” Joanna noted as a first giggle.
Rafaela, the Scrum Master, explained: this is actually more like trying to deliver a baby in a month with nine pregnant women - adding more people to an already-late project will just make it later.
- - - proposal #2 - - -
Spend more time upskilling. The team is adamant that they really can make progress: they even pinky swear. They show Ruben a few classes they could enlist in, and have a vague idea of how they would improve their skills on the job.
“If you want to learn new skills, that’s awesome. However, it’ll take too long. I mean, you guys just mentioned you’d be up to speed to an expert level in a year from now. We need the new stuff in three months completely up to speed already. So that’s not really gonna be useful. Be my guest if you really want to take the courses, but that won’t change the fact that we’d still have a big dependency that’s not gonna be resolved.”
- - - proposal #3 - - -
No Wan thought of another option. “What if we hire an external team member? That way we don’t have to fully onboard them internally, yet can start working right away.”
Rafaela had her doubts. “Process-wise that would be correct, but it would still mean a dip in productivity initially, plus externals are super expensive these days.”
“And looking at the budget that we currently have, we can’t even afford to hire such a person. We’re scraping the barrel as is. We’ve got $360k available for the coming 6 Sprints. That means $60k per Sprint, for the entire team, including salaries. That’s not a whole lot to work with, yet we need to release something after those 6 Sprints. So our time and budget are limited.”
- - - proposal #4 - - -
Patty looked puzzled for a bit, after which she hesitantly added “What if we would let one of our own team members go as a trade for the external expert?” The eyes of the others looked like they were going for the kill. Although it may be a viable option from a cost perspective, the impact on the team’s dynamic would be unparalleled. Resentment against new team members after cutting off one of their befriended team members would immediately create a bigger hole in value than the new team member could fill.
Ruben and Rafaela listen to the team’s proposals: Ruben’s face speaks volumes that he isn’t very keen on either of these ideas, and he hopes to influence the decision another way. He looks to Rafaela for her guidance.
Rafaela considers the options presented by the team. She wants to support self-management but doesn’t want to endanger the delivery of value.
Ruben opted for another option. “What if we would swap products with the Panda Crew? They’ve worked on facial recognition software before, they know at least a part of it.” Rafaela noted that if there were a temporary dip in productivity when swapping one team member, there probably would be a massive dip if the entire team would exchange.
After some moments of silence, John said he recently listened to an episode of the Mastering Agility podcast on dynamic reteaming by Heidi Helfand. People who are experienced in the ways of working in the team, in this case, Scrum, and who have the desire to explore further and develop further, could benefit from cross-pollination. Spreading their wings to another team while another internal person would replace his position would mean a small temporary dip in productivity because this person would already be used to corporate culture.
Some options were now presented. Ultimately the team chose for a watered-down version of dynamic reteaming. They just called it reteaming.
Sometimes temporary pain is needed for lasting gains.
Parting ways with fellow team members can be a painful process. Especially if either the team members are really close, or if the decision was not completely voluntary. On the other side of the coin, blindsides to one’s own behavior can occur after a while. Bringing in new people can bring that fresh breath of air that the product is craving so badly.
While they were aware of potential disruptions, reduced transparency, context switching, and a temporary capacity decrease, they believed that the introduction of an experienced Scrum Team member, already familiar with the company's culture, would help them address their skill gap and ultimately contribute to delivering valuable increments in the long term. Maintaining their team culture and facilitating a smooth onboarding process for the incoming member were key priorities as they navigated this transition.
Scrum Teams are self-managing, and cross-functional, meaning that they have all the skills on board to deliver Done Increments. This inherently means that they have the mental capacity and capability to decide on who is in the team and who goes. We have seen too many examples where management barged in like a rhino and told people to leave or join another team, for a variety of reasons. This devastated the people and team’s ability to deliver those Increments. Subsequently, it goes directly against what Daniel Pink and his team found on why autonomy is so important for people working in complex domains. We appreciate the fact that teams more often than not are funded by management. However, this does not mean that they are owned by management. Keep the decision where it should be - with the teams. If they are stuck, the Scrum Master can work with management or HR to figure out the next steps. But for the sake of self-management and growth, do not take away their voice in all of this.
We’re sure that this may be a familiar scenario or at least parts of it. We’re curious what your experience is and how you dealt with it. Maybe even more importantly; what did you notice was the effect on the team? Let us know in the comments