Comments on: The Maxwell Curve Blunder in the Name of Scrum http://shipsoftwareontime.com/2008/09/09/the-maxwell-curve-blunder-in-the-name-of-scrum/ The blog that helps you build great software Wed, 21 Jul 2010 05:13:30 +0000 hourly 1 http://wordpress.com/ By: Scott Maxwell http://shipsoftwareontime.com/2008/09/09/the-maxwell-curve-blunder-in-the-name-of-scrum/#comment-813 Scott Maxwell Tue, 23 Jun 2009 23:03:33 +0000 http://shipsoftware.wordpress.com/?p=220#comment-813 sorry, I meant up and to the left at the end of my previous comment! Scott Maxwell sorry, I meant up and to the left at the end of my previous comment!

Scott Maxwell

]]> By: Scott Maxwell http://shipsoftwareontime.com/2008/09/09/the-maxwell-curve-blunder-in-the-name-of-scrum/#comment-812 Scott Maxwell Tue, 23 Jun 2009 23:02:24 +0000 http://shipsoftware.wordpress.com/?p=220#comment-812 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 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

]]> By: Hamid Shojaee http://shipsoftwareontime.com/2008/09/09/the-maxwell-curve-blunder-in-the-name-of-scrum/#comment-535 Hamid Shojaee Tue, 07 Oct 2008 15:57:01 +0000 http://shipsoftware.wordpress.com/?p=220#comment-535 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. 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.

]]> By: Jeff Sutherland http://shipsoftwareontime.com/2008/09/09/the-maxwell-curve-blunder-in-the-name-of-scrum/#comment-534 Jeff Sutherland Mon, 06 Oct 2008 21:16:34 +0000 http://shipsoftware.wordpress.com/?p=220#comment-534 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. 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.

]]> By: john http://shipsoftwareontime.com/2008/09/09/the-maxwell-curve-blunder-in-the-name-of-scrum/#comment-473 john Thu, 11 Sep 2008 18:49:45 +0000 http://shipsoftware.wordpress.com/?p=220#comment-473 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 ;) 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 ;)

]]> By: Hamid Shojaee http://shipsoftwareontime.com/2008/09/09/the-maxwell-curve-blunder-in-the-name-of-scrum/#comment-472 Hamid Shojaee Thu, 11 Sep 2008 17:52:12 +0000 http://shipsoftware.wordpress.com/?p=220#comment-472 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. 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.

]]> By: JL http://shipsoftwareontime.com/2008/09/09/the-maxwell-curve-blunder-in-the-name-of-scrum/#comment-471 JL Thu, 11 Sep 2008 09:15:42 +0000 http://shipsoftware.wordpress.com/?p=220#comment-471 Guys its time to get a play station Guys its time to get a play station

]]> By: Gabe http://shipsoftwareontime.com/2008/09/09/the-maxwell-curve-blunder-in-the-name-of-scrum/#comment-470 Gabe Thu, 11 Sep 2008 04:25:47 +0000 http://shipsoftware.wordpress.com/?p=220#comment-470 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. 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.

]]> By: Greg H http://shipsoftwareontime.com/2008/09/09/the-maxwell-curve-blunder-in-the-name-of-scrum/#comment-469 Greg H Thu, 11 Sep 2008 03:42:23 +0000 http://shipsoftware.wordpress.com/?p=220#comment-469 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. 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.

]]> By: Andy Dent http://shipsoftwareontime.com/2008/09/09/the-maxwell-curve-blunder-in-the-name-of-scrum/#comment-468 Andy Dent Thu, 11 Sep 2008 00:12:45 +0000 http://shipsoftware.wordpress.com/?p=220#comment-468 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. 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.

]]>