Blog

Context Matters: Why I Don’t Believe in Best Practices

Most every week I am out training or coaching with one or two companies around the world. So, I am exposed to how many different companies are applying agile development – sometimes successfully, other times not so much.

Since my clients know that I visit many different companies they often ask me for “best practices” – approaches other organizations are using to more successfully apply agile. I know that my clients ask me this so that they can leverage the learning of other organizations to enhance their own agile adoption. To be helpful I provide examples of what has worked well for other companies or with other teams inside their own organization—but with one large caveat: those same approaches might not be as successful for them, and could even be harmful. Then, when I share a particular approach that has worked in the past, I also provide the relevant context of the other organizations or teams. That way, the people who are asking can evaluate whether it would be sensible to adopt a similar approach in their situation.

I believe there are no best practices, only good approaches in context.

Let me explain.

Practices vs. Approaches

First, notice that I make a distinction between practices and approaches. I use the term practice to mean a core or essential aspect of Scrum. For example, sprint planning, daily scrum, sprint review, and sprint retrospective are Scrum practices. An approach, on the other hand, is a particular implementation of a Scrum practice – for example, how your team conducts a sprint review might follow a different approach than how another team in the same organization conducts its sprint review. When people ask me about best practices, I take that to mean best approaches.

While two different teams or organizations have unique Scrum implementations, each should adhere to the same Scrum practices. Both, for example, should have Scrum teams made up of a product owner, ScrumMaster, and development team (developers). Both should perform the Scrum practices of sprint planning, daily scrums, sprint reviews, and sprint retrospectives. However, I expect that each team (or organization) will have its own unique approaches to performing these practices. Many organizations try to describe what a successful Scrum team is doing, capture it, and then institutionalize it as a best practice. Doing so can be harmful, because these are individual team approaches that may not work for other teams.

Tossing the Moose

Let me illustrate by example. The daily scrum is a core Scrum practice. If you don’t do it, you aren’t doing Scrum. During the daily scrum each team member updates and synchronizes with all other team members to get a shared picture of the full scope of work. But when the daily scrum starts, which person should provide his update first? Scrum doesn’t define this. Instead, each team will have its own approach.

While working with a team in Vancouver, Canada, I learned of an interesting approach to deciding who speaks first. On this team, at the start of each daily scrum, the ScrumMaster tosses a toy stuffed moose into the air. Whoever catches the moose, speaks first, and then the rest of the team members speak in turn, moving to the left of the person who first caught the moose. This simple, kind-of-silly-but-fun approach worked very well for the team in Vancouver. 

Tossing the Moose

As it turns out, the Vancouver team had a sister team in China that was formed some months after the Vancouver team had been established. A member of the China team asked the Vancouver team for a “policy or best practice” for determining who should speak first at the daily scrum. The Vancouver team told the person in China that in Vancouver they “tossed the moose” each daily scrum to figure that out. Apparently, tossing the moose took on a whole different meaning when translated into Chinese! An approach that worked well for the Vancouver team would not work at all for the China team. The China team adopted its own approach, as well it should.

Conclusion

Scrum defines core practices that must be followed. It is left to each team, however, to determine the approaches that work best in a particular situation. Approaches, therefore, are unique to each team; they can and should be reused by other teams only if they make sense in the context of those other teams.