Using the Scrum Framework? Don’t burden Scrum Teams!

I always thought that crew looked like a cool sport and I’ve admired crew teams. In crew, team members in lightweight boats, race to go as fast as possible. It is hard work! I think the crew team is a useful metaphor for Scrum teams.

Crew teams strive for speed so they keep everything as light as possible by eliminating anything heavy or unnecessary. The more strong people that are rowing, relative to the weight of the boat and everything on it, the faster the boat will go.

Crew teams can range from one to eight team members. A large crew team will have a coxswain supporting them. The coxswain isn’t rowing – instead, they coach the team, help the team steer, and keep the team focused and safe. They help the team to be efficient and effective and to go as fast as possible.

Scrum Teams are a little like Crew Teams

There are some similarities between the crew and Scrum Teams. Scrum Teams also try to go as fast as possible by being efficient and effective with their actions.

They also eliminate any unnecessary weight in the form of people, process, documentation or anything else that is not required and slows them down. And in Scrum there is the Scrum Master who, similar to the coxswain, is responsible to coach the team and help them go as fast to go fast as possible.

Imagine you had a crew team of four who were rowing their boat. Imagine that there were four or five others who were very interested in being on the boat but not contributing anything by rowing.

They wanted to be along for the ride, but not actually rowing or contributing to the forward motion. In the boating metaphor, these people would be just a dead weight to the crew team. They only slow the team down. It would be obvious and no one would tolerate it.

Don’t Burden Your Scrum Team

It is unfortunate but a common problem when organizations use the Scrum framework that they burden their Scrum Teams. It happens when we have people outside the Scrum team who don’t observe clear roles and boundaries and are behaving in ways that slow the team down.

It also happens when teams are not trusted, or when people are micromanaging. And it happens when Agile leaders don’t really know how to lead in an agile environment.

Frequently I will find well-intentioned individuals interjecting themselves in what the team is doing and concerned about the outcomes. They can make a lot of noise but they don’t deliver any valuable work themselves.

Instead, they direct individuals to work on different things, call meetings to gather status, churn requirements, change priorities or introduce urgent requests and generally create distractions and unnecessary work for the Scrum Team.

Examples of these interested parties could include the PMO, supporting business functions, department managers or functional managers like training or quality assurance. Additional stakeholders can get involved when the team is not connected to the end users and instead are forced to work with proxies or intermediaries.

These proxies may represent a handoff of information and cause more noise, rework and confusion because they don’t really know the business needs.

To be clear – these individuals are producing little or nothing of value. Proper Scrum Teams have all the skills they need and have been coached to self-organize.

To the extent that the external parties remain directly involved, they slow the team down. The higher the ratio of interested parties (i.e. weight on the boat) to those doing the work (i.e. rowing the boat), the slower the team will go.

Get The Right People on the Scrum Bus

Jim Collins of Good to Great fame had a good analogy for this. He said:

In the Scrum Framework, getting people into the right seats is straightforward because there are just three clear Scrum Roles. There is one Product Owner that prioritizes the backlog and makes decisions on WHAT the team should work on next.

There is one Scrum Master who coaches, protects the team, and removes impediments. Everything else is done by the Development Team.

The Development Team in Scrum is dedicated 100% to the team goals and they self-organize and decide HOW to complete the work as quickly and efficiently as possible. (Read more about the Scrum Framework and Scrum roles in my related post, Using the Scrum Framework, Stay in Your Lane!)

Everybody Abides by the Roles in the Scrum Framework

The roles in the Scrum Framework are clear about what the Product Owner, Scrum Master and Development Team should do. By defining these three roles, the Scrum Guide is also clear about what to expect from those managers, stakeholders and other interested parties who are not mentioned in the three Scrum roles.

For anyone who wants to tell the Development Team What to work on:

Telling the Development Team what to work on is the role of the Product Owner. There can be only one PO for the team. This is to prevent the all too common dysfunction that the Development Team is trying to serve multiple masters, getting conflicting direction and priorities, and working ineffectively because they are starting and stopping.

It also eliminates the despair team members feel when priorities change abruptly and their plans and work in progress are no longer important or valued.

