A few years ago I was working with a team new to Agile; we were coming to the end of our first Sprint and about to have our first Sprint Retrospective. I booked a meeting to catch up with them prior to the Retrospective because I wanted to explain the thought processes behind continuous improvement. Some of them had never been in a Retrospective before and I wanted them prepared and in the right mindset.

After explaining the basics, in particular, the philosophy of small continuous improvement (Kaizen), I asked them to reflect on our recent weeks together. We'd been through a lot in a short period of time: some Agile training, a team liftoff, their first Sprint. I asked them what they thought would be a good analogy for what we'd done so far.

We brainstormed, silently at first. I had asked them each to draw a picture of their analogy on paper. We then went, round-robin, around the table and everyone presented their drawings. One of our team had drawn a detailed picture of a delicious-looking cake. When it was her turn, she said, "It's like making a cake." She went on to explain, "Scrum, the Agile values and principles, our own professional disciplines, the problem that we're currently solving—they're all of the ingredients. How we put them together is the method."

This was the one idea that really resonated with everybody: "Like making a cake." So I asked them to expand on the idea a bit further; if those were all of our ingredients, and how we put them together was the method, then what was the Sprint Retrospective? Almost immediately, they agreed it would be us looking at how we could improve our recipe.

I suggested we start with the simplest recipe we could think of and go from there. Here's a picture of us making those "simple" cakes—microwave mug cakes:

We all have to start somewhere; the key thing is we'd made a cake, and although it might not have been perfect, within 5 to 10 minutes of starting the process, we got to taste it and work out how we could improve it.

By starting simply, we were able to start closing feedback loops, information that we could then use to make our recipe better. And because we started simply, our cake would be easy to improve. In the photo above, our team member on the left is already licking the spoon, a common cake mix test, while she's waiting for the microwave to do its job. From the look on her face, it must be pretty good, right?

The aim of this book has been to build up a set of practices that we need to help get our teams off the ground. These are all things that you can include in your recipe. Some of them you can't leave out, just like when you're making a cake. However, you can and should start to tweak the recipe, and that's when we need to teach our team the power of experimentation. 

Experiments allow us to relentlessly pursue small, continuous improvements. This will enable us to add tools to our toolbox. For example, we can introduce pair programming, test-driven development, mob programming, behavior-driven development, and so on.

We talk about experiments because we want our learning to be scientific. For example, the microwave cake won't scale to more then one person, but if our reason for doing it is to start testing out flavor ideas, or to see how a gluten-free flourless recipe might work, then we will have succeeded in learning.

Never accept the status quo; always assume that you can do better. The key to getting our team on the journey of continual self-improvement is to cultivate a learning/growth mindset.

To facilitate this, we have to reward the effort that our people put into growing and remind them that they won't always get it right, but just like a scientist, if they set up their experiments in the right way, they should be able to harvest substantial learning regardless of whether their hypothesis turns out to be entirely correct.

When a team is at the beginning of an Agile journey, we need to keep the practices simple to start with and gradually build our team's understanding. Once we foster a continuous improvement/change mindset, our Agile practices will start to grow. 

To do this, we need to:

1. Lay the foundations and set the challenge.
2. Teach the team how to improve. Demonstrate this as a leadership team—be authentic in this, that is, do it and mean it.
3. Provide them with the support they need.

It’s my humble opinion that a framework like Scrum presents a set of training wheels just like those on a child's bike. A Scrum Master’s key role is to support the team in understanding the mechanics of riding the bike, demonstrate why we use training wheels to start with, and then challenge the team to remove the wheels as soon as they can.

We achieve this by:

1. Demonstrating the mechanics, showing them how it works.
2. Transferring ownership to the team, creating more in-depth understanding—let them try and let them fail.
3. Gradually decreasing the support until they’re able to go it alone.

At each step, we are using a different leadership stance. In step 1, we model/teach it. In step 2, we facilitate them doing it. In step 3, we coach until our team becomes self-sufficient in that particular practice.

If we're to foster a healthy network of teams, we need to teach specific skills to draw out the true meaning of the Agile values and principles.

Of course, it depends on your context, and where you and your teams are at in their journey, but to my mind these are the most important when beginning to conduct experiments:

• Collaboration and communication
• Continuous, unrelenting improvement and learning
• Self-organization/self-determination