Before Implementing Scrum, Consider This...

So, you want to practice Scrum? Great idea, but don't be fooled. Great ideas are rarely easy to implement. Alicia Yanik found implementing Scrum to be anything but easy. In this week's column, Alicia contests that the process is certainly worthwhile, makes sense, yet definitely is nothing close to easy to implement.

I come from a rogue band of project managers who firmly believe there has to be something better than chaos, waterfall, and complete control. Six years into my project management experience a colleague recommended I look into Scrum. It was like entering the promise land for buck-the-system type project managers - and it all made so much common sense.

The company I worked for at the time existed in the land of chaos. Those at the top thought the implementation of any process would lead to the inevitable demise and downfall of the free world. Yet they bought off on Scrum, or rather, on what they heard when I described Scrum. This is important, so pay attention: they bought off on what they wanted to hear. It's easy to evangelize Scrum, to explain the benefits, and show how -- by implementing Scrum -- an organization achieves success every thirty days. Who wouldn't want to give Scrum a shot with those odds? The executives heard "daily status," "just enough documentation and requirements to be successful," and "new increments every thirty days." What they didn't hear was "no interruptions for thirty days," and "the sprint goal doesn't change during the sprint."

I succeeded in getting approval for Scrum, but then I floundered. Where should I start? What should I do? How was I going to make this happen? I found myself reading any article I could find related to Agile practices and Scrum in particular. I ordered books, I joined user groups, I even posted to user groups (and as all good introverts can attest, we NEVER post to user groups).

I decided to begin with the logistics of Scrum by holding daily stand ups, creating a backlog, tracking the burn down, and then I thought about what should come next. I believed the logistics of Scrum were easy to implement, but the power of Scrum doesn't lie in the logistics. The Scrum team holds the power. The team was initially hesitant about Scrum, but they quickly embraced it. I created a "mini-training" for the team, and was zealous in my excitement for Scrum and Agile in general. I always had a "scrummy" solution for removing any obstacle in our path.

The team didn't face many of the traditional pitfalls of software development. We released often, the work was always on time, and the team worked exceptionally well together. Our problems were in the planning, or rather, the fact that the planning never stopped and the priorities were never set. Our code was released literally as soon as it was written. The pace was quietly frantic and nothing was sustainable about our release process. With only four developers to write new code and support existing products, determine priority, define requirements, and perform any and all testing, we were headed for Burn-Out Fest '04.

We had the Scrum logistics in place, but I struggled with harnessing the team's power. I devoured more Scrum information and turned to the team for their ideas. We spent time in every team meeting talking about Scrum and how to move forward. Ken Schwaber noted in class that it's quite possible, and likely, someone on a new-to-Scrum team won't like Scrum. I found that to be the case with one of my software developers who pitted himself against Scrum and the rest of the team. Ultimately, Scrum wasn't for him so I stopped the bus, he got off, and someone new climbed on. I also faced resistance from a product manager who decided we needed process and documentation before we could even begin to start with something as

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.