Mandatory Change Never Works in Scrum

 in SCrumIn many organizations, I see Scrum not producing its anticipated value. The concept of value varies across organisations, but there is also a universal anticipated value of Scrum.

The Scrum Guide says about Scrum's purpose:

"A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value."

and

"Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment."

In summary: Scrum intends to deliver "Done" valuable products and provides continuous improvement.

How successful is your Scrum?

Ask yourself how successful your Scrum is in reaching those two objectives. Take a moment. Do it now before reading on.

Now that you have made a judgement, ask yourself what your "successful" is based on. I see Scrum excel in fulfilling its promise everywhere.

But in many cases, Scrum is delivering on a promise that was not anticipated when adopting Scrum. People might expect Scrum to deliver twice the value in half the time. To their surprise, though, they experience Scrum as a framework that is difficult to implement and causing problems everywhere.

Many organizations are not ready to cope with this harsh reality and cannot value the revealed problems as opportunities for learning and improving.

Blaming Scrum for not working and creating workarounds for complex systemic problems instead of solving them is a realistic option to many. By consequence, teams will ultimately abandon Scrum in such environments.

Why are people showing this evasive behavior? There are lots of reasons, but at the core I see a forgotten requirement for Scrum (or agility in general) standing out:

The agreement to work with Scrum

In many cases, I see agile transitions being inflicted on the people using command and control by management. People are told to work in Scrum teams and told to have their ceremonies by inexperienced Scrum Masters and ignorant management.

It makes sense that organizations introduce change using practices they are accustomed to, but in the case of agility, this approach is destructive in the long run because enforced change never works.

Everybody changes all the time in their personal lives. We might want to change cars, houses, jobs, etc. Voluntary changes never feel bad because we want them intrinsically and so we agree to them.

But when someone tells you that you will be transferred to a branch on the other side of the world, or to another team, it might no longer be fun because it was not your voluntary choice.

What is more important: You did not agree to it.

Change that is imposed upon us is not sustainable. Mandatory change never works. Craig Larman formulates this as "owning versus renting": With involuntary change, we do not own the change; we rent it.

Voluntary change is rooted in agreement

When we help people to reveal the dynamics of their system and then guide them to explore unknown territory to decide how to deal with these issues, the change will come from within and will be built upon the agreement that a change is needed.

Using the same principles, we can can come to agreement should we adopt Scrum. With this approach, people will own their change towards Scrum instead of renting it.

In situations where we scale Scrum (which is the default), we should not forget the importance of the initial underlying agreement to the Scrum adoption:

The first team that started a Scrum experiment had a strong conviction and team agreement to apply a new way of working.

The people who will later be introduced to a new way of working need to voluntarily participate and share the underlying agreement for Scrum to make it work. With LeSS adoptions, voluntary participation is one of the framework's three adoption principles.

When we want to scale Scrum successfully, we also need to scale its agreements, or else our attempt to scale will fail, regardless of the scaling approach we choose.

You may also like: Common Mistakes When Scaling Scrum

When we agree to adopt the Scrum framework, we agree to a large number of explicit and implicit agreements. Each and every one of these agreements are required to make Scrum work. Understanding which agreement is not met and in what way it impacts you can help us to fix our Scrum.

Agreeing to work with Scrum means...

We agree to the Agile manifesto and its twelve principles. They are fundamental to Scrum. The Agile manifesto should be known by all and understood by everybody in the team and in the whole organization. Not understanding or knowing the Agile manifesto will allow for opposing beliefs and will create an environment where Scrum cannot be successful.    

We agree that reality is too complex to be captured in a fixed set of requirements. A complex environment cannot be captured in a finite list of requirements but needs adaptation to change to be incorporated. Not agreeing with this will lead to wasteful meetings trying to optimize and capture reality in endless designs, user stories, etc.

We agree we need to adopt empirical process control to deal with complexity. We need to probe, assess, and respond to be able to adapt to change. If we do not embrace empirical process control, we cannot use empirical data to pivot and refocus on the newly discovered reality. Reality cannot be captured in a finite list of requirements. 

We agree to adapt as soon as possible. As soon as we detect a problem, we fix it to minimize the possible damage. Postponing the change will allow for more waste to be produced. This is not in line with key Lean principles at the foundation of Scrum.

We agree on a common language referring to the process. We need to use the correct wording for the roles, events, and artifacts to be able to communicate effectively about our process. By doing so, incorrect language can be detected, by which incorrect beliefs and mental models can be detected. This is key to aligning everybody to adhere and understand our shared goal, values, and vision.

We agree to honour commitment, courage, focus, openness, and respect. The Scrum values are key to create an environment where empiricism can be applied. Without living according to these values, we will not be able to transparently inspect and adapt.

• If we are not courageous, no change will ever happen. If we are too courageous, we will not be respectful.
• If we are not respectful, we will not be able to build a team that can solve complex problems. If we are too respectful, we do not challenge the status quo.
• When we are not committed to Scrum, empirical process control will fail. If we are too committed, we get tunnel vision and lose flexibility.
• When we do not have focus, we cannot finish things and share no goal. If there is too much focus, we lose flexibility.
• If we are not open, we cannot be transparent. If we are too open, we will lose focus on what is important and create confusion.

