Jeff Sutherland has piercing blue eyes – friendly, but probing – and a frequent smile. They are a bit like a distant uncle who wants to know what you have made of yourself.
After several CTO assignments at various companies, Jeff Sutherland found himself at Easel corporation where he created Scrum together with Ken Schwaber. Ken later presented this methodology at the OOPSLA conference in 1995.
A dozen years later I find myself in search for a good spot where I can concentrate on my interview. Jeff and I sit down at a café at the Øredev conference. My computer has been acting up going blue screen on me twice that day. Time is short and I wonder if it’s an omen.
Photo of Dr Jeff Sutherland.
Dr Jeff Sutherland. Photo by Mai Skou Nielsen, Trifork
Q: I hope I’ve done my reading. As far as I understand you’ve been a fighter pilot in Vietnam, an assistant professor in math and medicine and the CTO at nine different high tech companies. Moreover, you travel the world to teach Scrum. Does it take a resumé like this to invent a process like Scrum?
The key part of what makes Scrum work is “complex adaptive systems” and you need some understanding of this. Also you need to understand systems theory and how to optimise a system as a whole.
You do not have to be smart, but you have to thoughtful.
Q: How did Scrum start and from where does it draw its heritage?
Scrum and Lean both derive from complex adaptive system theory. Constraint theory is a narrow subset of complex adaptive systems thinking. Lean implementations of these theories have been created at companies like Toyota and Honda. Honda was actually more aggressive at this in the nineties, but then Toyota was more successful in the market. They also were more formalised and better known.
Q: Why does it work?
The first reason for all of this is important – super intelligent performance out of ordinary developers. In order to do that we need we need to set up a simple framework so that people will self-organize. The second reason is that there is no central point of control. The manager needs to back off. That is critical.
The third principle is behaviour that emerges in the team based on self-organizing in order to get max production.
The fourth reason is that the production is far higher for the group than any single developer. Groups actually achieve more than any lone bright developer.
These are the basic principles of a complex adaptive system. Any organization is a complex adaptive system. Software production is an organizational phenomenon. It is an empirical process that must absorb significant change in requirements, technologies, priorities, and people.
Q: You talk about managers, why is it important for them to back off?
A company needs to stop sub-optimizing locally. That is the thing that Toyota figured out, largely due to the efforts of Edward Deming and other Americans who trained the Japanese in WWII industry processes. Most managers just care about local performance. Managers have to work as a team to look across the whole spectrum. It is difficult for them. They’re paid and given bonuses on a single level, not the company as a whole.
For instance, look at the General Motors manufacturing plant in Fremont, California. GM shut down that plant 1982 due to several problems, among them quality. Two years later it reopened as a joint venture between Toyota and GM. Toyota needed a plant in the US in order to avoid import restrictions. In an agreement with the labour union they offered reemployment to the former employees.
Two years later the NUMMI plant was producing over 200 000 cars per year and was twice as productive as the typical GM plant. The thinking they applied is the same as “lean production” where Toyota makes the team responsible to figure out the best way to solve the problems and achieve the goals. NUMMI later won several awards for quality.
“Your battery is running low”, declares my machine solemnly. Jeff and I make a run for a power outlet and find one on the second floor. My power chord is too short so we stack up real close to the wall. It will do. More than that actually, it feels like we really are working together on this interview.
Q: Some parts of Scrum are frightening, like making the group totally responsible for an implementation. How come people in management buy this?
The best answer I can give you, is the discussion I had with my first CEO when I introduced the ideas of Scrum. We had a critical project with a hard deadline. It was a question of survival.
The CEO expected a Gantt chart [ed: a timeline specifying activities and their dependencies, showing the progress of a project].
- How many Gantt charts have you received that actually worked? I asked the CEO.
- None, was the short answer. In my 25 years I haven’t received a single one that was correct. I asked him if a 100% failure rate wouldn’t make it foolish of me to give him one.
- What are you going to give me, he asked?
- Working software. Decide for your self to if we’re on track. In return I made him promise not to disrupt the team before the deadline. At this point he started to worry.
I said that at the end of the month he could change everything he wanted, but not during that month.
- If you do this, you will get significant more code with better quality.
- I can live with that. Let’s do it.
Scrum was born in that minute.
It’s a basic contract between management and team. The team delivers twice as much stuff with twice as good quality (minimum) and the management supports the team in their efforts to self-organize and self-manage. If either party does not fulfil this contract then it will fail.
Q: Doesn’t Scrum fail?
Scrum itself is a set of rules that causes self-organization if certain things are put in place. It’s like the rules of soccer. Does soccer fail?
With Scrum you will fail significantly less.
The Standish Group \[ed: a company that specializes in IT studies\] reports that project in the range 3-6 million dollars with a traditional project plan fail more than 85% of the time. Scrum does a lot better than that!
Q: What are your top three tips on using Scrum?
Bas Vodde was the Lead trainer for Scum Master at Nokia Siemens Networks. He has the shortest set of questions to identify a dysfunctional Scrum team.
You must have iterations of 30 days or less with working software tested at system level at end of each iteration. You need an agile specification, just enough for programmers to start for that iteration.
You need a product owner who orders activities by business value of the feature set. The team estimates the product backlog.
And lastly, the team needs to monitor progress with a burn down chart and know its velocity at the end of the iteration.
Q: Finally, what is in the future for Scrum?
Hyper productivity on an economic and marketing level where companies consistently out perform their competitors. Scrum is a disruptive technology that will alter markets. Companies doing Scrum well will grow rapidly in both size and profitability and dominate their waterfall competitors. There is already a brain drain going on where the better developers are fleeing from waterfall companies to Agile companies. This will hasten the demise of traditional projects.
Q: Is this a shameless plug?
Oh no, we have achieved it in several departments at my company \[PatientKeeper\]. It is doable. Other companies I work with right here in Scandinavia are doing it as well.
Going away from this fast paced interview, I still have the feeling that I could have done more with my life. If Jeff can do it, then so can I …I hope
Originally published in JayView.
Tumblelight 