Three Tips for New ScrumMasters

We're starting something new with this post--we will occasionally publish articles by guest authors. I'm very happy to have as our first guest post, "Three Tips for New ScrumMasters" by Mitch Lacey. Mitch is the author of The Scrum Field Guide, which if full of great advice for new and experienced ScrumMasters.

One of the most common questions I get is "Now that I've taken a CSM class, what should I look out for when I return to the office?" While every situation is different, most new ScrumMasters should be aware of the following three issues.

First, remember the values and principles, the why-we-do-what-we-do portion of agile. Without a good set of principles and values, people will often flail because they lack a clear understanding of the why, the meaning behind the practices. 

Common indicators of a failure to grasp the principles behind the agile activities include:

• The team holding weekly "standup" meetings
• Teams not updating their task status on a Scrum board or tool
• Burndowns that are flat and suddenly drop to finish on time
• Not holding grooming meetings

For a refresher on the values and principles, watch my Scrum for Managers video - about the first 20 minutes - and reacquaint yourself with the why of Scrum and agile.

Another common issue has to do with architecture and design. In CSM classes, I discuss design and architecture but I don't go very deep on it. What I do say, however, is...

• Build incrementally
• Grow features over time
• Do the simplest thing possible
• Value feedback over "getting it right the first time"

The one people seem to struggle the most with is breaking the "getting it right the first time" mindset. One of my teams was able to build a system that supported millions of users and put it into production after a month by valuing feedback and throwing away the "getting it right the first time" mindset. How did we do this? Check out this talk from Microsoft TechDays in Sweden in 2011 for more information.

Lastly, many teams lack a clear definition of done. The DoD is a list of sorts that includes the product owner’s and team’s criteria for declaring a product backlog item as potentially shippable, or done. It's important for several reasons.

• It sets a common understanding throughout the organization on what "done" means
• It is a communication tool for stakeholders
• It helps remove technical debt

Creating a DoD is not as easy as it might sound. I have a detailed chapter in my book, The Scrum Field Guide, on this topic - and I have the chapter online as well. Check out how to create your own Definition of Done here.

They say an ounce of prevention is worth a pound of cure—this adage definitely applies to new ScrumMasters and teams. All ScrumMasters will encounter obstacles and challenges as they guide their teams. If you focus on resolving these three issues right away, however, you can avoid many of the common dysfunctions that plague agile efforts.