Are Dedicated Teams Required for Agile or Scrum?

Are dedicated teams required for Agile or Scrum? This is not a trick question – it is actually a genuine question that I posed in a LinkedIn Poll some time ago. And the results were somewhat surprising.

It seems like we are nearly evenly divided on this question of dedicated teams for agile. There were 46% who said NO they are not required and 54% said yes, dedicated teams are required for agile.

Let’s start there! How could a group of 120 people, working from the same set of documents, be nearly evenly split about what is required for Agile and Scrum? Nothing in the Agile Values or Principles says that you need dedicated teams for agile. Is it implied? Maybe. But not required.

Nor does the Scrum Guide say you need to use dedicated teams for agile. According to the Annual State of Agile Report, Scrum is used by about 80% of the people using agile. Nowhere in the Scrum Guide does it say teams should be dedicated.

So where do people get the idea that dedicated teams are required?

Why Dedicated Teams for Agile and Scrum Make Sense

Whether or not they are “required”, I feel very strongly that team members should be dedicated, that is, each person should be on just one team. Here are some reasons myself and others have given for dedicated teams:

• Individuals who are on multiple teams are multi-tasking and context switching which creates waste, reduces predictability and undermines team morale
• Individuals who are on multiple teams don’t share the same level of commitment to objectives and outcomes as others
• Organization working to capacity

There are some edge cases where having one person on one team may not make sense. These are primarily in areas where you have highly specialized skills. Sometimes people with UX, Architecture, Security and other specialized skills need to be shared. It should be the exception though, not the rule.

What is interesting about those edge cases is this – how should we keep that person busy when their special skills aren’t required on the team? Is resource utilization what we are concerned about or performance? Would you have the field goal kicker in the Superbowl running laps around the stadium during the times they aren’t needed just to stay busy? Would you have a closer in baseball doing jumping jacks and pushups the first 8 innings? Of course not.

Spreading People Across Multiple Teams Reduces Capacity and Throughput

That’s right, creating more teams from the same number of people reduces your capacity for work. 

But most manager and leaders don’t understand or believe this. And so they continue to say yes to new work and they spin up new teams to that work. With the same number of people.

We simply don’t have enough people to have dedicated teams for agile is what they tell me. That is complete batshit crazy as we can show with a simple thought experiment.

There are two main factors involved here. The first is the switching cost for a developer to shift focus from one project or activity to another. And the second is the cost of using the Scrum Framework on each initiative.

Let’s start with the cost of context switching. In his 1991 book Software Quality Management; Systems thinking, Weinberg posited that when people are required to do multiple things at once, they incur a cost of switching their attention between those activities. That cost turns out to be about 20% for someone switching between two tasks. The cost of switching goes to 40% for someone straddling three activities, with each activity getting about 20% of their bandwidth. You can see this visually below.

The work by Gerald Weinberg has been supported and improved on by more recent work by Barry Boehm and other researchers at the University of Souther California. Their 2017 study of software developer productivity showed the cost of context switching as more of a constant 17%, regardless of the number of projects underway. Let’s use that lower estimate in the following thought experiment.

Let’s say you have a small organization of 60 people who are workers and that you are using the Scrum Framework. The 60 people are the developers on your Scrum Teams. My recommendation would be to organize them into 10 teams with 6 people dedicated to each team. Let’s look at what would happen if you had 10 dedicated teams, or 20 or 30 non-dedicated teams.

10 Dedicated Agile Teams

Those 10 teams could be aligned to 10 backlogs and the backlogs could contain work for multiple products, initiatives or customer needs (I am intentionally avoiding the word project since working in projects tends to gum everything up). The capacity of that group to get work done is 60 people X 40 hours a week or 2,400 hours per week.

In the 10 team scenario, each person spends about 15% of their time in Scrum meetings and the other 85% is available to be used for work on the sprint. In a 40-hour work week, a 2-week sprint would have 60 X 80 or 4,800 total hours available. Remove the 15% of the time for the various Scrum events in the sprint and you get 4,080 hours that those 60 people could apply to sprint work. (I personally consider the Scrum events as working time but not everyone sees the time as productive.)

20 Teams that are Not Dedicated

In the second scenario, imagine that you created 20 teams with 6 members each. In this second scenario, each team member is on two teams and a total of 20 backlogs are used to contain work from multiple products or customers.

In this scenario, each person spends 15% of their time in the meetings for each of their Scrum teams or 30% total. Also, they incur a switching cost of 17% to move from one task to another. Each person starts with 4,800 total hours available in a 2-week sprint but now you need to reduce it by 30% for the Scrum meetings and 17% for switching costs or 47% of their capacity. This leaves just 2,544 hours of their capacity available for task time.

That means by creating double the number of teams and assigning people to two teams, you have reduced your effective working hours from 4,080 to 2,544. That is a reduction of 37%. You have effectively decreased your bandwidth by 1/3!

30 Teams that are Not Dedicated

A third scenario is 30 teams with 6 members each. Each team member is on 3 teams and there are a total of 30 backlogs of work. This is even worse from a productivity standpoint as I hope you can imagine now. Each person spends 17% of their time in context switching  and another 45% of their time in Scrum meetings. The actual working time for your 60 people has decreased to 1,824 hours, a decrease of 55%.

