During his long career, Jeff Sutherland – often referred to as the inventor of Scrum – has participated in many projects where Scrum has been implemented in larger organizations. In this article, he shares his experiences in an industry where offshore outsourcing is a major trend.
When did you first try Scrum for larger projects?
In 1996 I was hired by IDX-systems as their VP of product development, and eventually their CTO. I started at that company with about 300 developers, and by year 2000 we had almost 600.
So we started immediately by convertingthe 300 developers that were in the company – all of them – to Scrum in 1996.
And how were the Scrum teams organized in this company?
IDX had several business units with different product sets, and all the products had to work together in large enterprises. The larger product units had about 100–150 developers, and the smaller ones were 30–60 developers.
One of the interesting things I am finding in companies now is that about 60 developers tend to be a product unit. If the product is bigger it can typically be broken down into pieces that work well, with about 30–60 developers in each development team. And that can be very nicely broken down into a set of Scrums that is run by a Scrum of Scrums which consists typically of the leaders of every Scrum team.
So, according to your experience, how many Scrums would there typically be in a product unit with 60 developers?
If you divide that by seven you get a little bit less than nine, so it would probably be seven or eight Scrums.
When starting with these larger projects with Scrums of several and more Scrums – which were your greatest challenges?
We really did not have any significant problem in extending it into multiple teams. The problems we had were the typical problems when starting up a single Scrum – making people understand how it works and following the process. Having the daily meetings and get the reports out, so the whole team could see the state of the project every day.In retrospect at IDX we had very detailed data provided by external consultants on the productivity of every team.
I engaged Capers Jones, who is one of the leading productivity analysts in the United States. I had his company come in and do a function point analysis of every release for all products. So we knew how many function points were added incrementally by every team. So we got a clear velocity that was completely independent of any team, and was comparable across teams. IDX on the average increased their productivity with a factor of about 2.4 using Scrum – that is 240 percent. But Scrum was designed to produce teams that get five to ten times of industry average. I was always interested in finding a few teams – which we did have – that hit that hyperproductive state. And I was always trying to figure out why the Scrums that only doubled productivity – why they couldn’t do more. At IDX in retrospect, I had a lot of difficulty getting them to break the teams down small enough. They had a culture that historically had had thirty person teams – and I managed to get these teams down to fifteen or less, but I could not get them all consistently down to seven. Industry data show that seven people can finish the same project earlier than eleven people – so that I think significantly impacted productivity. You know, the goal of Scrum is to achieve Toyota-level performance, that is four times the level of your competitors in terms of throughput, and twelve times the quality. And the fact that we only doubled the productivity and could not get four times I believe was directly related to the team size.
So, one of the problems when implementing Scrum in larger organizations is obviously that it is hard to get the size of the teams small enough.