Early Scrum Pilots

Background

After 8 months of battling with my VP, I got transferred to the Software Engineering Process Group (SEPG) to help the organization achieve CMM L2. I helped where I could but knew that it was not the right long term direction for the company. I continued to read everything I could on rapid application development including Steve McConnells' book "Rapid Development". That book confirmed a lot of my thinking at the time. The SEPG team had also recently hired a person who was the Rapid Application Development (RAD) practice manager for Digital Equipment Corporation (DEC). We paired up and started developing and piloting a RAD Guide.

The company did achieve CMML2 in April of 1997 and we held a big celebration on Friday. The following week several things happened. There was a leadership change, CMM went out the door, and we started piloting Scrum with Ken Schwaber. A couple of fellow teammates in Boston were assigned to work with Ken. Several MS PowerPoint decks were produced and then used to train and coach teams on Scrum over the next year.

Actions Taken

Scrum at the time looked a bit like snake oil. We spent a bit of time comparing Scrum to the RAD Guide we had developed. They were nearly identical. But rather than fight the battle we figured we'd just go along for the ride and see how Scrum worked. And surprisingly, it worked very well in 11 of the 12 early pilots. The one pilot where it didn't work was where Ken and one of the executives didn't get along. No surprise there!

While the pilots were happening, I noticed that the terminology was continually changing. It was almost like Ken was making things up as he went. Turns out he was encountering problems that needed creative solutions and was doing nothing more than relying on his extensive experience.

Sometime in 1998 there was another CIO change. The new leadership was questioning Scrum. There wasn't a lot of documentation on Scrum coming out. We were also highly dependent on Ken Schwaber. My manager asked me and a colleague to go in and spend 6 weeks with Ken to do two things: document Scrum and provide feedback on whether to extend Ken's contract or not. I traveled to Boston for an entire 6 weeks so I could immerse myself and learn everything I could about Scrum, shadowing Ken as he trained or coached teams.

Over the course of the first two weeks, I asked Ken every question possible. Then went back to my manager and informed him that I got it all and that we didn't need to extend his contract. My manager then told me to go and document Scrum.

We met with Ken, came up with an outline (backlog) of topics and actually practiced Scrum to develop the Scrum Guide. I wrote about 90% of the content with Ken as a reviewer. I also had Ken document the case studies of successes and the one failure and allowed him to publish these on his web site.

Resulting Context

Many years later I got a chance to attend a class taught by Jeff Patton and Jeff Gothelf. Jeff tracked me down during one of the breaks and asked me "I heard you got Ken Schwaber fired. Is that true?". Yes, I guess I did.

The work done on the RAD and the Scrum guide would form the basis for developing several scaled agile frameworks. Scrum continued to gain momentum until the dot com crash. At that point, focus changed from throughput to cost reduction. We started up offshore development centers and swung the pendulum back to more of a waterfall process.

Takeaways

• Scrum is just a framework. It is not a cookbook. It's not going to provide any guidance for many problems a team or organization will encounter.

• There is nothing new under the sun. Do not be afraid to dig up solutions from the past. Especially from how development was done in the 70s, 80s and early 90s prior to waterfall, PMI, stage gates, etc.