How experiments improved our team's processes

Can processes unrelated to Scrum co-exist within the Scrum framework? Yes! Lars Douwe Schuitema, Front-End Developer at funda, explains how his team used experiments to improve their processes, and how you can do the same.

Around two years ago I became Scrum Master for the first time. I had no prior experience with Scrum. In fact, the only Scrum knowledge I had was what I had gained from observing my team over the previous year. The first thing I did in my new role was to read the official Scrum guide. After a few days, having read most of the contents, I realised that our team was deviating from the official Scrum processes, and so I proposed to implement a few crucial missing elements.

These elements are crucial, according to Scrum, because:

'Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless.'

One of the elements that the team was missing was the Sprint Review, which is a key Scrum event to inspect the outcome of the Sprint. I suggested implementing this event as part of our schedule, so that we would follow a more complete implementation of Scrum, but I faced resistance. Many team members did not like the idea of adding another meeting to their schedule, because it would potentially result in less development time.

One of the team members rightly asked me: ‘Why do we need a Sprint Review, when we have Demo Day?’ (Demo Day is an event held every other week at funda in which teams present their work to everyone in the company who wishes to attend). This was a valid question to ask a Scrum Master, because this person’s role is to help the team to understand what Scrum is and how to adopt it effectively.

I responded by pointing out the differences between these two events, but the team was not yet convinced it would be a useful addition. And although it is part of the minimal required Scrum implementation, who was I to act like the Scrum police and enforce this process onto the team? I had to come up with a better plan to convince the team: an experiment.

What is an experiment?

An experiment is not a Scrum-specific method or procedure to improve a team’s process, and so is not a part of Scrum. However, one of the amazing things about Scrum is that it is a lightweight framework, in which other features can co-exist. There is, however, only one way to find out whether this co-existence is possible: empiricism.

'Empiricism asserts that knowledge comes from experience and [you] make decisions based on what is observed.' – Scrum Guide 2020

An experiment is nothing more than implementing a new process or improving an existing process, running it for a couple of Sprints, evaluating how it went, and finally deciding as a team whether it can become standard.

The duty of the Scrum Master is to facilitate this experiment and its implementation, and to ensure the team understands what the experiment is about. But it is the responsibility of the team as a whole to make sure it runs as effectively as possible. Experiments can be adjusted if needed; for example, if you find out important content is missing, adjust the experiment so that a better evaluation can be made.

How to create an experiment

There is no standard format for creating an experiment, so you are free to do what best suits your team. Every team is different and requires a different approach. In the beginning you might not know exactly what formats fit your team best; indeed, that was the case for our team.

In such instances, it can be wise to use the ‘A3 Problem Solving’ format. This is an approach that encourages in-depth problem solving through collaboration. It employs continuous improvement to ensure an experiment meets its intended goal.

In the example of our team, where we lacked the implementation of the Sprint Review, we did two other things besides defining the A3 Problem Solving format:

Delivered a 30-minute presentation about the definition of the Sprint Review, to fill the knowledge gap and to help the team understand the difference between the Demo Day and the Sprint Review
Determined the structure of the Sprint Review that best suited the context of our team, product and company

Once the initial A3 Problem Solving format was set and the contents of the Sprint Review ceremony were clear, we decided to run an experiment for about 4 Sprints (8 weeks). The length of an experiment is not set in stone and can be adjusted throughout the process.

Go/No-go moment

Once the experiment is over, you need to organize a formal team session to evaluate and decide whether you want to implement the experiment as standard. The conclusions of the team’s experiment with the Sprint Review were to do the following:

Have a more focused session than the company’s Demo Day to elicit feedback from Key Stakeholders
Update the Product Backlog and/or individual Product Backlog Items based on feedback during/after the session
Improve the preparation of Sprint Planning based on the work that has been done and on feedback received from presenting the upcoming work

Over time, a team can gain more experience with the new standard and adjust when suitable. In the case of our team, the Sprint Review became a default Scrum ceremony.

Since doing this experiment, we have run many more experiments as a team, mostly for the things for which the team needed convincing or to remove discomfort around implementing certain processes. Other teams have followed suit.

So my two cents on it all: running experiments is a fantastic way to improve team processes.