Is “Protecting the Team” the Right Thing?

If you were to ask a Scrum Master what they do a common response is “we protect the team.” From the context of protecting the team from themselves or an aggressive product owner as Mike Cohn describes, I would agree. Protecting the team from complacency or overwork is a worthy endeavor.

For many Scrum Masters, protecting means shielding the team from outside distractions and interferences. These distractions and interferences come in different forms but most of them are from other humans. Here are three I have witnessed and experienced:

  • The “trespassers” have lost their voice of influence on a product or project. This may be a senior leader with a history of ownership on a product. As an organization grows, there is a need for them to relinquish control over their product but this is often a challenge for many senior leaders. They feel the need to strongly interject their opinions on the direction of a product vision or backlog. For the product owner, this leads to a lack of autonomy and a feeling of frustration. For the senior leader, this leads to intruding on product owner territory to get their ideas heard.
  • The “uninvited guests” have lost their assignment to direct the team. This is typically a manager with direct reports on the team. Prior to agile, they would be the ones who would assign work to the team and would always know what the team was doing. Status reports often originate from the uninvited guests (who are now looking from the outside in).
  • The “requestors” have lost their direct connection to team. This is typically a business person who in the past, had the ear of a developer and now must bypass the product owner. When something needs to be fixed or tweaked, a quick call to the developer and in just a few minutes the changes were made. This behavior often continues even after a team has assigned a product owner.

Our natural response to these situations are to protect, to shield, and to make life easier for the team by limiting the number of “distractions.” But just how should a Scrum Master handle them?

As an example, when the “trespasser” attempts to influence a product backlog, is a Scrum Master expected to tell the leader to back off? I have found very few who will. Most recognize their performance review, salary, bonus, and reputation are tied to the perception the leader has of them and are not willing to take the risk.

Beyond the personal impact, being in a mode of protecting also:

  • Increases isolation. As we continue to deflect people away from the team without creating an avenue for communication and conversation, we are conditioning them to never return. While this may seem like a good thing, this is where silos are born.
  • Fosters distrust. When people are isolated it is natural for doubt and suspicion to begin. For leaders, this is typically the time they will feel the need to get involved.
  • Solves nothing. Shielding the team will buy some time…until the next time. There is a short-term alleviation of discomfort or inconvenience but the real issues triggering the need to protect won’t go away.

As an alternative to protecting the team, here are a few areas for the Scrum Master and team to focus on to begin transforming into a culture where protection is no longer necessary:

Become a radiating team. I mentioned this in my last blog post. By naturally radiating work progress, the team begins to feel open and welcoming. Nothing feels hidden or mysterious.

Create connection points and conversations. The sprint review is a great place to start. Make this session open to all and facilitate healthy dialog around what reviewed and the direction of the product. Design other serendipitous occasions for people on the team to interact and engage with stakeholders and leaders.

Focus on co-creating opportunities. When the feeling or sense of protection emerges, use it to seek out ways to build things together. There are advantages to this:

  • Co-creation will illuminate lack of trust (and build trust) very quickly. For many organizations, a culture of distrust is just below the surface and is rarely addressed. By co-creating, we can begin to address this painful dysfunction and find ways to rebuild trust where needed.
  • Co-creation will amplify the strengths of each participant. When we spend time with each other, we learn how to leverage the best each has to offer.
  • Co-creation has transparency built-in. No need for status reports or additional meetings as vested parties have all contributed to the work. The Agile Leadership Engagement Grid walks through an approach for this type of transparency and connection at different levels in the enterprise.

SHARE YOUR THOUGHTS: Are there situations where you feel you must protect your team? Do you have any techniques to welcome interaction and co-creation? Please add your comments below.

Please note: I reserve the right to delete comments that are offensive or off-topic.

Leave a Reply