Things you (probably) misunderstood about Scrum…
Most of my professional experience is from working with a tech startup, where the word Agile was thrown around a lot, and we oscillated between sprints and kanban and had some semblance of Scrum, but no formal education (I have a theory that L&D budgets never get used up in the fast-paced startup environments), and naturally there were some things I misunderstood about Scrum. I hope to share what I learn here in case others are along the same journey too.
Scrum is a Framework not a Process
Scrum is not prescriptive — it provides a starting point for teams to set up their own processes. Think about it as more of a set of guidelines or heuristics, than a step-by-step play.
In my head, it’s a little bit like the difference between cooking and baking.
Patisserie is Process based.
I used to bake macarons and sell them from my home kitchen, and while lots of people would think that is quite a feat, I actually thought there was nothing much to it. At that time I had worked in a science laboratory for a few years and following a recipe was pretty much the same as following research protocol. You do the steps in exact same order, using the exact quantities, control for your environment, and you expect to get the same results each time.
Cooking is more a set of guidelines.
I once had a friend who just started cooking and read in the instructions “Cook for 20 mins or until meat is cooked through”. He decided to stick to the 20 mins even though he had sliced his meat much thinner than the instructions had asked for, and a room full of more experienced people told him that he didn’t have to wait for the full 20 mins. Everyone who has done some cooking knows that in cooking, there are more guidelines than processes. For example, if you want more flavour in your meat, you have to first brown it before you stew it.
Scrum is like a recipe for creating Products. It’s the starting point which illustrates the guidelines and introduces concepts so that you don’t have to start from scratch.
One reason why it is not prescriptive is that Product development is generally in the complex domain of the Cynefin framework.
Let’s take a closer look at the Cynefin framework, which is a sense-making framework created by David Snowden.
Simple/Obvious situations are when the cause and effect is well-known. If you do X, you will get Y. In this category of problems you first identify what the problem is (Sense), find out the best practice approach to solving the problem (Categorize), and then carry out the steps to fix(Respond). This is the realm of Best Practices.
Complicated problems are when cause and effect exists, but not yet well-known. Therefore, in this case, we first have to identify the problem (Sense), then do some analysis to figure out what the cause and effect is (Analyse) and then apply your learning to fix the cause (Respond). This is the realm of Good Practices, and where identifying a solution requires expertise.
Complex systems are without cause and effect — this is where most Product development (and other innovative) work lies. There are many unknown unknowns, and thus you first have to come up with some hypotheses and test them using experiments (Probe), then use the results from the experiments to clarify and determine if there are cause and effects (Sense), and only then you can choose what to do next (Respond). This is the realm of Emergent Practice. The diagnostic and the intervention happen in parallel in the same action, and we learn while we do.
Chaotic systems are when there are no known cause and effects, and also no constraints because they are usually a complete novelty. Think about it as a situation where are just too many hypotheses, where hypotheses from two completely opposite viewpoints are both probable. Here it is best to start creating the boundaries and the constraints by simply acting (Act), then come back around to gathering data to make sense of the situation (Sense) before refining the next actions (Respond). This is the realm of Novel Practices.
Disorder is simply where you have no idea which domain the problem/situation is, and therefore there is strong likelihood of taking the wrong actions, or perhaps taking no action at all.
Back to Scrum.
Misunderstanding — Product development is Obvious/Complicated. There are best practices or good practices that exist, and that is what Scrum is.
Clarification — Product development is Complex, Scrum is a set of enabling constraints/guidelines to help you navigate the complexity of the domain.
I like how David Snowden expressed it in the following words.
“Experts can be trusted in their areas of their expertise if the situation is complicated, but in a complex domain they can only create hypotheses. And the danger is, a lot of hypotheses are wrong. There’s nothing wrong with that, it’s the nature of the system. The trouble is, if we believe a complex system is complicated, and the expert gets it wrong, we lose trust in expertise.” — David Snowden
Scrum is founded on empiricism. Empiricism is just a big word that means you take action, learn from that in order to take better actions (sounds a lot like Probe, Sense, Respond, right?)
In Scrum the “processes” of the Sprint planning, Sprint, Sprint Review and Sprint Retrospectives sound like they are prescriptive, but in fact they are designed to be used like guidelines. Each of these “events” carry with them the opportunity to be transparent, to inspect and to adapt.
Adaptation is mandatory in Scrum. If Scrum was a process, it would be a process to help you adapt better.
Back to the cooking example. If you haven’t cooked before, or failed in the past, a recipe is good for you to follow to get started. You may not have known that you needed to add the cream at the end else it will burn, or that certain ingredients take much longer to cook and need to be pre-prepared. Every time you cook the same dish though, you will learn something. It may be that you learnt that you used too much salt the last time, or not enough herbs for your liking, or maybe the portion was too big or too small. Next time you cook, you will adapt that. You may even choose to mix it up and swap some ingredients. But there’s a high likelihood that the guidelines that the recipe provided you would be largely unchanged — and that’s what Scrum is meant to be like.
I’m fairly new to writing and so I welcome any comments on whether you agree/disagree, found this helpful or have other topics you wish to read more about. In the meantime, happy product developing and/or cooking!
