August 17, 2015

...Learn TDD with Codemanship

The Small Teams Manifesto

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!




Posted 2 years, 5 months ago on August 17, 2015