Practicing Scrum or Doing Scrum?

If your organization is like any other today, they’re looking for ways to cut costs and deliver on time and for many development teams it means Scrum or some variation.

When you ask your peers what methodology they are using many will say Scrum, but the fact of the matter is Scrum is not a methodology it is a wrapper around existing methodologies. Scrum will work with anything from CMM to XP.

  In the company I’m with now we do sprints, planning and daily stand up meetings. Even doing those things we’re not really practicing Scrum, we’re doing Scrum. We’re just going through the motions and when you do that quality is the first thing to suffer followed by moral. Each sprint becomes a death march and the developers don’t really pay much attention to what is on the backlog, it’ll be rolled forward if it’s not finished. You also begin to see backlog fudge, where some pet project or desire is added because someone felt like that’s what they wanted to do. Inevitably we no longer release or demo functionality to the users and owners at the end of the sprint. We’ve gone from Scrum and XP to “Scrumterfall”  Waterfall with a Scrum veneer.

So how do we bring turn around from just going through the motions to reaping the benefits of practicing Scrum?

  The first thing that needs to be addressed is the backlog. The backlog need to be scrubbed and reprioritized. This process needs to happen on a continual basis, otherwise the backlog becomes stale.

  Once we have a well prioritized backlog, we need to plan the sprints. Normally we plan sprints for two or three weeks, which honestly is not enough time, especially in a greenfield project, such as the one we’re currently working on. Sprints should ideally be thirty days. I like thirty work days as opposed to thirty calendar days, that way you know exactly what time you have to plan and execute with. Planning shouldn’t be a one or two hour meeting where you grab enough items off the list to fill the available velocity. Rather planning should last for a whole day. The highest priority backlog items should be broken down enough to give a decent effort. Once you’ve selected and planned the backlog based on releasing working functionality you’re halfway there. It is essential that all the team members buy into the work to be performed and agree that it can be accomplished.

During the sprint the Scrum master needs to play the role of “Heavy” and eliminate interference and remove obstacles from the dev teams goal. He/She needs to insure the backlog doesn’t grow to include “pet” projects or “I feel like doing something else” backlog items. He should lead the daily stand ups using a simple format. What did you do yesterday?, What are you doing today? and What obstacles are preventing you from completing your tasks? The daily stand ups are not optional affairs, they should include everyone always, no excuses.

  The team should work to accomplish all the tasks planned for the sprint, but realize that you may not always complete all of the backlog items for a given sprint. You may also discover during the course of the sprint that the scope of some backlog items were underestimated or impacted more than originally thought.

The sprint should be closed out with a demo of the features implemented during the sprint. Invite users and management to come and try the functionality for themselves. Involving the users is key, if they’re not engaged or see no tangible benefit they’ll be less like to support further development.