Are You Holding Your Agile Teams Back?

Anthony Mersino
March 29, 2017

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 unecessary. 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.

There are some similarities between 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 unecessary 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.

Unfortunately we have this frequently when implementing the Scrum Framework, especially win large organizations. It happens when we have stakeholders to the team who don't observe clear roles and boundaries and are behaving in ways that slow the team down. It happens when teams are not trusted, or when people are micromanaging.  It happens when Agile leaders don't really know how to lead in an agile environment.

Frequently I will find well-intentioned indivuals directly involved 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, request updates or reports, and generally create distractions and unnecessary work. 

Examples of these interested parties could include the PMO, supporting business functions, and department managers or functional managers like training or quality assurance. Additional stakeholders can be 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 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. 

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

In Scrum, getting people into the right seats is straightforward because there are just three clear 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 Dev Team. The Dev Team is dedicated 100% to the team goals and they self-organize and decide HOW to complete the work as quickly and efficiently as possible

These roles provide guidance on what to do with those interested parties and stakeholders that don't have clear roles:

If these individuals want to tell the team What to work on:

That is the role of the Product Owner. There can be only one PO for the team. The PO priorities are reflected in the prioritized back log. The indivuals that want to tell the team what to work on should collaborate with the Product Owner. The priorities should be clear in the backlog and the Dev Team should have only one master to serve.

If the indivuals want to direct team members or interrupt them or pester them for status:

Teams should not be interrupted and individual team members should not be directed to work on other things. The team should not be asked for status or interrupted midsprint. The team should be able to focus during the sprint.

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

If the individuals want to tell the team How to work:

That is the role of the Dev Team. Dev teams don't need others telling them how to work, they are self-organizing. So if someone wants to tell the team how to work, they can only do that by joining the team. They need to be full-time committed to the team and share the team's goals. They get to vote then, but they also are responsible for helping the team go fast. To the extent that these stakeholders can become value workers by directly rowing the boat, the entire organization will go faster.

Are your Scrum Teams going slow because there are extraneous people being dragged along that are not producing value? Can you make life better for your team by getting the right people on the boat, and everyone else off the boat?

About Anthony Mersino

Anthony is passionate about helping technology teams THRIVE and organizations TRANSFORM.  He loves partnering with organizations to help teams with Agile thinking and the Scrum Framework.  He teaches Agile and Scrum as well as the cultural elements that are necessary for an organization to gain true business agility. Anthony has  authored numerous articles and two books: Agile Project Management, and Emotional Intelligence for Project Managers.