We agree to be transparent. Without transparency, our adaptations will not be the right ones. We risk applying changes that will not contribute to delivering more value.

We agree to inspect frequently. We inspect the people, the work, the process, and the product continuously. If we do not agree to inspect, we can no longer empirically control our process.

We agree to adapt and improve continuously. Kaizen needs to become a way of life. Without it, we will no longer adapt to our ever changing surrounding.

We agree to deliver a working product every sprint. Scrum's primary goal is to deliver a done increment every sprint. If we do not agree to pursue this goal, we lose the opportunity for inspection and adaptation and we introduce the risk of building the wrong thing.

You may also like: If We're Not Delivering Working Software, What's the Point?

We agree on the product definition and vision. The product owner formulates and communicates a product definition and a product vision so that the team members and the stakeholders understand it. The Scrum team also needs to support this vision and purpose. When development team members do not agree with the Product vision, they do not respect the responsibilities adhered to that role. This will lead to wasteful discussions and will withhold the development team member from taking decisions autonomously.

We agree on a definition of done. The primary purpose of Scrum is to deliver done every Sprint. Team members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of "Done" for the Scrum Team.

We agree to honor all time-boxes. Parkinson's law is at the basis of using time-boxes. If there is more time available, the more work will emerge to fill that time. Hence, limiting the time available will increase productivity.

A common myth is that time boxes are interpreted as fixed meeting lengths. This is not true. A timebox sets a maximum amount of time available for an event. If it ends earlier, in most cases that is OK. By agreeing to honor time-boxes for the scrum events, we will learn to improve to make our work fit into these timeboxes and question ourselves what is wrong if we fail to do so.

And by doing so, we agree to let the empirical process control mechanism show us what we need to improve. Example: We do not add a couple of days to the sprint to meet deadlines; we let the sprint end and investigate what was not finished and why this occurred. This inspection provides learning. Adjourning the sprint does not.

We agree that we can only make decisions based on what is known. Predictive management fails. Management based on assumptions fails. We need to stay close to real data to base our decisions for altering our course. If we source our activities based on a prediction, we are excluding change to alter our plan; we become rigid and chances of delivering value degrade.

We agree that learning comes from experience. Knowledge can be acquired by studying books; however, we agree that experiential learning is essential to Scrum: We need to learn by doing. This is because building theories on what might happen is not delivering true value. Actioning on an experiment and verifying its outcome does. Not agreeing on this excludes the need for setting up experiments for exploring and attempting to understand complexity.

We agree that there is a need for predictability towards the stakeholders. Although we forecast the future, data from past performance can be used to see trends and forecast releases (with reasonable inaccuracy and possible increasing accuracy over time). Failing to agree to this makes us operate in isolation and fail to understand that Scrum is only a means to an end: delivering value.

We agree that an iterative, incremental approach will increase predictability to control risk. Pushing many small changes creates a faster feedback loop than pushing larger changes at a slower rate. When people continue adhering to the need for producing large changes, we will end up having lengthy discussions on architecture and spend lots of time on producing unvalidated specifications. Such activities can be considered wasteful.

We agree to deliver reproducible quality. In order to deliver continuously, the Scrum team needs to find ways to organize themselves so that they can reproduce at least the same quality as in each previously delivered increment.

We agree to honor the separation of responsibilities of the Scrum roles. Scrum separates the interest of business, technology, and process across three distinct roles to create a healthy tension.

We agree to respect the mandate that is attributed to each Scrum role. Everybody in the organization needs to play according to the rules of the game of Scrum. In this game, each role needs to receive the mandate to execute their responsibilities, an act that is impossible if the surrounding organization does not support and honor this attribution.

We agree to collaborate in teams. Teams are the cornerstone for doing Scrum. Team performance is more important than the individual result. However, some people do not like to or are unable to work in teams. Without the agreement to collaborate in teams, these people will sabotage your attempts to build high performing teams.

We agree with the concept of self-organizing empowered teams. The whole organization including the management needs to support the idea of handing over decision power related to the work to the people actually doing the work, as they know best what needs to be done and what needs to change to improve. Not supporting self-organization or self-management will slow down adaptation and will be a source of frustration.

We agree to adhere to the optimal Scrum team size. The minimal team size of three is set to reduce the "Bus factor." Too little people in a team also makes it difficult to acquire the required knowledge to deliver done and grow Done over time. The maximum size of nine is more fluid, but take into account the exponential rate of communication lines that quickly lead to communication overhead in larger teams. Learning more skills is a more interesting investment.

We agree that development team members need to be cross-functional. In order to deliver done, a development team needs to be able to perform different types of work autonomously as a team. This will make the team flexible and offers flexibility to the organization.

But this is an agreement that many team members find very difficult to accept. People tend to be hired for a certain skill, and we tend to value specialists. However, having a bunch of very deep specialists in one team makes it difficult for the team to collaborate and deliver done. For Scrum to function, i.e. for a team to be able to deliver Done, team members need to understand and master more than just one skill. Failing to agree with this will create teams that operate in waterfall mode and will have a hard time becoming high performing.

Do you see other agreements that need to be met? If so, I invite you to add them to this list.

Further reading

Norms, Values, Working Agreements, Simple Rules

Enablement Over Facilitation: 5 Essentials to Be a Great Scrum Master