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.  

A Free PDF to Help You Choose the Approach

A Free PDF to Help You Choose the Approach

I’ve created a PDF you can download that will help you decide which approach is best for any story you’re adding detail to. It also includes examples of the two approaches.

Download my PDF
Mitch Lacey

About the Author

Mitch Lacey is an agile practitioner and trainer. Mitch has been managing projects for over fifteen years & is credited with many plan-driven & agile projects. He is the author of “The Scrum Field Guide”, a book targeting teams adopting Agile and Scrum practices.
Mitch honed his agile skills at Microsoft Corporation, where he successfully released core enterprise services for Windows Live. Mitch’s first agile team at Microsoft was coached by Ward Cunningham, Jim Newkirk & David Anderson.

As a Certified Scrum Trainer (CST) and a registered Project Management Professional (PMP), Mitch shares his experience in project and client management through Certified ScrumMaster courses, agile coaching engagements, conference presentations, blogs & white papers.

He has presented at Agile Alliance Agile 2006, 2007, 2008 and 2009 conferences, the 2008 Better Software Conference and the 2008 - 2013 SQE Agile Development Practices conferences. He was the stage producer for the Organization and Culture track for Agile 2009 and continued that trend by producing the Leadership and Organizations track for Agile 2010 and 2011, was the Agile2012 conference chair and is the Agile2014 conference chair. He has served on the board of directors for both the Scrum Alliance and the Agile Alliance.