Ambysoft logo

Questioning the Concept of "Best Practices": Practices are Contextual, Never "Best"

Follow @scottwambler on Twitter!

A very popular term within the business community is "best practice". It's a wonderful marketing term, how could someone possibly argue about adopting a best practice, but does the concept really make sense? I'm not so sure. There are many examples where a practice that is considered "best" in one context is questionable within another. As professionals, it seems to me that we should strive to understand the context which we find ourselves in, and then apply the practice which is best within that context. In other words, we should really be focused on "contextual practices", not "best practices".


When you observe what's going on within the agile community it becomes clear that many "best practices" really aren't. For example, consider the following practices:

Towards Contextual Practices

Ideally, we should talk about best practices at all but instead should talk about contextual practices. Depending on the context, sometimes a practice is "best" and sometimes it's not. Calling something a "best practice" implies that it's a good idea all of the time, something we inherently know to be false. Having said that, the term "best practice" clearly has more marketing value than the term "contextual practice", and in this industry we know that marketing typically wins over truth, something that is clearly not a best practice.

The Situation Context Framework (SCF) helps to provide insight into the context which IT teams find themselves in. It describes several factors which provides this context. The factors are:

  1. Team size. From teams of a few people to thousands.
  2. Geographic distribution. From people being co-located to being distributed around the world.
  3. Organizational distribution. From everyone working in the same org unit to people working for different organizations (such as outsource service providers, for example).
  4. Regulatory compliance. From being non-regulated to very strict regulation (such as FDA regulations, for example).
  5. Domain complexity. From very simple problems to very complex ones.
  6. Technical complexity. From greenfield single-platform systems to multi-platform systems using legacy systems and data.

The point is that different teams find themselves in different situations, different contexts if you will, and therefore will tailor their approach to reflect that situation. They will adopt practices which meets their needs and tailor those practices accordingly, particularly when provided with the process goals-based strategy implemented via tool kits such as Disciplined Agile (DA) .

Suggested Readings

Choose Your WoW! 2nd Edition This book, Choose Your WoW! A Disciplined Agile Approach to Optimizing Your Way of Working (WoW) - Second Edition, is an indispensable guide for agile coaches and practitioners. It overviews key aspects of the Disciplined Agile® (DA™) tool kit. Hundreds of organizations around the world have already benefited from DA, which is the only comprehensive tool kit available for guidance on building high-performance agile teams and optimizing your WoW. As a hybrid of the leading agile, lean, and traditional approaches, DA provides hundreds of strategies to help you make better decisions within your agile teams, balancing self-organization with the realities and constraints of your unique enterprise context.