Individual vs. Team Productivity

by Krishna on October 4, 2007

Many people define “productivity” as how much you can accomplish in a given unit of time. Using this definition as the basis for higher productivity can sometimes be counter-productive.

Consider the following examples:

  1. As a product manager, you can start writing up many new product features for your development team. But, if you do not have enough resources, all you have done is create a huge backlog of work.
  2. As a tester, you can find many more bugs per hour than the average tester. But, this has just created more work for the project manager and the developers.
  3. As a developer, you complete and check in more features than expected. Now the build is delayed because there is more work for regression and integration testing.

The above examples all relate to problems caused a team setting by a highly productive member of the team.

In a team, every person’s work is the trigger for another person to start their work. There is a flow in the system. For example, we may have a simple flow like:

Customer -> Business Analyst -> Developer -> Tester -> Customer

There may be backward flows, where a tester reports bugs back and creates work for the developer, or the business analyst requests more information from the customer. The point I want to make is that when each person in a team produces something, they create work for other persons or teams. This is usually good. If there is a reasonable backlog for every person, they can continue working towards producing the end result.

However, if you are a person in the chain and you exhibit very high productivity, you have just created a bunch of problems. First, a huge backlog overwhelms the downstream employee. You or they must now spend time prioritizing the list of items in the backlog. In the absence of prioritization, the downstream employee will work on the wrong things, causing delays for everyone else too.

For example, let us consider a developer suddenly faced with a tester finding several bugs a day, albeit many obscure and minor ones. Since the bug count looks very nasty, he will be tempted to reduce it by knocking off the easier, less time-consuming bugs and delay work on new features. If the tester continues this mode of operation, very soon, you will have a project go totally off the rails.

This issue is, of course, one of the more important concepts in lean thinking. In a manufacturing setting, a highly productive team (or machine) can create huge inventories that consume space and money. In the above example, it may actually be more useful at this point to have the tester report only critical bugs (and sit idle, if need be) while the developer catches up. It may even be more profitable because the product can be shipped sooner and more sales gained.

Let us reverse the situation. Say, a developer produces more than a tester can test within a period of time. This is the case with projects in many smaller companies, where the tester-to-developer ratio is low and the pressure to ship is high. Here, the higher productivity results in a lower quality being shipped. The tester practically doesn’t have time to test everything and makes effort allocation choices that may sometimes be wrong.

It is necessary to establish the right rhythm of work within a team. In this way, each person produces just enough to keep the next person busy and no more. This may mean idle time for some people at times. Thus, individual productivity may go down. But the overall team will be more efficient in meeting the objectives of the project in terms of timely delivery and quality.

So what can you personally do? I think you can look at the work you do in terms of the people you affect and start asking yourself questions like:

  • If you are doing a task (like writing an email or a document), is it going to create more work for others?
  • And if so, is it filling a vacuum or is it adding to an already long list of tasks?
  • What effect will your work have on their existing tasks? Beware: if you are the boss, your new request, however silly, will immediate rise to the top, de-prioritizing important tasks.

If you are highly efficient, you cannot help producing more. What you can do is produce only the necessary work product within a shorter time. And then, instead of working on the same thing, you should move onto tasks that do not affect others. For example, a developer or tester can spend time learning new skills while they are idle and waiting for others.

{ 7 comments }

Adrian October 6, 2007 at 11:28 pm

Hi Krishna,

This is a great post!

This topic is very relevant to software development. I manage a team of business systems analysts and apply some of these principles when determining resource allocations and which tasks the team should work on next.

Having one team finish lots of tasks is not the end goal. Each project needs to identify the ultimate measurement for “throughput”!

If the developer deploys lots of code but that code is not needed by the end user, then it has no value.

For most software projects “throughput” should be measured in terms of the amount of needed functionality which has been successfully been deployed to the end user.

A great book on this topic is “The Goal” by Eliyahu M. Goldratt.

Best regards,
Adrian
Publisher, ModernAnalyst.com
Community for Business Systems Analysts

