Reality is messy. In its entirety, this world is too complex, to allow us humans make any sense of it. It is a scary thought, as we necessarily need to aknowledge that we are not in control of our own fate in basically all circumstances. One way we try to handle this chaos, is by coming-up with theories, models and frameworks that help us structure and therefore handle at least a tiny part of our lives. These frameworks are representations of the reality, but never complete. Similar to a map. A map helps navigate the streets of New York City. But a map doesn’t replace actually being in New York City where a map quickly might turn out to be a poor representation of the reality. E.g. when I discover that roads are blocked or subway stations closed for whatever reason.
In the New York case, every sensible person would shrug their shoulders and simply look for a different path the intended destination. When it comes to management and delivery frameworks however, it is a common issue that we insist on force-fitting everything into a single framework.
A great example for this is Scrum. The agile methodology which certainly helps millions of companies to embrace the advantages of agile software development. One of the reasons Scrum has been successful is, that it is:
- Quite simple. The entire manual is 14 pages of concise writing.
- Instructive. The manual is not philosophical grand opus elaborating on pros and cons and the intellectual backbone of the ideas. It tells you exactly what to do and doesn’t waste much time explaining why.
Maybe it is the contrast of Scrums simplicity to the otherwise complex environment that lead to Scrums popularity. Agility in software development as well as in business in general is by definition complex as its core is about handling a complex environment (you know…VUCA ?). Trying to wrap ones head around, how to manage and navigate in that environment can feel quickly like boiling the ocean. So clinging to a framework like Scrum which seems to be validated feels very comforting.
A role that is supposed to be introduced with Scrum is the role of a scrum master. The defintion of the role of the scrum master starts like this.
The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.
Official Scrum guide
The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the
Scrum Team to improve its practices, within the Scrum framework.
I’ve written before on the importance of autonomy and empowering teams to make their own decisions. Even though this is very much aligned with the agile principles, I feel like the definition of a Scrum Master’s role is an betrayal to those principles. A scrum master is there to teach and coach about Scrum as defined in the Scrum guide and the team is allowed to improve within the Scrum framework.
Dare you to deviate from the framework and its definition and you shall feel the wrath of Ken Schwaber and Jeff Sutherland.
Given this very prescriptive role definition I have seen the nicest persons turning into the most obnoxious and anal-retentive persons I had to work with. Discussions were cut short with the argument „because the Scrum Guide says so“, any questions for the „why“ were punished with a look that declared me a heretic, but were left unanswered. Those people turned into true Scrum-Nazis as they felt empowered to enforce rules a higher authority created and which shall not be challenged. Whenever my pragmatism kicked in and made me do something to „get it done“, I lived and worked in fear that this minor infringement would fill out the entire time of the next retrospective, leaving all the really pressing issues unanswered. While the purpose of the Scrum master is in opinion good, I have experienced way too many people becoming too rigid when it comes to rule adherence.
Scrum is a framework that is supposed to help us working together in a complex and dynamic world. And I think it is a great starting point for a lot of teams, but it is only that: A starting point. Depending on the context a team works in, it can make absolutely sense to eliminate parts of Scrum or add new things to it. In that moment your favorite Scrum-Nazi will start bitching „Well then you are not doing Scrum!“.
So what? Scrum in itself is no end. Building great products is the goal not adhering to a predefined process. The irony is, while Scrum is preaching evidence based management (of which I am a fan myself), I have seen basically no company which adhered 100% to the Scrum guide. And the company that came closest to it, was absolutely the worst I have seen when it came to delivering products.
The optimal way to use Scrum personally is as one framework out of many. I’ll turn to the Scrum guide with questions on how we might design the planning process or define certain roles whenever I feel the need for improvement in those areas. But I will only implement it when I believe that this will solve the problem based on the reasoning. Not based on an ideology. The irony is, that the Scrum guide itself is pretty loose and would leave room for flexibility. It seems to be the agile community that shares „best-practices“ and eventually encouraged my Scrum-Nazis to forecefully push addition „planning II“ and „refinement“ meetings down my throat.
In the last months my team has grown eightfold and we needed to fix a lot of processes. From planning with stakeholders to better refinements and a cleard definition of done. As FINN doesn’t see the need to hire Scrum Masters and Agile Coaches, I needed to figure this out together with my team by ourselves. This didn’t result in chaos. It resulted in a team that truly feels empowered as everyone got a say on how we work together. It fostered a culture of learning as we were open about trying new things which where neither absolved by Scrum nor had any other evidence that it would work. But we were open to try and change later in case it doesn’t work. I used ideas from LeSS, Basecamps Shape Up and Scrum. And it works – for us. People are aligned, feel empowered, are engaged and velocity is picking up.
And best of all, nobody is scared about not adhering to a framework. Framworks are there to support. Not to be oppressive. Whenever they are – ditch them.