Scrum De-Mystified, Not So Bad After All

It all started this past summer, of 2006. I started hearing about the latest sure-fire recipe for conducting software development projects: Scrum. Of course this new-fangled methodology came with many new terms, techniques, and rules to learn. After developing software for twenty-plus years now, I am wary of new crazes in this business, so I kept my distance, and did not pursue it.

As fall approached I heard increasing buzz about Scrum. Then finally the request came from my management to try it. I would dive in, wary or not, and I was to follow this new process with no formal training – learn on the job. The project leader, the “Scrum master”, was the only one trained in this practice, and would guide us. Alright, time for this old dog to learn another new trick.

Quickly I had to ramp up on Scrum. I asked co-workers and read many Web articles to “bone up” on it. I quickly learned there was a fair amount of disagreement on exactly how Scrum is practiced. Great! So then came the challenge of forming opinions on what aspects I felt were helpful, and which were overkill or a bad fit for scope of the internal tools development project I was to work on. A big concern I had was the possibility of Scrum -- with its daily project tracking meetings -- being too heavy on the micromanagement.

Before we go any further, I will try to de-mystify Scrum, using my own words, for those who still could use the explanation.

Scrum is relatively new agile software development methodology where you repeatedly develop usable components, in planned cycles of about a month, or sprints. It is highly-collaborative; with emphasis placed in team success, and software features evolved via frequent team interaction. It is called lightweight as it focuses on completion of limited-scope features, based on limited high-level functional requirements. It is light on the documentation, which can be addressed in follow-on sprints. The goal is to progressively build software, piece by piece, with each piece being a demonstrable, functioning unit. As a team completes more sprints, it gets better at working together, communicating with each other, estimation, and ultimatly self management. Both the software and team evolve.

Older software development methodologies include waterfall (1970), rapid application development (1980’s), and “cowboy coding”, a methodology-free approach that has probably been practiced since computer programming began. Like rapid application development (RAD), Scrum is a form of iterative development. The software is evolved via some degree of trial and error. But I would call Scrum a more controlled form of iteration. I need to say this because RAD is now widely regarded as bad practice. It is too much like the cowboy coding, with the rapid prototyping leading to poorly thought-out, limited, and too-customized designs.

The iterative, exploratory nature of Scrum deals well with ambiguity and the reality of not being able to foresee all software requirements and technical challenges before starting the development. You get to start coding with rough estimates on small units of work. It may take longer or shorter to complete a task, and that is just fine, as long as the team completes some demonstrable, high priority task before each sprint ends. You work off of a prioritized running backlog of requirements.

Ok, so how did it work for me?

Very well! And I am in my third sprint now.

First, our daily meetings are cool. They are short and focused. No more being asked every hour or two if you are “on track”. The meeting “pain” is predictable and limited. Measurable project progress becomes highly apparent to all involved. I get to focus on my work, with limited interruptions, by design. A key element here is emphasis on not breaking the work/thought flow of each worker. You avoid multitasking and taking change requests in order to focus on completing your sprint tasks. We come together for the quick huddle each day, then back to work. We did our meetings right after lunch, after we were already on a break from work.

Next, I like coding with rough designs, and rough estimates. No more pretending you know exactly what each piece will do, how it will do it, and how long it will take before entering a do-or-die six month death march, living up to your scary wild guesses. Taking it one month at a time is much more manageable.

Finally, the team building is great. Another key Scrum element is for the teams to self-manage. Because we work collaboratively with frequent interactions, we need less guidance from any outside people. Ideally, the Scrum master plays the role of record keeper, coordinator, and is an objective non-stakeholder. She keeps the outside world informed of progress, via integrated burndown charts, and keeps us from being distracted by outside influences like the business owners or managers.

Not so bad after all!

Recently I took a three day class on Scrum to fortify my knowledge but found out we were doing just fine without the formal training. Scrum seems more about philosophies and attitudes than strict process. You can adopt the specific practices that work for your team. Adaptive processes, adaptive emergent designs, lean engineering. This old dog keeps evolving, and so can you.

(Editor’s note: Microsoft Press, (Best Practices series) has a great book out by Ken Schwaber entitled Agile Project Management With Scrum (ISBN-13:978-0-7356-1993-7)

Comments

• Anonymous
  January 01, 2003
  Scrum is an agile software development process. Work items are placed in a product backlog. You select