Five Forebodes Failure

First shalt thou take out the Holy Pin, then shalt thou count to three, no more, no less. Three shall be the number thou shalt count, and the number of the counting shall be three. Four shalt thou not count, neither count thou two, excepting that thou then proceed to three. Five is right out. Once the number three, being the third number, be reached, then lobbest thou thy Holy Hand Grenade of Antioch towards thy foe, who being naughty in My sight, shall snuff it.
— from Monty Python and the Holy Grail

There are lots of reasons that embedded software projects fail. Informal development processes, lack of requirements (or poor requirements), coding errors, undefined software architecture, developer or engineer turnover, and so on. There is, however, one anecdotal but surprisingly consistent finding that makes us scratch our heads; developer teams adding the 5th primary contributor often have spectacular project failures.

One thing that we have noticed from both design reviews across teams in a variety of industries as well as in classroom activities: when you have a team of four on a software development project and add one more member… the project tends to fall apart. Three developers on a specific project works fine. Usually the fourth person added to a team helps, although potentially with decreased productivity contribution. (For student teams our data shows that the fourth person doesn’t add any extra productivity, but they’re still learning and only have a few hours per week to spend on projects for a particular class.) However, once a team reaches five individuals, the fifth person, no matter their qualifications or expertise, usually contributes negative productivity, and often causes a project failure.

You would think that adding a fifth member to a team results in at least a marginal productivity increase, and perhaps that happens in some cases. But time after time, we’ve seen that adding a fifth member to the team not only doesn’t add any productivity, but it is often counterproductive.

Why does one more team member often make such a big (bad) difference?

There is no one-size-fits-all answer, but we do have one hypothesis: most teams that add person #5 have weak or excessively informal processes, and are adding that person expecting to get linear productivity improvement. When you have 3 or 4 developers, you can often get away with a weak processes, especially if you have a stable team and work on a single product family over a period of years. 3 or 4 developers in a shared office area can form a tight group and coordination overhead is low enough to keep everyone on the same page. However, if you have a project that gets so complex that 5 developers need to coordinate on that same project, you have reached a tipping point. Informal processes and communication break down, and you often have a spectacular process failure.

Typically, teams that have a more formal, rigorous development process are less likely to suffer from the “Five Forebodes Failure” phenomenon, because they’re already spending the equivalent of most or all of that 5th person of effort on explicit coordination and software development process activities. Often the team leader is spending perhaps 10 hours per week on pure process support. (By the time you get to a team of 20 you’ll need a full time software process and SQA person.) Teams of six or more working on a project often have a more formalized process, or have been very clever at breaking a project down into numerous almost-completely independent components that don’t require much coordination.

All of this isn’t to say that adding a fifth team member to a project immediately means that you’re going to fail. But it does indicate that a good heuristic would be to tread carefully when you get to a team size of 4-6 developers, and expect to have to add more formal processes, especially if your current development process is informal.

We’re willing to bet you’re not keen on spending a whole 5th person on process. (If you want to add person #5, you probably are doing that so they can write code.) The key to success with developer #5 is not to go crazy with overly-burdensome paperwork, but rather to make sure you have some key process steps formalized to keep things under control.

We have a one-day on-site seminar that can teach you the top ways to improve software quality and process quality in a way that provides just enough process support to keep things from getting crazy while remaining productive. Contact us for more information.


Koopman, 2010: "Risk Areas In Embedded Software Industry Projects" 

100 43RD ST.

Copyright 2015, Edge Case Research, LLC. All rights reserved.