Is it any wonder that the people working on multiple teams claim that they don’t find any time during the day to get work done? “I was in meetings all day” they tell me. Who are we kidding when we say we don’t have enough people to have dedicated teams! Take a look at the comparison below.

And in this simple example, we are limiting each person to one, two or three teams. What I hear from my students is that they are frequently assigned to 4 or even 5 teams! Obviously, that will make things worse, not better.

Spreading People is a Lack of Management Priorities

Is the lack of dedicated teams a symptom of a bigger issue? John Clifford weighed in on the LinkedIn poll with a great point about not having dedicated teams for agile. He pointed out that the lack of dedicated teams and the resulting excessive work in process is because management is not prioritizing.

The fundamental reason for excessive work in-process (overburdening) is the refusal for management to step up and make the hard decisions.

— John Clifford, posted in LinkedIn

So it seems that managers are not making hard choices about the use of scarce resources (people). Rather than recognizing that they have a fixed capacity for development and deciding how best to use it, they abdicate and force individuals to make the decision. Which has the exact opposite effect!

At the portfolio level, you are simply saying yes to too many things. And as a result, they are all moving at a snail’s pace with very little delivery of business value. You would get more done by adopting the Kanban slogan, “stop starting and start finishing”.

So why don’t managers and leaders make those tough decisions which result in lower work in process? John Cutler recently posted the following Tweet in hopes that it would reduce the confusion people have about why they should limit work in process:

not an original thought, but “limiting WIP” confuses people it is actually

• increase focus
• limit multi-tasking
• stop starting, start finishing
• collaborate more
• try to keep less things in memory
• reduce planning inventories
• increase flow
• learn faster
• pivot earlier

— John Cutler, Feb 26 2022

This is very helpful. Though I have to wonder if there is anyone in leadership who is actually confused about this practice and the benefits?

Dedicated Teams for Agile Conflict with Old-Timey Project Management Techniques

I wonder if part of the reasons for this ignorance around multi-tasking and overburden is a direct result of the planning techniques that were prevalent when planning traditional/waterfall projects; resource management and the critical path.

The resource management approach popular 20 or 30 years ago was to have an elaborate set of spreadsheets where everyone was assigned to 100% or more of their capacity. The focus was on taking the 100% bandwidth of a person and spreading it across multiple projects. The main focus was on maximizing resource utilization. It assumed that the hours worked by an individual were completely fungible and there were no switching costs.

Critical path says that the time it takes to get things done is a function of the shortest path through all the sequential activities. Prior to agile and Scrum, project managers like myself would create these elaborate Gantt charts in MS Project. The resulting schedule predicted when things would be done based on the critical path. These Gantt charts showed how work was handed off from one specialist to another in a seamless way. It also showed resources being immediately available to work on things when they were needed such as to complete a 2 hour code review on a Thursday afternoon. These models were beautiful and project managers like myself would spend hours finessing them and getting them just right.

Unfortunately, the models did not represent the real world And the main reasons were 1) tasks never took the exact amount of time that was forecast and 2) people were never available exactly when needed. As a result, managing a project like this was really more about managing the plan you created in MS project and trying to make it look like the reality that already happened.

It was largely an exercise in futility. We had to trick the tool into reflecting the past that had already happened in hopes of predicting the future. We would leverage all the tricks MS Project offered, like playing around with task dependency relationships, inserting dummy tasks, and creating intentional delays.

God forbid you hit the button for resource leveling which would attempt to make a realistic schedule based on the “resources” or people you had working on it. That would extend your project timeline to 1.5 to 2 X what it was. While it probably made for a more realistic schedule, it was often unacceptable to managers and leaders.

Good PMs would combine all that MS Project gymnastics with resource management dirty tricks. If your shared resource wasn’t working on your task when you needed them, you went and stood over them or yelled to get what you needed. People would comply if you stood over them. Or they might cry for help – “just tell me what to work on”.

What a complete waste of time.

The way out is to stop pretending that people are completely fungible and can be spread over multiple initiatives. Or that they are available exactly when needed. Stop planning by individual person and start planning by team. Stop sending project managers around to act like glorified babysitters making sure workers do their tasks. Put each person on one team and then let that team self-manage to get the work done.

By the way, if you are still clinging to those old-timey project management approaches for technology initiatives, perhaps it is time to invest in new ways. The Standish Group reported in 2020 that based on their studies, teams with no project manager fared better than those with one.

Bottom Line – Do You Need Dedicated Teams for Agile?

I think it only makes sense to have dedicated teams for agile, even if they are not explicitly called for in the Agile Values and Principles or the Scrum Framework. Spreading people around only causes more work in process, context-switching and suboptimal use of resources. Make some tough decisions as leaders as to what you can do with the people you have.

Thanks to everyone that weighed in on the LinkedIn discussion.

[See my related post on Biggest Mistake Organizations Make, Avoid Assigning People to Multiple Teams and PMs Fail to Help]