“When is it going to be ready?”, “How long will it take?”. As someone involved in software delivery, you are probably asked these questions or something like them, every day.
However you choose to answer the question, you’ve probably taken into consideration the capacity of your team. For most people, capacity is simply a case of counting the number of people in the team, and making an assessment of how much work those people can get through in a certain time period. In order to understand how to increase team capacity, the temptation is to think in the same terms. In doing so, you are only able to draw one conclusion: to increase team capacity you have to add more people.
A number of books have been written on the dangers of thinking in this way, most notably The Mythical Man-Month. These books focus on dispelling the myth that adding people to a project has an immediate positive effect on team throughput. Thinking longer term, if throwing people at the problem isn’t always the right thing to do, or we aren’t able to take on the additional cost of doing so, how do we increase team capacity?
Capacity isn’t simply about the number of people doing the job, it’s also about how they go about it. Their capability. If we put a focus on work management: limiting work in progress and reducing batch size, and couple it with engineering practices such as continuous integration and pair programming, we begin to increase a teams capability. This capability manifests itself as a reduction in waste as fewer defects are injected and knowledge is shared, and a reduction in lead time as deployment pipelines are automated alongside some of a teams testing effort. Not only does our software reach our customers more quickly, it’s of a higher quality, resulting in less rework. That leaves the team more time to focus on the new features that add value for our customer.
Increasing capacity isn’t simply about adding more people to the team. It’s also about increasing capability, by optimising the way in which the team produces software. In this way we can keep teams smaller and more focussed, helping to control our costs.
Good post James. The more I’m involved in software development, the more I realise how many things are completely counterintuitive.
Who would’ve thought that two people working on one machine and code base could be quicker than two people working separately. Who would think that adding more people may actually slow things down or the best way to ensure quality isn’t to put a single person in charge of quality.
I also quote (or misquote probably) Alan Kelly, who says, “there’s no such thing as economies of scale in software development”.