Krishna Kumar October 8, 2007 at 10:48 am

Thanks for your comment, Adrian

I agree with your thoughts. Many times, software projects build a lot of functionality that no one uses. It is lot more work, but the benefit is zero.

Susan Kuchinskas December 14, 2007 at 5:36 pm

I thought this was really insightful, and applicable to many jobs besides software development.

Krish December 15, 2007 at 9:48 am

Thanks for your comments, Susan

MGoBlue93 March 15, 2009 at 9:53 pm

I'm sorry to be so blunt but this is the most asinine article I've ever read.

1. If you have developers writing code for features that aren't going to be used, the bottlenecks aren't with the developers creating a backlog of code, but with your system engineers and project managers who have failed to analyze the requirements properly. Making excuses otherwise is just throwing the baby out with the bath water.

2. A developer, or a tester, should never be evaluating anything which is not traced directly to a specific requirement. Anything else is just waste, a deviation from the spec, and is a hard cost with comes directly from the project's budget.

3. "Customer -> Business Analyst -> Developer -> Tester -> Customer." Way to go, you just modeled waterfall development or something out of Yourdon's textbooks circa 1980. I've seen this so many times, organizations say they want to embrace scrum/agile/lean etc., and they set up their Software Development Plan that way… and then management crams waterfall down the technical teams' throats. Sorry, but while it is okay to tailor development frameworks to your organization's needs, iterative development and waterfall development are generally NOT compatible — that's why you have backlogs and productivity problems. Are you working on a government project or something???

4. Selected quotes from the article:

"For example, let us consider a developer suddenly faced with a tester finding several bugs a day" — You have a bug quota??? I've never heard of tester faced with such a tasking before. You know, if you write your test cases according to the requirements and prior to writing code, you won't have this problem!

"Let us reverse the situation. Say, a developer produces more than a tester can test within a period of time. This is the case with projects in many smaller companies, where the tester-to-developer ratio is low and the pressure to ship is high." — mature software engineering organizations leverage automated testing. mature software engineering organizations have test cases developed since day 1 of development; so that there isn't a backlog of testing which would interfere with the pressure to ship. After all, shipping is important is it's the vehicle which ultimately brings the revenue into the organization and thus keeps your staff happily employed!!!

My goodness, you want your teams to be high-performing, you don't throttle back one team because "it creates work for someone else"… that's the whole point of delivering software for Pete's sake. If you're experiencing backlogs in the examples described above, fix the problems with your design and requirements analysis and your software processes — NOT by artificially hindering productivity in the name of maintaining synergy!!!

Krish March 15, 2009 at 11:40 pm

@MGoBlue93

1. The point is not about writing code for unused features. The point is about completing the work way ahead of previously accepted deadlines.

2. Point accepted. I haven’t said anything to the contrary.

3. I fail to understand what this flow has to do with waterfall development. The flow is about what input leads to what work and this is the same in any methodology. In an iterative development, every iteration has the flow I outlined, more or less. Even in Agile, requirements has to come from the customer who has to finally accept the application.

4. I am puzzled by your statements. Where did I talk about having bug quotas or not to do automated testing? Even with the best testing practices, testing could get ahead of development and vice versa. All I am saying is that you need to find a way to prioritize bugs.

Regarding productivity vs. synergy, my point is that high individual productivity can inhibit productivity of the team. I agree with you that instead of throttling, you have to look at problems with the software processes. But even with software processes, you will find these kind of problems.

Anyway, go read “The Goal”. You will understand what I am talking about.

William Liao May 3, 2011 at 6:58 am

I find this article is surprisingly helpful, I’m having this debate in school, about this topic, and I’m trying to find a great reason that will totally make the “individual” side lose, and this article helped, I also don’t get what does the flow have anything to do with waterfall development. But, it’s a pretty good article overall. My teammates loved this article, so thanks a lot, Krish.

Comments on this entry are closed.

Previous post:

Next post: