Why Should I Insist That Team Members Be Full-Time?

Most Agile experts recommend dedicating people full-time to their Agile team. Developers, testers, and other professionals should only deal with items in their team’s work stream — the backlog. This minimizes the cost of switching between unrelated activities and enables the team members to concentrate on their work.

Management usually frowns on this advice, for two reasons:

1. They want to maximize people’s output. If someone is only needed 80% of the time on one project, what happens with the rest of his time?
2. The workload usually includes more than net new development. It also includes production support, some training, fixing older versions, roadmap planning, or merely smaller one-off projects. These activities are often managed separately and, to staff them, individuals are “sliced and diced.”

Many individual contributors also embrace this thinking. They consider it reasonable that they be 60% on project A, 25% on project B, and 15% on project C.
Both management and line workers are well aware that, in most software development efforts, the largest cost item is the team’s pay. So, naturally, they follow the factory logic of maximizing utilization, which goes hand in hand with referring to people as “resources.” Many of them don’t realize the cost of context switching and don’t know that utilization is not the right measure to look at. The useful indicator isn’t that people are kept busy; it’s their contribution to the company’s overall productivity and business.

At one standup, I heard a developer report to the ScrumMaster, “I just finished that task I’m working on, so I’m a free resource now.”

Consider Alex, a highly skilled database analyst. He is only needed half the time on the Blue Team, so he spends the other half helping the Green Team and the Red Team.

This approach implicitly assumes that the return on Alex’s time — his usefulness or productivity — is proportional to the time he spends on projects. After all, he’s competent, he’s motivated, and he wouldn’t waste company time. So, every minute he’s on a task, he’s being useful. Makes sense, right?

Sure, if Alex were a computer.

Because Alex is human, though, he will not be all that productive, and neither will his teammates. Here are just four reasons:

1. When Alex switches from the Green Team’s project to the Red Team’s, he needs time to catch up on Red’s developments. This isn’t like synchronizing a smartphone; it takes time and often involves asking people questions, thus lowering their output.
2. Inevitably, his bonds with the Blue Team members (and the Red ones, and the Green ones) are weaker. He’s simply not around enough, and when he is, he’s this “expert” they should all listen to. This often translates into reduced collaboration, trust, and knowledge sharing.
3. Alex has no slack time in which to come up with new ideas or simplifications. He lacks the bandwidth to consider that perhaps they should be building other product features.
4. The Blue Team needs him for 50% on average. What happens the week he’s needed for 80%? Either he becomes the bottleneck and Blue suffers, or he spends that time with Blue and then Red and Green both suffer. A flurry of management activity ensues to coordinate his time, none of which gets deducted from anyone’s “productivity.”

What about the costs you see only much later? A few months of this, and Alex burns out, or asks to be reassigned, or even leaves the company.

What can you do? Stop the “maximizing utilization” madness. Even your computer’s operating system avoids 100% CPU utilization (and that’s a machine!). Serve your team by fighting to have full-time members on it. Keep pointing out that what matters is overall team throughput — a steady stream of value — not the productivity of individual Alexes. If you absolutely must share certain people, then fight to share them with only one other team and make sure they are being useful and effective when they are on your project. You can rotate your specialists among the teams every few months for increased knowledge sharing, solution consistency, and personal satisfaction.

About the book and the author

The excerpt above is from the book The Human Side of Agile: How to Help Your Team Deliver which will be available September the 12th. With this book, Gil Broza has created a practical, universal guide to navigating the least manageable, understood, and appreciated asset in an Agile environment: its human side. Even if your customers are reasonably happy and your developers seem to be doing okay, you know your team is capable of more: delivering great products and staying ahead of ever-changing demands. You want to feel good about using Agile and to create the conditions for great results, but the skills you honed in traditional environments don’t always apply to the role of Agile team leader. The Human Side of Agile fills this gap, guiding you to:

• Establish yourself as a confident and capable leader who adds value
• Build and lead an engaged team that can handle almost any challenge
• Cultivate collaboration and a continuous improvement mind-set
• Reap the full benefits of Agile in the real world with real people

Don’t forget to leave your comments below.