The Maxwell Curve Blunder in the Name of Scrum

The Maxwell Curve Blunder in the Name of Scrum

I recently ran across Jeff Sutherland’s blog article, titled Maxwell’s Curve Getting More Production. In this article Jeff refers to the Maxwell Curve, a concept created by OpenView Venture Partner’s founding partner Scott Maxwell about how team productivity actually decreases as teams work longer hours in a given week (see the graph to the right).

Looks reasonable, right?

However, if you study this graph for just a tad longer than a glance, the graph is actually quite humorous as it seems to suggest the following:

  1. Weekly productivity goes down to zero -0- if a Scrum team works 60-hour work weeks — they accomplish nothing.
  2. Using a Waterfall methodology is far more productive than Scrum for teams that must work 52 or more hours per week.

WOW! What am I missing?  This is supposed to be a pro-scrum article, right? You might recall that Jeff is a Scrum co-founder. He also has a Ph.D from the University of Colorado School of Medicine (Wikipedia), and Scott Maxwell is no slouch either having graduated from M.I.T. with a Ph.D in Mechanical Engineering (OpenView Profile Page).

Now, I’ve become a big fan of Scrum lately and I love that Scrum is taking off in a big way with so many software development teams adopting it. But sometimes, with the rapid adoption of new software, technology or even a methodology, strange claims are made. I think Maxwell’s Curve is one of them.

Now to be sure, I agree that productivity slows down and might even go negative as the number of hours worked in a given week increases beyond the social norms for the region and average age of the team, but that’s not what Maxwell’s Curve is indicating. It’s indicating that productivity actually starts to reverse itself significantly just shy of the 40-hour typical work week. Basically, the graph suggests that negative productivity kicks in and erases all of the positive productivity of the previous 40 hours in less than 20 hours: a pretty impressive accomplishment in and of itself.

If the vertical axis indicated “widgets” instead of “story points,” at about the 32-hour mark, the team would stop creating new widgets, turn around and start smashing all of the widgets they had already created previously in the work week. Software development is different than assembling widgets, of course, but it’s hard to imagine a generally productive team that would net 0 story points (productivity) because they worked 60 hours instead of 40.

What’s even more intriguing is why teams using a waterfall method would remain productive for as many as 80 hours — how the usage of Scrum could possibly slow down teams that work more than 52 hours when compared to Waterfall teams is beyond anything I can comprehend.

Reality, even in Jeff’s own example, suggests otherwise.

For the record, I’m a big advocate of the 40-hour work-week, but I have no delusions about how the 40-hour work week impacts our overall performance. The 40-hour work-week helps Axosoft maintain its competitiveness in the following ways:

  • Attract talented individuals who wouldn’t want longer hours forced on them;
  • Improve the work/life balance of employees, which is great for employee retention and general happiness levels;
  • Reduces animosity and feelings of dissatisfaction when generally developers are the only ones expected to work the long hours while management and other employees head home.

That’s why the 40-hour work week is so important, not because negative productivity takes over and erases all of the week’s accomplishments.

So do I worry if an employee makes the choice to come in on the weekend or work extra hours in the evenings on a project that he or she is excited about? Not at all! That is virtually guaranteed to improve productivity, not reduce it. But I don’t expect employees to do that and when they do, I generally make it a point to reward them for it.

So what about the Maxwell Curve? Well, I can’t just leave a blunder like that alone without attempting to correct it. So until Scott Maxwell updates his curve, I’m going to have to introduce the world to Hamid’s Curve:

Disclaimer: The above graph shows the probable relationship between productivity and work-week-hours and is totally non-scientific. It’s a rough sketch drawn from experience. 🙂

Some people have suggested that I didn’t take into consideration the negative productivity of teams when the rate of bugs are increased as a result of fatigue from long hours. But that’s precisely why productivity goes down significantly and can even (in rare cases) go negative. In the article, I explain that I definitely agree that the rate of productivity goes down and often hits 0 at some point, however, Maxwell’s graph suggests that if you work a 60 hour week in Scrum, your overall productivity (not your rate) for the week is actually 0. The graph actually shows rate of productivity going negative somewhere around 32 hours. It further goes on to suggest that somehow, you’d be better off using a waterfall model if your team regularly worked 52-hours (or longer) weeks because teams using waterfall don’t hit 0 overall productivity until 80 hours of work. Those are both unwise claims to say the least.

Another interesting graph would be the “Rate of Productivity”. Here, I’ve graphed what typically happens as the work week increases in duration:

Stay on the cutting edge of software development by getting innovative tips, trends and stories delivered to your inbox every month!

Agile project management software
Plan, develop, review, and ship fast


Legendary suite of developer tools
GitKraken Git GUI, Boards & Timelines