"Take no prisoners, how a VC group does Scrum" was a chance to see Jeff Sutherland talk. Last time I saw him in London, he'd mentioned OpenView, the VC Group he was involved with who were using Scrum and insisting that all their investments used it, to up performance. This was a more detailed talk from Jeff and Igor Altman (who works at OpenView) on their experiences adopting.

Very interesting to hear that even a Scrum team so close to the originator of the method has gone through so many familiar stages and pitfalls...

• Organisations get refactored, just life software does. OpenView has "refactored its Scrum implementation" 5 times so far;
• VC groups have highly trained, silo'd specialists;
• The Maxwell Curve indicates that optimal working hours for a waterfall team are 60h/week. For a Scrum team it's 35h/week. VCs want to see their portfolio companies being optimal :)
• OpenView has a strategy of adding value to their investments by providing best practice, helping with execution in all areas of the business, running forums and workshops, doing on-site coaching and training. They and their portfolio companies were all full-Scrum by 2008;
• They do this to bring operational efficiencies to all their companies and maximise ROI. They've had 2 rounds of $100m investment, employ 22 staff and have 10 portfolio companies, including VersionOne;
• The VC ran 4-person teams on 1-week sprints, tracking in hours not story points (they couldn't get their heads around SPs); initially they adopted the trappings of Scrum but not much more;
• The team became self-managing, communications got better, they noticed themselves aggressively eliminating low-value work with stress reduced and impediments around clarity and communication;
• Quote: "If you're working long hours, you aren't doing scrum" - particularly surprising to hear that from a VC;
• Challenges they still had were overrunning meetings and some people uncomfortable with it all;
• In January 08 their planning took 1d (for a week sprint), with standups at 45m. But August planning was half a day and standups 15m;
• They noticed themselves oscillating between concentrating on quality and velocity; some team members were missing the big picture; and too many projects were dragging out whilst they were all being done in parallel;
• By November 08 they were running 2 teams of 4 staff, focusing on initiatives (epics) to give more "big picture", fewer simultaneous projects, and knowledge sharing through learning-lunch type things;
• They found they needed to balance direction, speed, quality and sustainability quite actively;
• Removing impediments without addressing the root causes usually led to those impediments returning later on - so they do RCA regularly now;

Comments

[Faffew Manglin]

Dear Tom

* The Maxwell Curve indicates that optimal working hours for a waterfall team are 60h/week. For a Scrum team it's 35h/week.

So they are trying to claim that the waterfall method allows you to code optimally for 10h a day 6 days a week? And yet, for the same project, using a different project management approach, can produce double the work in only 40h? Nothing about that strikes you as ridiculous?

Considering that they haven't provided any information about the data that backs the pwetty graph they have so prominently provided I would have to say that its rubbish. There are studies that cover over 100 years that indicate that working more than 40h per week is less productive than working 40h.

The following link is a concise coverage of the studies, applied specifically to knowledge workers:
http://www.igda.org/articles/erobinson_crunch.php

Many of the studies quoted above come out of industrial environments, and it may be argued that the more creative mental work of programmers, artists, and testers is fundamentally different. In fact, it is different, and Colonel Belenky explicitly addresses that:

In contrast to complex mental performance, simple psychomotor performance, physical strength and endurance are unaffected by sleep deprivation.

[Faffew Manglin]

Continued...

I personally think that unsubstantiated claims like this can damage Agile more than they promote it. Anyone who approves of this 'data' is already an Agile proponent, while anyone who is indecisive and sees claims about Agile made against a distorted baseline will be less likely to take other, more sensible, claims seriously. Its something which has been covered rather well before:

“Considered harmful” essays are most harmful to their own causes. The publication of a “considered harmful” essay has a strong tendency to alienate neutral parties, thus weakening support for the point of view the essay puts forth. A sufficiently dogmatic “considered harmful” essay can end a debate in favor of the viewpoint the essay considers harmful.
http://meyerweb.com/eric/comment/chech.html

I would personally think that they decided that the 60h week was harmful, and they tried 40h weeks independently of Agile. When they noticed the improvement they were reluctant to say "we have been ruining peoples lives for nothing" (burn out, get demoralized, and threaten to quit) and instead tried to explain the change in direction using Agile.

[Faffew Manglin]

Finally...

I wrote all this on your blog instead of his because I don't want to have to sign up to whatever flavour of the month rubbish I would need to be able to post on his blog. You can thank me later!

P.S. If the email field is required then some validation might be appropriate :)

[Tom Hume]

Thanks for the comment Faffew. I'm a bit tight for time, but let me get some thoughts out:

The figures aren't mine, but I don't find the idea that a combination of good process, technical practices and appropriate management support can deliver 2x improvement in productivity to be a priori ridiculous. They're not claiming that "waterfall allows you to code optimally for 60h a week", they're claiming that VC groups see the most productivity from waterfall teams when they work long hours... and that they see higher productivity from scrum teams working fewer hours, and productivity for these teams peaking at 35h.

The longest hours that I've seen worked are in startups and the games industry. They frequently lead to burnout, and the "crunch periods" of long hours are usually short (where short can be weeks or months). Some of the studies you reference talk of short periods of long hours being productive, albeit with a post-crunch period of lowered productivity - so there isn't necessarily a contradiction here. Given that the curve comes from VC research, I'd expect data underlying this graph to come from startups.

A bit of context: it was a VC guy and Jeff Sutherland (inventor of Scrum) presenting this. Their justification was that as a VC group, they want to see maximum return on the money they put into their investments. VCs are accustomed to pushing teams hard and encouraging long hours in order to do this - the sorts of hours they're talking about for waterfall project are not unusual in startups, or indeed the gaming industry. Their take was that with Scrum, their results were better when teams worked shorter hours.

Given the data's provenance, I'm inclined to give it some credibility. Whilst Jeff is clearly associated with Scrum, the VC firm have no interest in selling a process, other than as a route to productivity: their interest is purely financial and their view is that they get better value for money from Scrum teams working fewer hours, than they do from traditional teams working longer hours.

By contrast, I'd consider surveys posted on a site for knowledge workers to be more susceptible to selection bias - I'd be very surprised to see a site representing any knowledge worker promote the idea that their most productive working week is one of 60 hours. That said, I agree with their conclusions wrt long hours personally, as evidenced by the massive reduction of overtime here at FP in the last few years.

Jeff Sutherland does make some extreme claims for Scrum (along the lines of 1000% productivity gains in some cases). We've not see than sort of improvement here: there's still a lot of work for us to do in that respect. But we saw an increase in quality at the same time as a stark reduction in overtime post-adoption, which I think equates to a productivity gain of some sort, albeit a tough one to measure objectively.

It strikes me as quite strange to complain about the lack of solid data backing up the graph, whilst simultaneously and very exactly speculating on the motivations and method behind gathering it - where's yer data bwoy? ;)

There's another good criticism of the graph here: http://shipsoftwareontime.com/2008/09/09/the-maxwell-curve-blunder-in-the-name-of-scrum/ - including some comments from Jeff Sutherland and Scott Maxwell.

[My Real Name, Honest]

Dear Tom,

First off, your right about the second comment. I was expressing my opinion at that point, but after reading the comments they made on the article which you have linked it seems that the evidence base for the graph they have produced is not what I expected - so they are expressing opinions too. Naughty of me!

Secondly, about the graph. What I find disagreeable about it is the fact that it states that for work of a given duration, the waterfall has an optimal working week of 60h while, for the same duration, the agile optimal week is 40h. I basically see two timescales for that graph:

