The Maxwell Curve Blunder in the Name of Scrum

September 9, 2008 by Hamid Shojaee

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:

Weekly productivity goes down to zero -0- if a Scrum team works 60-hour work weeks — they accomplish nothing.
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. :-)

Update:
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.

As Dennis pointed out in the comments (see below), another interesting graph would be the “Rate of Productivity”. Here, I’ve graphed what typically happens as the work week increases in duration:

Tagged with: hamid's curve, jeff sutherland, maxwell curve, productivity, Scrum

Categorised as: Development

Dennis A

I think that there can be a decrease in output from an increase in hours. I agree that going to 0 productivity is not likely, but an overall reduction is quite logical.

The idea that you are overlooking is project velocity, the rate at which you complete story points. Your analogy of destroying the widgets created in the first 40 hours of work assumes that we have the same velocity.

With a 40 hour work week, we have a sp/h of 120/40 or 3 story points per hour. With 50 hours, we have 80/50 or 1.6 story points per hour. So in 40 hours, only 64 story points would be complete, and none would be destroyed…

That being said, I highly agree that going to a velocity of 0 by working 60 hours a week seems far fetched. I think a more informative graph would be velocity by work week length.
http://www.axosoft.com Hamid Shojaee

Dennis, I think I fully agree with you but I’m not sure why you assume that I’ve overlooked the “rate at which you complete story points.” In Maxwell’s graph, the lines don’t represent the “Rate” or velocity of productivity, but rather “Total” productivity. Rate of productivity can easily hit 0 or even go negative as the work week increases, but it’s not likely going to erase all of the week’s productivity in any real-world scenario.
http://jeffkwak.com Futureturnip

I recently talked to Jeff Sutherland about this graph (I took ScrumMaster training from him). The explanation of 0 (even negative productivity), is that the rate of bugs or work in the wrong direction will start to accumulate and possibly completely take over the work of one or more sprints.

It’s not that you “smash the widgets”, it’s that you have to stop making the widgets because you’re fixing the “widgets” you said you finished yesterday (but didn’t in reality because they were broken).
Rick S

Though I reported to an executive who once asked all of us to “re-double” our efforts, the reality is that one person cannot be more than 100% productive at any point in time. Additionally, in spite of money, coffee, lashings, belittlement, or any other motivating factors that may be a part of your work environment, a person becomes less productive over time.

I do not agree with either case described in this article. An extreme case such as the one Hamid suggested is no more realistic in suggesting that productivity increases at a lower rate or flattens after 80-hours than Maxwell depiction by graphically suggesting that productivity (assuming Story Points are associated with a Productivity concept) will go to zero.

The reality that I experience is that after reaching a peak in productivity during a given work period, as the number of hours worked increases productivity begins to decrease, but will likely not never be zero – and will approach zero as the number of hours in a work week reaches a limit of 168.

The crux of the argument should focus on the point that you begin to see diminishing returns in productivity using a given methodology and associated tools or on the positive where you see efficiency gains from the right methodology coupled with the right tools and people.
http://www.andydent.com/ Andy Dent

My understanding of “Productivity” was that it was already a ratio, which Wikipedia confirms http://en.wikipedia.org/wiki/Productivity as “output from production processes, per unit of input. Labor productivity, for example, is typically measured as a ratio of output per labor-hour, an input.” Hence “Producitivty per hour” is an acceleration, not a velocity.

In terms of actual output, yes I believe the actual programming widgets delivered as a total can go backwards after a certain point, not only because of programming bugs introduced (damaging existing output) but bad decisions which have an even more leveraged effect in having to be undone.

The question is whether you are measuring “stuff produced” vs “stuff produced that doesn’t require re-work or repair in the near future”

To put Jeff’s point maybe more simply (brutally?) – you can do more damage with Scrum when you’re tired than you can with Waterfall.
Greg H