The Scrum Product Owner priorities are reflected in the prioritized product backlog. All requests for new work should be directed to the product backlog and the Product Owner should determine the priority.

Any individual that wants to tell the team what to work on should collaborate with the Product Owner. The priorities should be clear in the product backlog and the Dev Team should have only one master to serve.

For anyone who wants to interrupt the Development Team:

Interruptions introduce churn and inefficiencies. The Scrum methodology is clear that the team should be allowed to focus. The Scrum Master should protect the team from the interruptions and distractions like a sheepdog would. Typical distractions include:

• Managers who pull individual team members to work on special projects
• Stakeholders accustomed to going directly to the developer to get favors done
• Managers who fractionally assign people to projects and keep splitting people into smaller and smaller pieces to assign to more and more projects
• Stakeholders or Managers who invite team members to status meetings to check up and see how things are going

That last category is particularly insidious. Under the guise of good communications, many well-intentioned individuals will invite the entire Development Team or key Dev Team members to weekly meetings to get status updates.

I liken this to pulling up plants in the garden to examine the roots and see if they are growing. These status meetings are more likely to occur if the team is perceived as falling behind schedule. Ironically, by interrupting the Development Team to hold a status meeting, the work is likely to fall even further behind.

Instead of interrupting the Dev Team when they are focused during the sprint, it is better to let the team finish their sprint and then see what they achieved in the Sprint Review.

If you want high-performing Scrum teams, don’t bother the team. The team should be able to focus during the sprint.

If interruptions or distractions occur during the sprint, then the Scrum Master should step in to protect the team as noted above. The Scrum Master is there to protect the team and make sure that interactions with the team are productive.

For anyone who wants to direct, micromanage or otherwise tell the team How to work:

Deciding how to get work done is the sole purview of the Development Team. Dev Teams don’t need others telling them how to work; they are self-organizing. We insult them when we assume that we need to direct them or micromanage them.

This category includes those who have grown accustomed to being helpful or solving problems for the team. Frequently leaders will jump in and solve problems for the Dev Teams. Or they will offer unsolicited advice. Doing so only deprives the team of learning and fosters dependency. Stop it!

How to Help Your Team Use the Scrum Framework

It should be clear that there are really only two ways that outsiders can help the Scrum Team, rather than hold them back. Agile Leaders should work with those interested parties to get them to do one of the following:

Option #1 – Leave the Development Team Alone

I know this may be difficult for some, but they need to get out of the way of the team. They need to stop being a burden and let the team alone to do the job they need to do.

Even if they think they are helping the team – they probably aren’t. Stop inviting them to meetings. Stop interrupting them when they are working, or going to the Product Owner to get favors done.

Managers may feel it is their job to get into the details of what the team is working on. No, it’s not. Rather than focusing down on the team, managers should level up and begin doing the more strategic and important work they were hired to do.

I’ve outlined the leader’s role in several related blogs including Ask Don’t Tell, Hire Motivated Individuals and Leaders go First. We’ve also created an excellent resource page for leaders who want to learn more, and we offer agile training courses for Agile Leaders as well as for Coaches.

Option #2 – Join the Development Team

There may be other individuals whose help and input are valuable to the team. They should join the Development Team! They should move from coaching and advising on the sidelines to getting in the game.

If they truly want to help, they need to move from being an outsider to being a full-time, committed team member that shares the Dev Team’s goals.

Full-time Dev Team members get to vote on how to work, but they also are responsible for helping the Dev Team go fast and create business value.

To the extent that these stakeholders move from being a burden to the team to being a valued worker by directly rowing the boat, the entire organization will go faster.

Self Check – Are Your Scrum Teams Being Held Back?

Now that you understand the intent of the roles in the Scrum Framework and the behaviors that help and those that hinder Scrum Teams, do a quick self-check.

1. Are your Scrum Teams going slow because there are extraneous people being dragged along that are not producing value?
2. Are people telling the team what to work on, how to work, or interrupting them during their sprint? Are you doing it?
3. Can you make life better for your team by getting the right people on the boat, and everyone else off the boat?