1) Short term. The graph is for the first week of a crunch. In that situation you would experience productivity gains by moving to a 60h week. However you should experience these gains even if you were using scrum. The article http://www.agilegamedevelopment.com/2008/06/scrum-overtime.html (which was linked by Jeff from his blog post) shows a clear increase in velocity on week 1 of a 60h week for a scrum team.

2) Long term. This is where I got all frothy at the mouth, and rather spoilt my point. The graph is for the duration of a project which lasts at least two months, if not more. This is when the article that I originally linked comes in. It expresses that productivity gains from the extended working time will be cancelled out over the long term by the accumulated fatigue of the workers. Interestingly, the very same effect is noted in the scrum overtime blog post that is linked to in point #1.

Now, I think that the agile section of that graph is a #2 graph, while the waterfall is a #1 graph. While startup members might push themselves to extremes through a macho effort to succeed, are they really being optimal in their use of time? This is where the article I linked mainly comes in - a lot of other fields of work have tried longer hours, and they have found that 40h weeks allow the workers to produce more than 60h weeks. In this case we are trying to apply those studies to a field that is intensively thought based - and that is where the "strength endurance etc are unaffected by sleep deprivation" quote becomes most applicable.

P.S. Have you thought more about that thing? Would you like to do lunch on Monday??

[Tom Hume]

I don't share your view of that graph. To me it says:

1. Productivity for a waterfall team is at its highest when the team works 60h a week. It tails off quickly after this.

2. Productivity for a scrum team is at its highest when the team works 35h a week. It tails off slower after this.

3. Peak productivity for a scrum team is about twice peak productivity for a waterfall team.

I don't see where you're getting the "timescales" view of the graph from, how you relate the graph to a specific duration or time period within a project, or why you think that two different sorts of project are being compared.

I agree with you on the "accumulated fatigue" point, I just don't see the idea that you can have short-term gains in productivity by working a few more hours as being contradictory to the Maxwell curve. Your point that 40h weeks allow more work to be done than 60h weeks in general supports the Maxwell curve a little, I think.

That Thing has had very little thought from me I'm afraid - as we're getting a little crunchier than normal right now. It may get little time from me next week too. Lunch would be good whatever, though next week is out for me...

[Igor Altman]

Hey guys...I know this discussion is a bit old but I just recently came across it. I co-wrote the paper with Jeff, and can comment on the origins of the famed graph.

Let me address some of the points raised here, all of them valid.

I'd like to start by discussing the context, which is that:
-Our focus is on helping our portfolio companies (all expansion stage software companies) grow quickly, and in a sustainable way.

-Our second focus is on growing ourselves quickly and in a sustainable way, so we can offer more operational assistance to more companies.

We adopted Scrum to help with this, and are still iterating (refactoring) our internal organization and processes to get better at what we do (and will forever, since we can never become perfect!).

When we experienced the initial boost from Scrum in focus and velocity, people started getting burned out, and noticed that working the same long hours as before with this higher focus was hurting quality of sustained output, and people were burning out.

So Scott Maxwell basically said, "Stop working long hours." And what happened was:

-Quality went up

-At a high level, the amount of output went down, but it was still much higher than when we were following an approach closer to waterfall

-People stopped burning out and started enjoying work much more, which has all kinds of benefits in itself, including attracting good talent

To illustrate this point, Scott drew up the Maxwell Curve for Jeff Sutherland on our white board, with no numbers on the axese.

Jeff subsequently added the numbers to help illustrate the point.

But let me be clear, this curve is not a result of a rigorous study with collected data (other than our velocity over time).

It is also not an attempt to sell anything, but I can see why people are having negative reactions to it.

Sorry for any confusion! No controversy intended.

FYI, I recently started blogging here, and sometimes discuss issues related to Agile and Scrum:
http://blog.openviewpartners.com/blog/igors-insights

I would love everyone's feedback to my ideas. They're still early in development (and after 2 years, I'm still relatively new to Agile), so I appreciate your skepticism, challenges and comments.

Igor Altman
OpenView Venture Partners
www.openviewpartners.com