The other thing to keep in mind is that both graphs look different if you see the x-axis as timeline instead of points in time. For example, couldn’t the graphs be saying “If a team works 32 hours a week, they are going to get the most productivity compared to those teams that work 10 hours or 60 hours”? Similar to the comment made about Maxwell clarifying the 0 point at 60 hours, if a team works 60 hours then expect 0 net productivity for just the reasons he mentions. You will build 100 widgets and be fixing that same 100 at the end of the week…thus nothing produced.

If I work on projects for 32 hours out of a 40-hr week (fairly normal ratio though I see a 60/40 split is hard to maintain on my teams), then I get a work/life balance, solid amounts of worktime, and thus great productivity. Beat me over the head and make me stay for 60 hours (or stay for 70 while being billable for 60), I will gripe away several of those, not want to work harder, feel resentful and overworked and overtired and thus make many more mistakes or architectural blunders that cost me time over the week to redo.

As everyone seems to be mentioning, finding a solid methodology that matches your team is key. Work hard and find ways to keep your team on projects instead of “non-billable”. Give everyone solid work-life balance. Things will remain productive.

What isn’t shown is that even if the waterfall and scrum graphs were identical, you’d still create better software in scrum in shorter time. Huh? Well, scrum forces you to make the software do what meets the business needs. In waterfall those needs are too vague and nebulous, and set in stone way too early to make the software great at the end. You’ll spend many more cycles trying to kludge in that new functionality after the fact. So your productivity will be high…on doing all the wrong things! haha. True productivity is if you are turning out a high measure of what you are supposed to. We’ve all worked with busy overworked people who produce nothing.
http://www.onepax.com Gabe

I just started an article on Wikipedia regarding this. http://en.wikipedia.org/wiki/Maxwell_Curve Maybe you could fill it our more with other claims.
JL

Guys its time to get a play station
http://www.axosoft.com Hamid Shojaee

Andy, I considered the possibility that the Maxwell Curve was trying to graph the rate of productivity and not overall productivity, but even then, the graph makes little sense. There’s no reason why it should start at 0. It’s not likely that your rate of productivity would be 0 in the first few hours that you work, but then go to as high as 120 only in your 32nd hour and then back down to 0 by your 60th.

The Maxwell graph is simply wrong.

As for productivity going down as work week increases, I think we are all in agreement. Bugs, fatigue, etc. can cause productivity to go down significantly and in rare cases, go negative. I completely agree with that. In fact, both of the graphs that I’ve provided show that exact principle.
http://geekswithblogs.net/goinawry/Default.aspx john

First off, where do bosses like you come from? Another planet? Good for you, keep it up.
The point in this case, understand the meaning not just the numbers. As for productivity enhancements, I think it’s more dependent on the person than the process. Truthfully, if you gave me beautifully written, comprehensive requirements that I could understand… I’d kick your scrum butt. The reality, that is never going to happen. Agile and scrum came about to address this issue.
As we’re trying out scrum with “Tackle”, an interesting tool thrust upon us, I’m finding the “product owner” focusing on the chart that shows the estimated, actual, discovered, remaining, etc. during our sprint. I have to remind him, it’s the product that matters, not the chart. For individuals that focus on the charts and percent complete, I use the failure factor. Since we’ve literally chucked 3 different designs on this project, I count them. When asked where I’m at -
I’m 340% done.

Personally, I find multi-tasking to be the biggest killer of productivity. When the boss wants you slicing and dicing between 4,5,6, 10 different projects.
Good reminder, I’ll need to blog about this
http://jeffsutherland.com/scrum Jeff Sutherland

I started to think about changing this curve based on Hamid’s response.

However, as I thought about it I realized that Scrum teams that start working 60 hours a week start to transform into a waterfall team where management puts pressure on the system and turns it into a sweat shop. So Scrum people will either turn into waterfall people or start to quite sooner than waterfall people and go to an Agile company that works at sustainable pace.

