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, given the space necessary to make that natural and efficient.
Only when we have this understanding do we create rules and structures, seeking to formalise and enforce that 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 realize that the Scrum framework is, a process. A framework for a process to be exact, but nonetheless, a process. The fact that companies are actually able to adopt Scrum literally and without modifications proves that it is a process. This will typically end in disaster of course, but the actual outcome of a process does not play a part in defining 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 improve it.

Lets 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 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.

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.

I think that the beauty of Scrum lies in the fact that it is designed to channel our innate ability to continuously improve processes, towards the challenges we face in our work. And just like my recipe for hammering a nail, it 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 why we see the 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!

So, to be practical a process needs to to be clear and simple, and 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 empirically, 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, lets 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.
And 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, and Agile in general. 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 do our work the way the boss tells us to do it - that seems to be the default? Processes are laid down for us and we are expected to follow them. We are conditioned to accept the processes without thinking. This sadly 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 work; our behaviour and our attitude. Scrum is indeed a process, but when you approach it from an Agile perspective, it is only one piece of the puzzle, one of the tools we use to achieve that mindset.
Agile makes us take ownership of processes. 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.

It is important to realise that every single aspect of the Scrum framework can be done without. For example, the purpose of the stand up 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 the stand up becomes obsolete.
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 realize this, it completely changes the way you work with Scrum. You realise that you have to be critical of everything you do. And you discover that 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!

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 was 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. I might have expected the team to drop everything an 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. And 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 our offer of a team of developers to help out, settling for 3 developers, citing that that was the sweet-spot for increased productivity against increased overhead,
• set two developers to direct and manage the new recruits,
• assigned the “easy” stuff to the other team,
• planned the remaining complex work for the remaining team,
• tweaked their process to maximise productivity while at the same time managing technical debt.

They pulled it off.