Interview With Ken Schwaber Part 1

Part 1:

The Early Days of Scrum

Coming this spring, Better Software magazine will publish an interview with Ken Schwaber that I conducted.  As part of my blog, I will publish a number of excerpts.  Here is part 1 of 5.  Enjoy.

KS - I’ve been working with the ideas of Scrum for 23 years. I was using one of the early OO technologies and at the same time the customer was coming back with changes - we were going nuts with our inability to deal with the technology difficulties and the constant request of changes.

I started to start coming up the ideas in scrum and agile and found that Jeff Sutherland was trying to solve the same problems by doing pretty much the same thing.  Jeff was formalizing these ideas from scrum so we started doing that together and by 1995 we had a pretty well described we called Scrum today.

We got an email from Kent Beck who had seen our initial work at Oopsla.  He liked the ideas and asked to borrow some of them which is why you see convergence between XP and Scrum.  

I had always hoped, in 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.

Lightbulb experience

I had a lightbulb experience a few years ago  when I took a careful look at the agile values and tried to compare them to the traditional business values.  There really was no traditional set of values, so I had to construct my own version. 

I came up with: 

1) We develop processes and tools to standardize our interaction and maximize individuals’ productivity.

 2) All of our software has comprehensive documentation so that anyone can understand it quickly and easily.

 3) In order lock down a plan and cost for project, we enter contract negotiation with our customers.

 4) We follow a plan in order to minimize and control change.

 All of these are the exact opposite of the agile manifesto.  I now understood that the traditional techniques of developing software were based on control and came from a domain like construction, where the exact layout of the product under construction could be fully understood before beginning.  Software changes too quickly and it usually is a matter of “I’ll know it when I see it” for the end user.  

I began to see that a lot of what we do these days is a waste:  determining full requirements at the very beginning when they will change after a short time, estimating everything to the lowest level of detail at the beginning when the least amount was known about the project, putting together one-size-fits-all methods and then tailoring them down to the project at hand.  It’s all too much to just develop software.

I now use agile for software, running businesses, writing, creating all sorts of non-software related products.  It’s great.