Maybe 60 hours a week is too early for everyone to quit but Scrum is definitely going to go to zero earlier than a waterfall team. We now have several published studies showing that people that work in command and control pressured environments lose 5-10 IQ points, i.e. they get stupider so they will hang around longer.

I am open to any suggestions as to what work week drives all waterfall people to quit and what work week drives all Scrum people to quit. Remember, good Scrum people are raided by Google and it is pretty easy to get them to quit in a bad environment.
http://www.axosoft.com Hamid Shojaee

Jeff, thank you for taking the time to post a comment on the article. I have gone ahead and sent you an email explaining why the Maxwell Curve graph makes no sense. Hopefully the email will clarify what I was trying to say in the article. However, I do agree that the rate of productivity approaches 0 (and can even go negative) as the number of hours worked per week increases, but to be clear, that’s not what the Maxwell Curve says.
http://www.scottmaxwell.wordpress.com Scott Maxwell

Thanks for your comments regarding the Maxwell curve. It is unpublished work (at some point I will post the full description to my blog scottmaxwell.wordpress.com), but I would like to clarify that the Maxwell curve is conceptual and does not intended to imply that a specific number of hours is optimal. The basic idea is that for any given person or workgroup, there is a peak long-term output point as a function of the number of hours worked and that many people operate above that point (just to be clear, in my experience the point changes with age and other factors). The original logic is that the point of zero hours worked is going to result in zero output and as the work hours increase the output increases. at some point their is declining focus and productivity which reduces the slope of the curve and the total output starts declining at some point. The total output declines to zero at some point as the number of hours worked effectively result in no useful output. The curve is general purpose, not just for development activities, although the nature of development is a great example. I agree that it is quite possible that the curve actually goes negative given that low quality output could be negative value, although it is actually not very important from a practical perspective, as it is the optimal point in the curve that is the most important to truly understand. I developed the curve to try to persuade people I work with and around that working too many hours is not the goal and have used the curve quite a lot over the years. The point that I made to Jeff Sutherland was that the work intensity of scrum changes the peak up and to the left (higher output at a lower number of work hours), which has been proven out by our scrum teams. The numbers on the axes are not part of the Maxwell curve, but rather something that Jeff added to help describe what he sees.

Just to be clear, the curve that you describe above is the long-term Maxwell curve, meant to represent the output for a given number of hours each week over a long period of time. There is also a short-term Maxwell curve that better represents a short burst for a week or two of a larger number of hours. The curve has a higher output at a higher number of hours than the long-term curve, but the output will still degrade to the long-term curve if the work hours stay at a high level for an extended amount of time.

Hopefully, this better explains the concept. The points and conversation on the specific number of hours is a good one, but not one that I am going to engage in as the peak performance number of hours has a lot of variables (some of which are already discussed). The curves have proven themselves out over time in many work environments, and the major point of them has been to try to help individuals and teams find their optimal performance point. I will leave it to others to examine other points on the curve (such as whether the curve can go negative).

btw, your points about working a weekend for a special project and your last curve are essentially the short term Maxwell curve (if you change the units to output rather than output to hour and then redraw the curve). If you then extend the number of hours worked to a point where you would agree that your total output would be worthless if you actually worked that number of hours each week (you pick the number of hours that this would happen to you in your situation), you will probably get to the point where you can understand how the total output drops dramatically and the long term Maxwell curve is achieved. Again, it is not the important part of the curve, but hopefully can get you to the same general shape of the curve that I came up with based on my experience (luckily, I don’t actually have much experience out the outer edge of the curve, so my understanding of that point is more conceptual than experiential).

Again, the major point of the curve is that there is a maximum output at an optimal number of hours worked regularly and the point when truly using scrum effectively is that the maximum output point moves up and to the right.

Hope this helps.

Scott Maxwell
http://www.scottmaxwell.wordpress.com Scott Maxwell

sorry, I meant up and to the left at the end of my previous comment!

Scott Maxwell