What Creates Individual Productivity? Can We Improve It?

We've all heard tales of relative productivity differences among software developers: where the most productive are ten times as productive as the least.  Are they true? And is productivity a given, or can we inrease productivity through education, or motivation?  On the AgileProductManagement list, Janne Korhonen asked an interesting question a few weeks ago, which surfaced some interesting issues to think about. He asked:

Personal software process is the only methodology I know for developing individual productivity.  Are there others? What do you think about PSP from Agile point of view?  And what is behind the productivity difference?  I think that the biggest reason behind such differences is motivation.  In the short term, motivated people get more done.  And in the long term they learn more.  If this is the reason behind the differences then what can we do to get productive individuals?  Better leadership?  Or should we just hire motivated people and get rid of unmotivated?

(PSP is the Personal Software Process, and TSP is the related process for teams. Based on practices found in the Capability Maturity Model (CMM), the PSP was developed by the SEI to be used by engineers as a guide to a disciplined and structured approach to developing software.  PSP/TSP were developed in the late 90's, before Agile methods came strongly on the scene.)

On the thread, Diana Larsen calls this productivity issue a "squishy subject":

I'm more productive when I have good working relationships, less productive when I'm distracted by group or individual dysfunctional behavior. How do we separate my productivity from my colleagues? If I get along well with the person next to me, that might increase my productivity...or decrease it if we both hate the work and spend our time fooling around.

What does it mean to be productive? If I'm productive when I'm writing and turning out lines of text, am I also productive when I'm wrestling with what to write next (which could look like sitting and staring)?

Her colleague Esther Derby seconds the motion: judging productivity is tricky business:

One of the biggest mistakes we -- as managers and leaders -- make is focusing solely on the person. Sure, we have to have good people, but then we have to create an environment where they can succeed.  Further, there are some people who *look* motivated and may appear productive, but they actually make everyone else *less* productive.

Derby goes on to say that PSP and TSP aim to improve productivity by making patterns and obstacles more visible so that people can make different choices and eliminate obstacles. She says, "it strikes me that Agile methods also do that, especially when teams are diligently doing retrospectives."  She points out an article she wrote a couple of years ago, called "Skills are Only Half the Equation for Success."

Mary Poppendieck, co-author of two books on Lean Software Development, shares her viewpoint:

Much of the 10:1 difference in productivity comes about when developers realize that it is far more productive to write fewer lines of code, implement fewer function points, and accomplish the overall objective with as few features as possible. All manner of good things come from writing less code: delivery of business value in much less time; a far less complex code base which is then much easier to change and maintain; and less technical debt accumulated over the long term. What measurement do you use to quantify this kind of productivity?

There's a lot more on this thread, including Larsen's observation that it's a mistake to assume that the "most productive" individual is of most value to their project. She says "they are not necessarily the same."  Ron Jeffries contributes: "I think that sometimes 'working hard' is a negative attribute. [Some developers] are expending large amounts of effort and possibly spending many hours at the office but they aren't very effective."  Others talk about good and bad approaches for motivating productivity.

Korhonen comes back with an interesting point of view:

Someone not seeming to be 'productive' can really be the catalyst for productivity... So for example leadership should be evaluated by its capability to produce quality end products and so in the long run anything else than end product doesn't have value in itself.

And just to keep things light, Ilja Preuss injects an amusing note near the end, reminding us of one common threat to productivity with this (apocryphal?) story:

I once had a coworker who worked so hard that when I came in the morning, he was already sitting there trying to fix the things he broke after I left the day before...

Read the whole thread on the AgileProjectManagement list.