After years helping companies to adapt their practices and change their mindset toward agile values, a comment we hear very often is “Ok, we know that we don’t follow the recommendations… But our context is quite singular and Agile/Scrum is meant to adapt to everything, right? Thus, we adapt it to our context.”. Unfortunately, it is not as simple as that!

Agile doesn’t mean adaptation to everything

Let’s first draw the relation between the Agile culture and adaptation. The Agile culture consists in a set of values. Accepting and facilitating change is one of these values. It comes from the observation that unlike other domains early software management took inspiration from, it is difficult to plan software development ahead and very unlikely that requirements, expectation, budget, delays, etc. will not vary a lot as the project goes on.

Among the many things that may change during a project, an agile mindset mainly helps anticipate and adapt to changes of delays, budget and functional scope (along with the underlying code). However, this is no magic and one cannot summon agile “we are agile, why don’t you adapt?!” each time an adaptation would be desirable.

Take a traditional organization, if it considers that agile must adapt to the existing values of the organization, then that is just putting an “agile” label on them, which is meaningless. If an organization wants to be agile, then it must adopt the agile culture and its values. This change, which is often called Agile transition, adoption or transformation, is difficult and has a significant impact on an organization as a whole.

Scrum to the rescue

One of the main goals of Scrum is helping in this process. This methodology is a framework that brings a common terminology and set of rules that make adoption of agile values easier by naming and legitimating practices that favor them.

Just as any framework, it is recommended that novice teams follow the rules. On the other hand, a mature team can bend them because it knows precisely why it is relevant to do so. Sometimes, that means moving from Scrum to a lighter and smoother workflow inspired by Kanban. However, an Agile team may need months or even years to reach this level of maturity.

Theory versus reality

Our experience told us that on the field it’s a whole different story. Disclaimer: this is not a criticism to any organization, but rather our observation of a phenomenon that has intricate roots and implications.

The majority of teams switching to agile do so in a context that is hostile to Agile values. In such case, practices involving a change of mentality are simply put apart in the name of adaptation in favor of “visible” practices (e.g. daily stand-up meeting, post-its, burndown, user stories instead of requirements…). Adopting these practices is a change, but it mainly impacts developers who then grow an aversion to “Agile” as they pay the price of change without any benefit. In the end, if such projects fails or gets delayed, Agile and Scrum are pointed out as the cause and it is concluded that “it doesn’t work”.

There is hope!

Make no mistake, I am not pessimistic and it is definitely possible to avoid this scheme! The first step consists in acknowledging the risks (that’s why we write this blog post!). Then, we really encourage you to reach out for external help through coaching and training (if your team is located in France, check our training services: https://www.icescrum.com/training/, we will be glad to help!). Finally, It is also essential to observe the practices provided by agile methodologies (it doesn’t have to be strictly by the book, but if you have to choose, focus on rules that trigger mentality change rather than the easy ones).

Cheers!