At the Open Volcano 10 openspace conference today, Jeff Sutherland talked about systematically achieving hyperproductivity. “Everyone can get there, without exception, it’s actually not hard at all once you know what to do”, said Sutherland, giving several examples from research of real projects.
Sirsidynix and Xebia, both running scrum with globally distributed teams, delivered 15.3 and 15.1 functional points per man month respectively. Saying that functional points are a comparable measure of complexity and performance, Sutherland also gave an example of the Microsoft Vista project which delivered 2 functional points per man month. (The figures are from the papers titled , “Distributed Scrum: Agile Project Management with Outsourced Development Teams,” from HICSS’40, Hawaii International Conference on Software Systems Big Island, Hawaii: IEEE, 2007. and “Fully Distributed Scrum: The Secret Sauce for Hyperproductive Offshored Development Teams,” from Agile 2008, Toronto.
Myspace “leftshifted significantly” according to Sutherland, losing high level management support for scrum and agile. Even in such a disfunctional company, Sutherland says they could get every team hyperproductive compared to where they started. Within 5 to 6 weeks, teams consistently got to 400-500% of their former productivity, with one team at 1500% productivity. This is the set of rules that Sutherland says were applied to increase the performance:
- everyone must be trained in Scrum
- backlog must be ready before taking into sprint
- software must be done and tested at the feature level, ready to go to production, at the end of the sprint
- information needs to be distributed – by pairing immediately when needed
- no multitasking
- physical scrum board
- short sprints (1 week)
- keeping burn down story points
- everything including support is prioritized by the Product Owner
- top priority impediments must be removed within two days
- implementing servant leadership
Venture Capital Strategy was interested in being hyperproductive through this same framework, and doing analysis after the implementation they concluded that peak productivity with waterfall was at 60 working hours per week per person and that with scrum the the peak of productivity was at 40 working hours per week per person.
Systematic Software Engineering was piloting Scrum after doing “perfect waterfall” and according to Sutherland consistently getting 36%-42% less defects to comparable projects. They were running scrums with acceptance test driven development, and the conclusion was that acceptance test driven development is mostly responsible for the drop in defects. According to Sutherland, they were already a company with one of the least defect rates in the world, able to constantly deliver high quality software and run such comparisons cross teams reliably. They also found that a well executed balanced scrum “scales linearly”, contradicting the Brook’s law according to Sutherland.
Summarising data from these projects, he said that “If you keep the time to fix a bug to two hours or less, you are guaranteed to double productivity”, advising teams to track time to fix a bug as one of the most important metrics. How long does it take a team to implement something, in average, is another important metric to track. “With those two metrics we can drive hyperproductive teams” said Sutherland.
It is crucial to keep inspecting work and removing impediments to keep the high productivity. “High performance teams are like modern fighter jets – they have computers in them that constantly adjust. If the computer fails, the jet becomes unstable. The faster you get, the smaller impediments get, but as soon as you stop removing impediments the team will crash and move back into the waterfall productivity state,” said Sutherland.
As the main challenge to hyperproductivity, Sutherland singled out developer self interest. Many developers see it as against their self interest to optimize for team performance – they often try to optimise for personal efficiency or personal interest and generate repeated sprint failure, or significantly sub-otimise team performance. This is not the “self-organised teams” idea from Scrum, said Sutherland, adding “We’ve got a lot of scrum out there but only 50% of them are doing iterative development” on the current state of Scrum adoption in the industry.
|
|
I don’t doubt any of the data here, but all this emphasis on velocity and ‘hyper-productivity’ causes more destruction than good. Managers read or hear this, and almost always start measuring in improper and dysfunctional ways, driving teams to deliver more and more functionality, faster and faster. They don’t give teams any slack to learn, experiment, make mistakes, innovate – all necessary in order to be more productive long-term. The result – if they manage to keep their good people, it’s only because those people have no place else to go. Maybe there are ‘golden handcuffs’ of good salary and benefits.
Also, I don’t care how many “function points” my team can deliver in an iteration. if we aren’t working together with the business people to make sure the company is focusing on the right business value, what will keep the company successful and profitable for the long term and meet all company goals and vision, we aren’t productive.
I worked on one team where 1) nobody in the company really cared about the quality of the software we were producing, it was just checking boxes off on a list and 2) nobody was allowed to suggest ideas, raise issues or ask questions. But the team was driven to produce a lot of volume of work, and was seen as a highly productive team. I didn’t stay.
Lisa, I did raise the question of function points of being a good reference during the talk and didn’t really get a satisfactory answer on that. It was interesting to hear about these figures but I guess as with any other statistics you can always bend it to show the point that you are trying to demonstrate. However, as always when I do a write-up of a conference talk, I tried to take a neutral view and present what the speaker said directly.
I agree with Lisa. I don’t think that this is good practice.
Managers tend to say: “Ohh but they said you will work 1500% more!”
They tend to base decision on numbers only. Which is never a good thing to do.
Jeff’s session video is up on the skillsmatter site for those who want to view it:
http://skillsmatter.com/podcast/agile-scrum/a-practical-roadmap-to-great-scrum-1374
Just in case anyone was wondering about Jeff’s use of the terms “leftshifted” and “rightshifted”, this was in the context of the rightshifting curve c.f. http://twitpic.com/k2gxj .
More info via the UK Rightshifting Network group on LinkedIn.
HTH
- Bob (@flowchainsensei)
the very idea of “hyperproductivity” is a bit dubious IMHO. claims involving such wild percentages usually get binned by my email spam filter, relating as they do to either Nigerian investment opportunities, or matters penile.
fixating on squeezing ever more product from employees wilfully ignores very pressing human concerns (written off here as mere “personal efficiency or personal interest”) and for this reason it should carry a fifty foot neon health warning.
I was addressing Sutherland’s points, not Gojko’s write-up of them – just to be clear! Gojko, you always do a great job of writing what the person presented, I knew it wasn’t you writing about your own views.
For all of the talk about Function points not being good, and “productivity” being a bad thing we have to understand and humbly recognize that Jeff is using data, some of it peer-reviewed.
Criticizing is fine if we have the data to back-up our arguments.
Does any of you (criticizing Jeff) have data to prove your claims?
Hi,
Servant leadership is an interesting topic. Are there any articles that you can recommend on this subject?
Now about fixing the bug in 1 hour or two, how can someone always restrict the fixing of a bug to this amount of time?