The Value of Prescriptive Frameworks in Agile
Scrum is prescriptive and rigid. But despite its faults, it does provide the most effective way to start an Agile journey
I once introduced Scrum at a startup. The whole company was enthusiastic about working with Scrum. With one exception. The lead developer, the one person whom I thought would gladly embrace the framework, was emphatically against Scrum.
I was very surprised. In his own way, he was already quite versed in the important parts of Scrum. He collaborated effectively with stakeholders. He was acutely aware of the need for value. He was very good at organising his work into manageable parts. He was continuously pushing everyone to evaluate things and learn from their mistakes. He even had this way of drilling management about the essence of their wishes, refining a clear goal for himself.
Eventually, I realised the problem: for him, his way of working was so obvious that he strongly resented the prescriptiveness of Scrum. All the rules and formal meetings felt highly inflexible to him.
For me, this was an important experience because it got me thinking about Scrum from a temporal perspective. How does the purpose of Scrum for a Scrum Team change over time? What happens when people are so Agile that Scrum starts to get in the way?
Getting Scrum to work in a team had always been the goal I was striving towards, and I had never stopped to think about the possibilities of diverging from Scrum, let alone what would happen after Scrum. Sure, sometimes some compromise is necessary, but I always saw Scrum as the ideal to aim for.
I suddenly got caught in a train of thought whereby I realised that the only logical conclusion of any Scrum implementation must be the team eventually leaving the framework behind.
This realisation has everything to do with Empiricism. Empiricism plays a crucial role in Scrum. You might say that it lies at the heart of Scrum. And, assuming Scrum is running smoothly, because empiricism ensures that improvement never stops, it is only logical that a team will eventually find solutions that grow beyond those prescribed by Scrum. After all, even the Scrum Guide presents Scrum as a purposefully incomplete framework. So theoretically, if you wait long enough, as the team gradually accumulates improvements, it should reach a point where their process is no longer recognisable as Scrum.
In contrast, looking at the other end of the spectrum, I realised why Scrum is so prescriptive, and why the Scrum Guide stresses the importance of adhering to the rules expounded in it. It is simply because this is the most effective way of starting out on the road towards becoming Agile.
Imagine an established company with an enlightened leadership. They have decided they want to become Agile. They have read the Agile Manifesto, the Scrum Guide and done some further research. How should they go about translating all this into an effective way of working?
In my own experience, what they usually do is pick elements of Scrum and adapt them to their established way of working. Start with bits and pieces, to see if it works. The results are usually painful. But how can you blame them? A company is not going to adopt a completely new system out of the gate. Even if it says so in the Scrum Guide. It is often simply too much of a challenge for anyone new to Agile to be able to grasp the whole thing right from the beginning.
Getting back to the start-up I started this article with, they did exactly that: with all the best intentions they translated Scrum to their situation creating something which was, to put it mildly, very original. Inevitably, this approach created a mess, and they hired me to get their Agile transition back on track.
And this is the typical situation where the Scrum framework really proves its worth. It provides a set of rules on which a Scrum Master can always fall back. Any discussion heading towards endlessness and decision paralysis is easily solved by saying: “it says so in the Scrum Guide!”.
As a devoted Agilist, it goes against my convictions to accept this as a positive thing, but the bottom line is it works. It gives us the power to convince the company to accept a certain way of working until they learn to understand it and see for themselves that it really works.
It is the combination of a powerful voice for change and a set of clear rules which allows companies to take the plunge. This critical duo is provided by the experienced Scrum Master and the Scrum Guide.
The Scrum framework is so well thought out that it really provides an effective structure that can be implemented immediately.From this basis, teams can start by just going through the motions, applying Scrum and kind of doing Agile even though they might not understand what it is.
It gives them time to gradually discover the different aspects involved. And in the meantime, they, and management are happy because even though there is some disruption, it works. From the very first sprint, it brings structure and results.
Scrum has the advantage that, even at the Zombie Scrum level, it brings positive things like increased transparency, better collaboration and improved project management.
For me, it reminds me of learning math as a kid. I studied theoretical mathematics, which involved a lot of playing around with numbers, with absolutely no idea what it was for. Motivation came from getting good grades.
Eventually, I went to University to study biology and what a surprise it was when all those mathematical techniques suddenly came together and proved extremely useful! At the same time, I noticed many of my fellow students struggling because they were too busy learning the basics to understand the practical application.
Sometimes you learn something by rote, without understanding its purpose, simply because you can only understand the purpose when you have become proficient enough with its application. This is the “Shu” level of learning in the concept of Shu-Ha-Ri.
My experience leads me to conclude that prescriptive frameworks like Scrum are extremely useful to get started with Agile. Without them, Agile transitions would be much more challenging, maybe even prohibitively so. Our worldwide movement towards Agility might not even have been possible without Scrum.
The prescriptiveness of the framework is simply essential to provide a clear way of getting started and to avoid getting lost in endless discussions of merits and problems, ending up in decision paralysis.
But that is also where it stops. Scrum is a fantastic framework to get us started in our Agile journey, and that’s it!
We put so much effort into trying to make Scrum fit the ideal we are pursuing. Endless semantic discussions and interpretations of the meaning of the Scrum Guide, like scholastic monks sifting through the bible. With a lot of self-doubting and second-guessing on top!
Maybe simply having the experience necessary to be able to discuss the meaning of the Guide proves that you have outgrown the framework? I think that at this point the important discussion is no longer whether what we are doing is Scrum or not, but how Agile are we?
If we agree Scrum is only the start, we can separate the two discussions into their separate contexts, making them so much more meaningful.
Think of it as a building. Agile is the building and Scrum is the framework. During construction, the building is completely obscured by the framework. Gradually, as the building nears completion, the framework starts to disappear. And finally, on the day the building is delivered, there is no sign of the framework. It has been completely removed, simply because the building stands on its own.
Our ultimate goal as Scrum Masters should be to proudly help our teams to grow beyond Scrum. Our ultimate badge of success should be to be able to tell the team:
We have left Scrum behind us! The process is now completely yours! You have the wisdom to do with it what you will!