# The Small Teams Manifesto

Author: Jason Gorman
Published: 2015-08-17
Original URL: http://codemanship.co.uk/parlezuml/blog/?postid=1322

So.... grrr.... arrrgh... etc.

Another week, another software project set up to fail right from the 
start.

What angers me most is that the key factors we know can severely damage 
our chances of succeeding in delivering software of value are well 
understood.

The main one is size: big projects usually fail.

We know pretty empirically that the development effort required to 
deliver software grows exponentially as the software grows. If it takes 
a team 2 hours to deliver 10 lines of working software, it might take 
them 4 hours to deliver 20 lines of working software, and 8 hours to 
deliver 30 lines, and so on.

There's no economy of scale in software development, and we know for a 
fact that throwing more bodies at the problem just makes things worse. 
A team of 2 might deliver it in six months. A team of 10 might take a 
year, because so much of their time will be taken up by being in a team 
of 10.

The evidence strongly suggests that the probability of project failure 
grows rapidly as project size increases, and that projects costing more 
than $1 million are almost certain to run into severe difficulties.

In an evidence-loaded article from 1997 called Less Is More, Steve 
McConnell neatly sums it all up. For very good reasons, backed up with 
very good evidence, we should seek to keep projects as small as 
possible.

Not only does that tend to give us exponentially more software for the 
same price, but it also tends to give us better, more reliable 
software, too.

But small teams have other big advantages over large teams; not least 
is their ability to interact more effectively with the customer and/or 
end users. Two developers can have a close working relationship with a 
customer. Four will find it harder to get time with him or her. Ten 
developers will inevitably end with someone having that working 
relationship and then becoming a bottleneck within the team, because 
they're just a proxy customer - seen it so many times.

A close working relationship with our customers is routinely cited as 
the biggest factor in software development success. The more people 
competing for the customer's time, the less time everyone gets with the 
customer. Imagine an XP team picking up user stories at the beginning 
of an iteration; if there's only one or two pairs of developers, they 
can luxuriate in time spent with the customer agreeing acceptance 
tests. If there are a dozen pairs, then the customer has to ration that 
time quite harshly, and pairs walk away with a less complete 
understanding of what they're being asked to build (or have to wait a 
day or two to get that understanding.)

Another really good reason why small teams tend to be better is that 
small teams are easier to build. Finding one good software developer 
takes time. Finding a dozen is a full-time job for several months. I 
know, I've tried and I've watched many others try.

So, if you want more reliable software designed with a close 
collaboration with the customer at an exponentially cheaper price (and 
quite possibly in less time, too), you go with small teams. Right?

So why do so many managers still opt for BIG projects staffed by BIG 
teams?

I suspect the reasons are largely commercial. First of all, you don't 
see many managers boasting about how small their last project was, and 
it's the trend that the more people you have reporting to you, the more 
you get paid. Managers are incentivised to go big, even though it goes 
against their employer's interests.

Also, a lot of software development is outsourced these days, and 
there's in obvious incentive for the sales people running those 
accounts to go as big as possible for as long as possible. Hence 
massively overstaffed Waterfall projects are still the norm in the 
outsourcing sector - even when they call it "Agile". (All sorts of 
euphemisms like "enterprise Agile", "scaling up Agile" etc etc, which 
we tend to see in this sector more often.)

So there are people who do very well by perpetuating the myth of an 
economy of scale in software development.

But in the meantime, eye-popping amounts of time and money are being 
wasted on projects that have the proverbial snowball's chance in hell 
of delivering real value. I suspect it's so much money - tens of 
billions of pounds a year in Britain alone, I'd wager - and so much 
time wasted that it's creating a drag effect on the economy we're 
supposed to be serving.

Which is why I believe - even though, like many developers, I might 
have a vested interest in perpetuating The Mythical Man-Month - it's 
got to stop.

I'm pledging myself to a sort of Small Team Manifesto, that goes 
something like this:

We, the undersigned, believe that software teams should be small, 
highly skilled and working closely with customers

Yep. That's it. Just that.

I will use the hashtag #smallteams whenever I mention it on social 
media, and I will be looking to create a sort of "Small Teams avatar" 
to use on my online profiles to remind me, and others, that I believe 
software development teams should be small, highly-skilled and working 
closely with customers.

You, of course, can join in if you wish. Together, we can beat BIG 
teams!