Scrum Scrum Scrum

It’s been a while since I last wrote – I’ve been eager to post but just hadn’t come up with the correct topic. The past several weeks I’ve immersed myself in Scrum – as in Agile. Last week I took a two day class from Ken Schwaber and I’m proud to say I’m now a Certified Scrum master. When I told my wife I was talking a class to become a Scrum Master she asked me if I was on drugs. When I assured her I wasn’t, she next asked if I was having an affair. I had to pull out Ken’s book and show her that Scrum is a real thing and there really are people out there called Scrum Masters.

For those of you who don’t know what Scrum is, it’s simply a software development process built on empirical data. It’s based on Agile that defines a plan for iterative development – rather than water fall. I really like to think of Agile (I’m watching out for the lightening bolt) as a series of mini-waterfalls. But this isn’t important. The Scrum process ensures the team works on the most important requirements at the time. And most important Scrum ensures the team is empowered. This means the team commits to the work and is responsible for seeing the work is completed.

The Scrum Master training was taught by Ken. If you’ve ever taken a class from Ken or had the pleasure of working with him you’ll know he’s a very entertaining person. My favorite anecdote was the squirrel burger. Remind me someday to tell it – although I won’t tell it half as good as Ken.

There are many teams at MS that are toying with Scrum and several that may actually be doing scrum. Though not many are doing pure Scrum –most have modified it in some way shape or form. While the purest in me wants to correct them from saying they’re doing Scrum, I do appreciate and applaud their efforts and rather than judge I will support their efforts.

My group is working on implementing Scrum. Make no mistake about it, it’s hard. It’s a completely new way of thinking – a way that most people who have worked any time in the “traditional” software development world really struggle with. The notion of empowering the team is really foreign to them. What do you mean I can’t just sit in my box and write code? What do you mean I need to attend a daily meeting? I’m a dev, what do you mean I need to write automated test cases? In essence the individual titles are removed and replaced with the title of “team member.” Once people become used to this they flourish. They realize that if a team member doesn’t succeed the team doesn’t succeed and ultimately, personally, they don’t succeed.

Sorry to use a baseball analogy, but think about when there's a runner on third and the pitcher throws the ball past the catcher. Does the pitcher stand on the mound and point the finger (or give him the finger) at the catcher? No, the pitcher covers home plate in the catcher's absence. Is the pitcher a catcher? Not generally speaking. The pitcher is trained in how to pitch, not play catcher - there two totally different positions. But when the team needs the pitcher to be a catcher - the pitcher obliges for the good of the team.

We’re slowly implementing Scrum which I’m not convinced is the right thing to do. We’re introducing the basic process and tenants of Scrum and over time moving bits and pieces of our process to the Scrum process. This is contrasted with jumping in and moving everything to pure Scrum. Change can be difficult on people. We went through a re-org a couple of months ago and I felt that pulling the process rug out from under the team would be too much. But I wanted to leverage the change from the re-org to start the process change. So far it’s work pretty well. People are becoming more comfortable with the process and as they see things working they’re much more receptive to changes. For now I’m going to continue with the iterative introduction of process and see how it goes. We had a new Group Manager start yesterday. He’s a Certified Scrum Master and implemented Scrum at his previous company. Also, I have a new PM starting at the end of the month who’s also a Certified Scrum Master. Having knowledge and experience on the team will be a huge help.

I encourage any team (IT or commercial software) who’s using RUP or waterfall or CMMi for that matter to investigate Scrum. There are thousands of success stories and there are failures; Scrum isn’t a silver bullet. It’s a very simple process that’s incredibly hard. Mostly this is because software development is hard.