When you are a Scrum master or Agile coach you probably recognize questions like: “What does Scrum say about <random issue>?” On the one hand, it is a good thing that one tries to fall back on Scrum when encountering a problem. However, I regularly notice that when there is no apparent answer, the problem is blamed on the ‘incompleteness’ of Scrum. In the worst case they discard Scrum on the wrong premise, try to change the few rules Scrum has, or add layers and procedures on top.
Clearly understanding what it means that Scrum is a framework, is a necessary requirement to solve the perceived problem and achieve the true value of Scrum. The Scrum guide states that Scrum is “lightweight, simple to understand, but difficult to master.” I like to compare it to chess for that matter. It is easy to learn the goal of the game and the moves of the different pieces, but this does not make you a good chess player. Likewise, just knowing the rules of Scrum does not make you a good Scrum ninja. Let’s explore how one should tackle problems using Scrum.
So what does it mean that Scrum is ‘only’ a framework? To start off, it has few prescriptive rules: it does not prescribe any specific engineering practices, but does give some constrains like timeboxes, iterations and cross-functional teams. It mainly describes why and what, it sets boundaries but leaves very much room for filling in the blanks. Simply stated there are just three roles, five events and three artefacts (of four if you count the Definition of Done). Each element is in place for a specific reason and has a specific connection to the other elements.
Applying Scrum correctly to address complex problems – like many things – starts with a good understanding of the “Why”. Before one can break the rules, one must follow the rules. It is all about the three pillars of Scrum: transparency, inspection and adaptation. During the Sprint Retrospective the Scrum teams inspect and adapt their processes and interactions. The Sprint Review is in place to inspect the product and adapt the Product Backlog. The Daily Scrum aims to inspect progress towards the Sprint Goal and adapt the Sprint Backlog. Scrum as a framework does not prescribe how to develop, refine or do release planning– it just makes it clear (transparent) where the pain is and where a team or organization needs to improve (inspect & adapt).
You don’t make up new chess rules because you cannot win. You need practice to become good, and you might need coaching to become an expert. Use Scrum as is. Do not adjust it when you walk into problems. Use Scrum to make your team and organizational problems visible and address them with an Agile mindset. Use the strength, knowledge and creativity of the teams to solve those problems. Don’t try to implement pure top-down plans or procedures as a safeguard in a command and control manner, but instead support your teams in finding solutions and overcoming these problems. Make use of good practices that complement Scrum and the Agile principles. Experiment and continuously learn to become better.
When you encounter problems, address them in the Scrum events. Visualize the problems to make everything transparent, inspect the cause and adapt by using the power of the people.
If you are looking for training related to Scrum or Agile, or need coaching to help overcome problems in this context and become a more responsive enterprise, you can always contact me or my colleagues.