Ken Schwaber has been at the methodology game for many years, emerging from the rigorous, heavy methodology years of the late 1980s and early 1990s with a deep understanding of the fundamental flaws in detailed, process-centric approaches.
Scrum evolved from the combined efforts of Jeff Sutherland, Ken Schwaber, and Mike Beedle. It has been used in a wide variety of projects, by a number of practitioners, for nearly ten years. Ken and Mike teamed up to write a new book on Scrum (Schwaber and Beedle 2002), and all three—Jeff, Ken, and Mike—are Agile Manifesto coauthors.
As with several others interviewed for this book, I talked with Ken during the initial Agile meeting at Snowbird. In the lobby of the Cliff Lodge, after a couple of runs through two feet of fresh Utah powder, Ken and I relaxed and tried to tune out the noise of skiers coming and going.
Jim: What are the threads of your career that eventually led to the development of Scrum?
Ken: I’ve been doing software my entire professional life, nearly 35 years, but it wasn’t until I was at Wang Laboratories that I worked on a really big project, about 110 people. The whole project was very ad hoc—a lot of meetings and design sessions. I thought there needed to be a better way for everyone to understand what they were supposed to do, and said so. My boss replied, “OK, you are now in charge of processes for systems development at Wang.” I couldn’t see any benefit to SDM, and updating it was like beating a dead mule.
Wang was trying to sell its systems to MIS groups for software development but wasn’t having much success. I suggested that the reason was because people didn’t have a methodology, a practice, for building software using its database and forms generator approach, so I proposed building such a methodology and an implementation service. Wang demurred, and I left to do essentially the same thing with structured methods and CASE tools.
I was approached by Index Technologies, which had CASE tools and wanted someone to provide training and implementation services for structured methodologies. I founded a company, Advanced Development Methods (ADM), which grew to about 20 people. We grew a methodology, which proved to be a good differentiator for consulting companies in those days (1990-91).
Eventually, we built software that automated our methodology and called it MATE (Methods and Tool Expert). We used an early OO development product to build the tool, and people started buying it, which just flabbergasted me. People could customize their methodology using the tool. But we sure took in a lot of money that, when I look back, delivered very little value—and that always troubled me.
Jim: That was a period of time when people were spending hundreds of thousands of dollars for methodologies, training on methodologies, and methodology management software.
Ken: Many spent $400,000 to $500,000 on MATE and our services. One of our customers wanted to know if we would customize it with templates, detailed planning, an interface to Microsoft Project, and other things. It would do what we are all now against—very detailed master planning and estimating. We ended up with every customer wanting a customized version of MATE. At one point, we had 22 customers and 22 versions of the software—which is enough to drive anyone nuts.
At around the same time, Jeff Sutherland and I were doing structured methods, and he was beginning to work with something he called Scrum. He heard of Scrum from the “New Product Development Game” article (Takeuchi and Nonaka 1986) and the book Wicked Problems, Righteous Solutions (DeGrace and Hulet Stahl, 1990). Jeff’s and my friendship goes back to the early 1980s, and we worked together on systems starting in 1987. At some point Jeff asked me, with all these methodologies, which one did we use for building our MATE product? “None,” I said. “If we used any of them, we’d be out of business!” So we sat down with our own developers and asked them what they actually did, how they worked. And the answers were quick turnaround, evolving object diagrams, adaptive, requirements evolved, and that everything kept getting better and better.
Jim: About this time, in the early to mid-1990s, RAD approaches became popular. I was convinced that development practices—iterative cycles, focus on code, feature-driven teams—wasn’t just for small projects.
Ken: Exactly. Around 1995, our main business was still selling those big methodologies. Scrum allowed us to empirically control the software development process. We had two inspections—the daily Scrum and the end-of-Sprint review. We then added the practices that had projects quickly adapt to the findings of these inspections, such as impediment removal, product backlog modification, and quick decision making. We used Scrum to get out really critical projects where there was a lot of emotion and intensity—“save the company” kinds of things.
Jim: What type of project could use Scrum?
Ken: Most of our Scrum implementations have been in situations where people are desperate for the product and their regular defined approach or hacking has let them down. They need the product for their business to survive. An example was CoreTek, a micro-component fiber-optics start-up that was approached by a large telecommunications company as an acquisition candidate. The owner thought the offer undervalued the company, but since they didn’t have a finished product, valuation was difficult. To get the valuation increased, I asked the president, “What are the most important things to valuation?” He listed off a number of things—improving yields, an upcoming electronics show—but the one thing that seemed to be the most pressing was demonstrating a product at the show for credibility purposes.
With the show a few months away, we started daily Scrums with the team. These meetings have just three questions for each participant: What did you do yesterday? What are you planning to do today? What’s in your way? The company had lots of engineers, many of them with Ph.D.s, but they weren’t talking to each other. They had just been doing their own thing. These meetings got them talking to each other about what they were doing—they started communicating.
The 15-minute daily meetings not only aided team communications—they were used to set up meetings in which two or three people got together to resolve specific issues—but they eliminated many other meetings. People found that they didn’t have to go to other meetings because they might miss something.
Jim: Are you using Scrum to do more business consulting than software development consulting these days?
Ken: It seems so. Most of the projects that I’ve worked on are projects to build commercial products that the company depends on. I’ve done some IT project implementation work, and I see this increasing as organizations get more fed up with the traditional heavyweight approach. I have a friend who wants to use the Scrum process to build a new-style organization. We want to start with a live project, removing impediments and making things happen. Your alternative is using a big consulting firm and having them do a two-month assessment, recommend changes, then have everyone line up to resist the changes.