Tailoring Agile Processes – Good Practice or Avoid At All Cost?

One of the most controversial topics within the Agile community is the practice of “tailoring”, which most simply-stated, is the process of customizing a specific Agile model or framework for various reasons. In my experience, some teams consciously modify the process for valid reasons, while many teams do so without understanding the impact and potential risks.

Some Agile purists feel that tailoring Agile processes should never be done no matter what. I’m not sure that I would agree with this view. The world is increasingly more complex, as are products and solutions we try to build. There may be situations where parts of a model simply don’t work or make sense. With that said, in most cases, teams should try to carefully evaluate the situation before making the decision to tailor an Agile framework.

Let’s take a closer look at this. Over the past few years, I have been called upon to help out with Scrum teams that are struggling with various parts of the project for different reasons. Many of the teams that are not effective in delivering value tend to share similar behaviors – they seem to struggle with basic mechanics of following basic Scrum practices. For example, in more than one occasion, a struggling Scrum team has decided to eliminate the Sprint Retrospective from their normal operation because it was deemed “a waste of time”. Instead of investigating why this practice was not adding value, the team chose the seemingly easier solution, which is to stop doing it altogether.

As Ken Schwaber, the co-founder of Scrum states in the Scrum Guide: “Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.”

This statement is very powerful because it explicitly declares that the Scrum framework is a cohesive unit that is intended to be applied as a single entity, and not to be de-constructed into something that resembles Scrum. You may be familiar with the phrase “the whole is greater than the sum of the parts”. This seems like a fitting description of Scrum, given that the framework as a whole functions together and can only be effective if all the individual components complement each other.

In the case of the Scrum teams that choose to stop doing Sprint Retrospectives, my advice to them was for the teams to explore how to make the Retrospective a meaningful and valuable experience, rather than looking for reasons to stop doing it. There’s a reason that millions of professionals apply Scrum on a daily basis – it is because it helps them achieve success!

My opinion regarding tailoring of any Agile process or framework is this – we should seek first to understand the reasons behind a specific practice being included in the framework before deciding that we don’t need it. Simply eliminating parts of a framework without understanding its purpose is like throwing away an oddly-shaped part of a large machine without knowing what it does, and then hoping that this machine will still operate as you expect. Perhaps if the team understood and valued the concept of inspection and adaptation, they would have explored different ways to execute the Retrospective and try to make it an integral part of their practice.