Why is Scrum a Process?

Or, perhaps more accurately, why is it so easy to use it as a process?

In the Agile Manifesto, the first line is “Individuals and interactions over processes and tools”. The way I interpret this is that we should first endeavour to understand the way people communicate and work towards a common purpose, giving them the space necessary to make that natural and efficient.
Only when we have this understanding should we create rules and structures, seeking to formalise and enforce that particular way of working.
In other words, processes and tools follow from the needs of the people carrying out the work and are meant to evolve with those needs.

Considering this then, it is quite surprising to realise that the Scrum framework is a process. Sure, it is defined as a framework, but it is formulated as a process. The fact that companies are actually able to adopt Scrum literally and without modifications proves that it can be used as a process. This will typically end in disaster of course, but the actual outcome of a process does not play a part in defining whether it as a process.

To be clear, processes are not a bad thing. In fact, they are an integral part of our lives. In all that we do we create processes for ourselves, simply because it is the most effective way to learn something, to remember it. And once you can remember something, you can understand it and improve it.

Let’s take a very simple example of a process: the process of driving a nail into a piece of wood with a hammer. If you see a child doing this for the first time, you will probably spend most of the time cringing, waiting for the hammer to hit the child’s finger instead of the nail. But we all have to start somewhere. The child is taking the first step to creating a process, a process she will keep improving for as long as she keeps banging at nails.

My 2.5-year-old daughter creating her own hammer-and-nail process. No children were harmed in this photoshoot, though I did hold my breath for most of it.

Think about your own process for this activity. Here is mine:

1. hold the nail at a precise angle,

2. hit it with the hammer at a specific speed and angle,

3. repeat until the best moment to remove your fingers,

4. continue hammering, compensating for the fact you are no longer holding the nail,

5. stop when the nail is driven in completely.

Think for a moment about how this process came to be. Starting as a child, practising, gradually tweaking the process, especially when you smashed your fingers. Or bent the nail for the @#$%& time.

source: Oxford Dictionary. The definition of a process.

I think that the beauty of Scrum lies precisely in the way that it is designed to channel this innate ability we have to continuously improve processes, to solve the challenges we face in our work. And just like my recipe for hammering a nail, the Scrum Guide is clear and simple about the principles that matter: “hold the nail at a precise angle”, leaving the details: “what angle?” vague.

But why is that?

We have to hold the nail at a specific angle, otherwise, the nail will bend. The angle depends on a myriad factors such as strength, size, the type of wood, the kind of nail… I could try to work out all the details myself, for the whole process. But then, instead of a simple list of five points, my process would become a thick scientific paper, full of formulas, models, and diagrams. Sure, great fun to write, especially if you have a research grant, but rather impractical for anyone just wanting to get a nail into a piece of wood.

Incidentally, this is one of the reasons why we see waterfall project management fail for complex projects. You have to admire the breathless optimism: to think it would be possible to foresee all aspects of a project and be able to create a complete process for it!

To be practical, a process needs to be clear and simple. And it must leave enough room for us to adapt it to our needs and improve it continuously.
I think that that last point is the key to the effectiveness of processes. The practising and tweaking to continuously perfect it. The process becomes ours, and we modify and adapt it as we see fit. Either deductively, by considering the consequences of our choices, or inductively, by learning from the results of our choices.
Why not combine it with another process? Or chop some stuff out? Or turn it on its head? Go right ahead! Modifying the process becomes a fun, creative activity that is also great for our self-confidence.

To illustrate this, let’s go back to the hammer and nail. Have you ever driven a nail into a piece of wood with something other than a hammer? Say a beer bottle? I have, and I learned very quickly to modify the strength with which I hit the nail, to avoid breaking the bottle. Imagine the coolness factor, surrounded by your friends, as you nonchalantly hammer away with a bottle!

I would venture to say that herein lies the greatest challenge for implementing Scrum. Unlike our personal processes, which are very clearly ours, and for which we never hesitate to tweak and improve, we often do not feel we own the processes we use in our work. This is a cultural and social pattern that we are often unaware of. We learn to do our work the way the boss tells us to do it. We are merely cogs in a great machine.

source During the industrial revolution, the idea that an elite could create very efficient processes that should be followed to the letter by workers, culminated with Taylorism. Charles Dickens’s novels describe the social impact this had, with workers referred to as ‘hands’.

Processes are laid down for us and we are expected to follow them. We are conditioned to accept the processes without thinking. And sadly, this often applies to the Scrum framework too.

And that is why “Individuals and interactions over processes and tools” is so important. It defines Agile as a fundamental change in the way we look at work: our behaviour and our attitude become more important than the process.

Scrum is indeed a process, but when you approach it from an Agile perspective it is only one piece of the puzzle. It is simply one of the tools we have at the disposal of our Agile mindset.

I think the Agile mindset allows us to take ownership of the processes we use. It makes us accept that a process is never perfect, that there is always room for improvement. That is the reason why Scrum is presented as a framework. Because it is up to us to adopt it, adapt it, and continuously improve it.

This may eventually even involve leaving out certain parts of it. For example, the purpose of the Daily Scrum is to force us to manage a sprint. But if a team is so proficient in their communication that they are continuously managing the sprint, then they may decide to skip it.
Even something so seemingly essential as the role of the Product Owner can become obsolete. In fact, there was a recent discussion about this very subject. Check this link out for the initial idea, and this one for a counter-argument.

Why is this important? Because when you realise this, it completely changes the way you work with Scrum. You realise that you have to be critical of everything you do, including Scrum itself. Scrum is not about doing proper Scrum but is meant to“continuously improve the product, the team, and the working environment”, as the Scrum Guide itself puts it.

In essence, what is important about the Scrum framework is not enforcing the rules, but rather, the purpose behind all the rules.

Every single aspect of Scrum is trying to coax us to do something differently. Understand what that is and you understand how the system works. You know what to watch out for when you make changes and can handle accordingly, to direct the change process. You can properly adapt to changing situations. This is being Agile!

source A definition of Agile. It is all about a mindset and a way of thinking, with no mention of processes.

A striking example of this is something that happened to me recently. A team had run into serious trouble with a project, due to a miscommunicated deadline. There were at least 3 sprints of work left, but the client had to go live in 2 sprints.
I literally told the team to forget Scrum and focus on getting the job done. This was quite a shock for the team, as I had been coaching them for the past 3 years to adopt Scrum. I might have expected the team to drop everything and just start programming like crazy, but instead, they had a meeting. The meeting lasted 2 days. They considered all their options and brainstormed all possible solutions. When they finally came out they had a plan where they:

• had pruned the backlog, removing anything unessential,

• split the remaining backlog into easy stuff and complex stuff,

• rejected my offer of an extra Scrum Team (6 developers) to help them out, settling for only 3 developers from the other team, citing that that was the sweet spot for increased productivity against increased overhead,

• set two of their own team members to direct and manage the developers from the other team,

• assigned the “easy” stuff to the developers from the other team,

• planned the remaining complex work for themselves,

• tweaked their process to maximise productivity while at the same time managing technical debt.

They pulled it off. They displayed complete ownership and a very clear understanding of their own process. This enabled them to bend the Scrum rules where necessary and tweak the process at will to create the best solution for a serious problem.