Rolling your own Agile

There is a common attitude that because frameworks like Scrum are Agile that you can basically modify it any way you want to fit your particular situation.

However, I think its important to point out that the “agility” being referred to is actually the frameworks ability to respond quickly to changing external factors. Using mechanisms like backlog grooming, sprints, etc. Not an inherent ability to change the framework to suit a given situation.

To take Scrum as an example, it doesn’t have a particularly large set of rules, however the rules it does have should be followed quite closely. That is, if you want to extract the most benefit from a process that has been carefully constructed and proven to work.

Ideally, if you have made the commitment to implement an agile framework you should be changing your organisation to fit the framework rather than vice-versa. Presumably you are going agile because something either no longer works or can be better. Scrum works when organisational change happens, not when the existing processes are re-branded with scrum terminology to sound agile.

Of course, there may be times when you outgrow the defined structure of your chosen methodology, I would argue that this only happens once your organisation has reached the highest levels of agile maturity. But, if and when this does happen, I believe that the best approach is to go back to the drawing board and build a process from the ground up that fits your highly evolved agile environment.

I recently discussed an example of a corporation who somewhat mangled ‘Scrum’ to fit the way they worked.

This time I would like to highlight a company who I believe totally nailed it when it comes to higher level organisational agility.

Spotify originally and very successfully used Scrum as their method of choice, however as their teams and tasks grew in size and complexity they realized that they needed to make some fundamental changes in order to maximize their productivity and happiness across a rapidly changing and expanding landscape.

One of the things that really put Spotify a cut above the rest was the re-branding that went along with this. They didn’t say this is our “modified Scrum”. They took what they needed structurally from Scrum and then built out an entirely new way of working basing their additions of the principles of the agile manifesto and how it intersected with their objectives.

Seemingly small semantic changes such as renaming sprint teams to squads and scrum masters to agile coaches were extremely effective in setting their approach apart and letting everyone know that, yes, we are Agile, but the process we use is our own. There can be no criticism of their implementation, only the opportunity for improvement, because they have created it in house by scaling agile concepts and building their organisational structure around it.

Here is an inspirational video series the Spotify engineering team released about their process:

Part 1:

Part 2:

Originally published at