Has Scrum made us forget what is Agility?

According to Ken Schwaber, in 2009 about 84% of the organizations using Agile processes were using  Scrum.

However most people using Scrum were in fact using what was described by Martin Fowler as Flaccid Scrum. That is to say: inadequate variants of Scrum which were not yielding the full benefits of the methodology (when not actually making projects worse).

Now that we stand 4 years later, the figures are probably even bigger and the number of Flaccid Scrum even greater.

Scrum has been widely embraced in IT projects. And, indeed, that's quite understandable. Scrum methodology is lightweight, easy to understand and easy to practice. When compared to industry heavy methodologies such as PMI practices, Scrum offers a breath of fresh hair most welcome by project managers.

More and more often when we speak of Agility, we tend to really speak of Scrum. The line between the two is increasingly getting blurry.

This is problematic as it is easy to fault the whole of Agility for badly executed Scrums.

Scrum became dangerous to Agility as it was used by more and more people not knowing Agility in the first place.

Agility is a state of mind (for some it's even a philosophy), it is not a tool or process.

No tool will ever make you Agile, it is the way you look at things that will.

Scrum is a framework for project management. 

It is nothing more than a tool. Scrum, by itself, is not inherently Agile. 

As all tools it won't work if not used properly.

Following Scrum, even when done perfectly, does not make you Agile.

When starting on the Agile journey, you first need to understand the philosophy before learning how to use the tools.

If you want to get the full benefits of Agile tools, you need to understand their purpose. 

To learn that, you need to know what are the roots of Agility.

It would be easy to limit the roots of Agility to the signature of the Agile Manifesto in 2001.

That would be forgetting why experts met in the first place.

People only remember outcomes, not the path to discovery.

When the experts met in 2001, software development was getting more and more complex. 

With increased complexity, the rate of project failure was becoming higher.

Although improvements had already started (Scrum was initially published at the 1995 OOPSLA conference), software development project methodologies were still largely based on project methodologies initially developed for industries (such has the infamous Winston Royce waterfall model, which incidentally he never recommended). 

We were using methodologies suited for stable environments in an unpredictable world.

So the question that guys behind the Agile Manifesto really wanted to answer was:

How do you lead a project in a complex environment?

That is, how can you drive a project in a fast changing environment when all parameters become unpredictable?

In unpredictable contexts, traditional project management proves useless. It only offers techniques to increase predictability and can never be 100% successful.

The only thing you can do is to adapt to new events you couldn't predict. And you want to do so the fastest you can so that it doesn't cost you.

The purpose of all Agile methodologies is to increase your adaptability to change so that the impact of unforeseen events remains constrained.

Scrum is in fact trying to offer a framework that will make it easier, quicker and less costly for you to adapt to change.

For instance, the Daily Stand-Up is nothing but a tool to increase communication, so that you know about change the minute it occurs.

If, in the Backlog, you prioritize tasks according to their added customer value, it is in an attempt to keep project costs at their minimum. This way, if you need to change your plans (and you will), you won't be throwing away work you could have dispensed to do.

You could find similar benefits for all components of Scrum. One way or the other, they all help putting the project in a situation where change is easy, quick and not costly to make.

Now, it's pretty easy to understand why most Agilists recommend the XP practice of tests automatization.
Indeed, it's the best way to decrease the cost of quality when change becomes the norm.
With automated tests, your full work can be instantaneously checked. Defects introduced by change can be spotted at next to no costs.

In the end, I'm not saying we should never adapt Agile practices or that we should follow them all, quite the contrary.

As we've seen, in a complex system, you want to increase your adaptability and that includes adaptability of your tools.

What is important, is that you adapt your tools for the good reasons. 

Today, people look towards Agile methodologies as a way to increase productivity. 

Remember that at the heart, Agility is not about being more efficient.

The winnings in productivity (or costs) are only byproducts.

It is because you diminish waste (by being better suited to the environment) that you are faster, not because you increased the pace of execution.

So if you are looking at adapting Agile methodologies for productivity reasons you are probably getting it wrong (chances are you'll diminish your adaptability to change).

But if the adaptation you want to make actually makes embracing change easier, faster or less costly, then, by all means, feel free to do so!

"Science sans conscience n'est que ruine de l'âme" Rabelais, Pantagruel
"Science without conscience is nothing but the ruin of the soul" Rabelais, Pantagruel

Credits: Anthony Gatto by Dirk Franke