In this interview with Dr. Charles Suscheck, Ken Schwaber, one of the signatories of the 2001 Agile Manifesto, describes the first days of Scrum, the biggest threats to agile, and the next big idea in the Scrum framework: evidence-based management.
Charles Suscheck: Ken, you've been in Scrum for long time; well over ten years. It's a really different way of looking at software development. What triggered your mind, in those early days, to shift from a predictive approach to an empirical approach?
Ken Schwaber: I've been working with the ideas of Scrum for twenty-three years. Back then, we were building the first ALM tools in Burlington, MA, but the tools weren’t working very well. They were online and they weren't adopted. So we looked at a way to connect the methodology to the tools so that they would work better.
It was great, except I was using one of the early OO technologies and, at the same time, the customer was coming back with changes—new built-in capabilities or customizations. We were going nuts. The ability to deal both with the technology difficulties and the constant requests for changes lead me to start coming up with the ideas in Scrum and agile. At the same time, Jeff Sutherland, who is a friend of mine, was running into the same problems.
Turns out, we were trying to solve the same problems, so we started collaborating and found out we were doing pretty much the same thing. Jeff was formalizing these ideas from Scrum, so we started doing that together. We worked some more, and I started using the Scrum terminology as we fleshed it out. By 1995, we had a pretty well-described process that we called Scrum, which had a ScrumMaster and product owner and many of the current ideas.
The thing that drove me to these ideas was trying to be responsive to many customers and keep them in the loop. We would have gone out of business if we didn't work that way.
As Jeff and I were formalizing Scrum, we got an email from Kent Beck, who had seen our initial work at OOPSLA. He said those are really neat ideas and asked to borrow some—that is why you see convergence between XP and Scrum. I had always hoped, particularly leading up to the 2001 Agile Manifesto, that we could somehow band together, because Scrum answers the question of how to develop within an agile framework.
Charles: I read a lot of studies that say the adaptation of Scrum in agile organizations is well over 84 percent. Many companies are using Scrum as their primary framework. Does that surprise you?
Ken: Well, the latest data from Forester says 92 percent of agile organizations are using Scrum. I would have expected at this point to see 90 to 92 percent Scrum and maybe 85 percent XP. So it doesn't surprise me, because I think the statistics are a little funny. The data doesn't say how many organizations are developing software just with Scrum and how many are using modern engineering techniques, too. It just asks if you are using Scrum in your organization. I think if we ask the other question, the answer might be closer to 30 or 40 percent, which is still pretty reasonable. The most pleasurable thing is I think we have finally turned a corner on people thinking waterfall is a good approach for software development. As long as that type of mentality persisted, there was always the chance that we could have something like RUP or waterfall again.
Charles: What do you think are some of the big threats to Scrum adoption or growth?
Ken: I think the biggest threat is people's desire for certainty and their belief that somehow, if they can nail things down just a little better, they will have certainty. You see that with Safe and DAD and even the desire for kanban, which has more certainty than Scrum. I see these edges being eaten away by people wanting more certainty. Even within Scrum there are conversations about how to get more predictability of velocity, and the effort that people put into the sprint plan meeting trying to be more certain of what we are going to deliver at the end of the sprint. All that is absolutely contrary from the biggest idea in Scrum: Let's use short cycles so we don't care about how much we create, because we are going to find out very soon.