Anyone for a Scrum?

In preparation for work on a new project, I have been investigating the Scrum software development process. I have read “Agile Software Development with Scrum” by Ken Schwaber and Mike Beadle and am currently reading the follow on book “Agile Project Management with Scrum” by Ken Schwaber. Next in the queue is “Agile Estimating and Planning” by Mike Cohn. From what I have found on the net, these are essential reading for anyone getting started in Agile. Based on what I have read so far, I tend to agree.

At its heart, Scrum (and really all agile processes) attempts to inject some much-needed realism into project planning and development. The pillars of Scrum are visibility, inspection, and adaptation. Schwaber spent time with industrial process gurus reviewing software development. The consensus is that software development is complex and can only be successfully managed using an empirical process. Scrum provides such a process. This is in contrast to a defined process such as the waterfall model that is embodied in many companies’ development processes (including the one used in my company).

Given that I am reading three books just to get familiar with Scrum, there is no way I can provide the detail in this e-mail needed to fully sell anyone on the idea. Here are a couple of good sites that cover Scrum. The first provides a very good high-level overview and the second gets into details.

CodeProject

Mountain Goat Software

At a high level, here are some reasons why Scrum should be considered for use.

Visibility into project status with Scrum is excellent. At any given time, it is easy to see what has been done and what still needs to be done via the burn down chart and product backlog. These are quantitative tools for examining cost/time/quality throughout the duration of the project. After a couple of Sprints, the burn rate or velocity of the team can be calculated and the end date accurately projected. Need more visibility? Reduce sprints to 2 weeks in duration.

Since Sprints are only 30 days long, if priorities change or problems are encountered, only 30 days are lost. Before each Sprint, the direction of the project can be refined or even drastically changed if needed. Scrum is all about agility and adaptability.

For larger projects, a set of interlocking Scrum teams can be used to develop sub-components. This is an area that will take a little more work to get right, but will be worth the effort. To quote Dr. Venkat Subramaniam (technical author, speaker, and amazing developer), “Any team with more than 10 developers is a setup for failure.”

At a recent JUG in Boulder, author Neal Ford asked the audience, “How many of you are developing using a waterfall process that is being called agile?” A lot of hands went up, including a co-worker’s and mine. Going forward, I have resolved not to be quiet whenever we use the term agile to describe a waterfall process. They are not agile. That’s OK, particularly if you buy into waterfall as a successful software development process, but it isn’t agile. Until we stop using the word to mean something it doesn’t, we won’t get any closer to truly finding out if agile can help us. If you don’t have enough first hand evidence already, Schwaber recommends “Wicked Problems, Righteous Solutions” for discussions about why waterfall doesn’t work.

Schwaber makes the observation that technology plateaus are gone and that new projects + new technology = unpredictability. Scrum provides a tool to manage these challenges.

What’s next? I recommend getting Certified Scrum-Master training for all management and senior developers and Scrum product owner training for the product marketing team. Then implement what you have learned in creating great products!