Increase Your Velocity By Adding More People?

Many people find that often one of the most misunderstood ways to increase productivity is to just throw more people at a problem. I mean, in some circumstances it does make sense and in many circumstances I’m sure that it sure does work. But what about Agile teams? If we have a tight deadline and need to push a product out the door, does adding more cooks in the kitchen make sense?

Mark Needham tells us “No.” There aren’t as many productive gains by doing this, especially in regards to communication. What are his reasons?

Reasons larger teams can pose less productivity:

  1. Daily Scrums or standups take much longer – Since there are more voices, it takes longer to get through everyone and harder to put the all the pieces of information together.
  2. Technical consensus is harder to reach – Since there are more voices, decisions around technical directions and issues can take longer and lead to more disagreement.
  3. Larger teams means less direct communication – Since there are more people (Mark says more than 12), then sitting co-located within direct talking distance is impossible. There will inevitably be less direct communication and collaboration.

Mark’s resolutions to this if your team is large:

  1. Daily standups – Reduce standup to not include discussions. Take them offline.
  2. Technical decisions – Only include a smaller amount of people to technical discussions (Scrum of Scrums?)
  3. Co-location – Find a co-location method that fits your enterprise. Look for ways to break down distance between key developers or product owners.

“Adding people to a team may increase the velocity but it’s unlikely to lead to an improvement… it might make more sense to take a bit longer building the product or application rather than aiming at a strict time deadline with more people.” – Mark Needham


5 Replies to “Increase Your Velocity By Adding More People?”

  1. Great points Scout. Even if a large team is required, I find it’s always good to start small, lay down some architecture, and then add people incrementally over the life time of the project.

    That way you can keep the culture and best practices up, not have to lower the bar, and absorb the new team members without taking too big a hit.

    Good stuff. Keep em coming.

    1. Thanks man! We love your stuff too. Starting small is great. Startups are great places for solid foundational Agile elements to be employed. Unfortunately, the big behemoth organizations can’t move as quickly.

Leave a Reply