Academic Studies Into Benefits of Team Work in Software Development

Question

Hi All

I need to find some good statistics from reputable sources on the benefits of software developers working in a team.

We use Scrum - so anything linked to this in particular would be really beneficial but not essential.

I have 5 developers of differing skill levels and I feel that they need to work as a team. However, if my boss had his way they would all have a large single project each (or worse, multiple projects on the go at the same time) each. It's a constant battle.

I am looking to put facts in front of him that are difficult or impossible to argue with. Things like 'working as a team increases productivity by xx% would be perfect. Increases morale by xx%, reduces bugs by xx% - you get the idea.

There are some posts already here that may help and I will go through them but I don't think they're exactly what I'm looking for.

Some may feel they want to side with my boss. In the interests of good discussion this is OK. However, I know the dynamics within my team and Organization and am convinced that team working is the best route for us. I'm unlikely to change my mind :)

Any help would really be appreciated - before my guys walk out on me :)

Answer 1

What do you mean by working "as a team"? Aren't you battling over semantics?

Even if everybody had their own project, you would want to avoid duplicating each other's functionality. You should build your own library of repeatedly used base functions etc.

If everybody worked as a team, you'd still have to assign invididual tasks to each programmer.

Answer 2

I have 5 developers of differing skill levels and I feel that they need to work as a team.

On what ground do you have that feeling?

There is no point in enforcing team work for the sake of team work. If there are really different projects or components, they could be developed by individual developers as well.

Things like 'working as a team increases productivity by xx% would be perfect. Increases morale by xx%, reduces bugs by xx% - you get the idea.

There are no absolute benefits of team work over individual work. Sometimes team work only interferes with effective work. You lose time arguing about stupid things (like argument names) instead of being productive.

Team work may be or may not be of benefit. You need to tell us more about the project you have at hand, its organization and what kinds of tasks/subprojects your colleagues are being assigned.

I wrote my considerations on the team work in my blog article. Though not exactly to help strengthen your team work position, the story can give you some thoughts.

Working in teams can destroy your learning abilities

Answer 3

I seem to remember "The Mythical Man Month" mentioning that the size of an optimally efficient team is one - because inter-member communication is essentially zero. However, once software reaches a certain size, you're going to make a tradeoff of efficiency for time - for example, it may take one person 5 years to develop a system, but a team of 5 can do it in 2 years (hypothetically). However, communication issues, design issues, etc. means that adding team members doesn't scale directly - you can't take a team of 1780 developers and develop the system in one day.

So - I'm not sure that productivity is the metric that you're looking for - adding team members lowers individual productivity as a tradeoff for less calendar time.

Morale is a tricky area too, and depends on the individual developers - some people work better solo, some work better in teams - and sometimes the mix of team members negatively affects morale.

"Reduces bugs" might hold some traction, though - depending on the development practices. I know that I've seen studies showing that certain classes of bugs are less likely in pair programming - but if each person is working in their own section of code on the same project this isn't likely to have the same benefit. You could have code reviews too, but this could be done in your current "one developer per project" style too.

Answer 4

As The Mythical Man Month discusses, time lost on internal team communication grows with the team. If the team lead assigns discrete pieces of work to each developer, then this relationship is (ideally) linear - each developer might spend 10% of his time and use up 10% of the lead's time.

If you 'work as a close-knit team', then each developer is communicating with all the others. That means the communication time rises geometrically, which is scary.

Also, consider Joel's articles on 'task switching' where he claims that developers need to be freed from distractions in order to concentrate intensely and get 'in the zone' of high productivity. If your devs have to keep talking to each other they are not going to be able to focus on their own work as well.

It's good each dev knows in general what direction the project is going, who is working on what, etc. It's also good to maybe have people do code reviews. But that can all be done in a more linear fashion in my opinion, without all this 'teamwork' stuff. Reviewing code and testing functionality can just be another task assigned by you.

Answer 5

I am pessimistic that you will meet your goal of confronting your "team" with facts that cannot be contradicted. Empirical studies have been carried out, but people are complex and whimsical. Even if my experiment shows that teamwork has worked wonders, that doesn't mean that the results will translate into your people. The specific character and peculiarities of each individual has a huge influence on the results; so big, that it dominates the outcome.

Hence the old saying of the agile disbeliever: "given a team composed of brilliant developers, who wants an agile method? who wants a method at all?" :p

Answer 6

Maybe check the references that Scrum itself uses:

• (IBM Surgical Team) F. P. Brooks, The Mythical Man Month: Essays on Software Engineering: Addison-Wesley, 1995.
• Takeuchi and Nonaka. The New New Product Development Game. Harvard Business Review, 1986
• J. O. Coplien, "Borland Software Craftsmanship: A New Look at Process, Quality and Productivity," in 5th Annual Borland International Conference, Orlando, FL, 1994.

Quoting The Scrum Papers about the Quattro Pro project:

We were prodded into setting up the first Scrum meeting after reading James Coplien's paper on Borland's development of Quattro Pro for Windows [2]. The Quattro team delivered one million lines of C++ code in 31 months, with a four person staff growing to eight people later in the project. This was about a thousand lines of deliverable code per person per week, probably the most productive project ever documented. The team attained this level of productivity by intensive interaction in daily meetings with project management, product management, developers, documenters, and quality assurance staff.

From the same document:

One of the motivating factors in creating Scrum was the Borland Quattro Pro project documented in detail by James Coplien when he was at ATT Bell Labs [2]. Each developer on this project generated 1000 lines of production C++ code every week for three years. In comparison, productivity on the recent Microsoft Vista project was 1000 lines of code per developer per year. The Borland Quattro Project was 52 times as productive as the Microsoft Vista project measured by lines of code.

And another source (added for the links and the defect rate):

One of the most widely regarded case studies of a successful roll out and productivity assessment for a software project, was Borland Quattro Pro that was using Scrum before scrum become a household name. Apparently, the Borland team was able to produce 1000 lines of C++ code per week with a less than 3% defect rate.

...

More links:

• http://jeffsutherland.com/scrum/2007/07/origins-of-scrum.html
• http://www.donkim.info/2007/05/japanese-orgiins-of-scrum.html
• http://www.docstoc.com/docs/15598/LESSONS-LEARNED-FROM-THE-FIRST-SCRUM

---

More on productivity and team size (I know you asked about studies on team work but, well, Scrum implies close collaboration, as stated in its name):

• Jones, Capers. Applied Software Measurement, Second Edition. McGraw Hill, 1996.
• Industrial Strength Software: Effective Management Using Measurement by Lawrence H. Putnam and Ware Myers (1997)
• Rubin, Howard (Ed.) A Metrics View of Software Engineering Performance Across Industries. IT Metrics Strategies V:9:3, September 1999.

Sources:

• http://jeffsutherland.com/2003/02/scrum-keep-team-size-under-7.html
• http://www.infoq.com/news/2009/04/agile-optimal-team-size