Starting with Scrum - The Series

An introduction to a series of articles I wrote describing how to start working with Scrum

A scholar, full of knowledge and opinions about dharma, came to a monastery to learn about Zen.

After several weeks, he was sitting with his master, drinking tea.

His master refilled his teacup but did not stop pouring when the cup was full. The tea ran over and spilled all over the table. 

“Stop! The cup is full!” said the scholar.

“Exactly,” said his master. “You are like this cup; you are full of knowledge. You come and ask for teaching, but your cup is full. Before I can teach you, you need to empty your cup.”

This parable illustrates what I think is one of the major problems with Scrum (and Agile, for that matter). 

The bottom line is that there are so many ideas about how Scrum should be done, so many techniques, tools and best practices, that it is hard not to drown in the possibilities. We seem to have lost the essence of Scrum in an overfull cup.

For a long time, all of this was only a suspicion I had… Until I had the opportunity to coach a management team, with no knowledge of Agile. I described the experience in a previous article: How I Discovered Agile Is About Ownership

Since then I try to approach all my teams by focusing on the essence. Start with the events and the roles as the basis for feedback loops, or with Kanban for an even clearer feedback loop. Keep it as simple as possible and only add elements as the need arises.

It is a cathartic experience. It makes room for the really important things, like ownership, empiricism and Scrum values. It also keeps things very much in the hands of the team.

I have had such great experiences with this approach that I decided to write it all down, to help others wrestling with similar challenges, especially Scrum Masters who are just starting out. The result is a series of 7 articles I call Starting with Scrum.

• In the first article, I discuss how to get started with Scrum by determining what the Product Goal is.
• In the second article, I talk about how to translate the Product Goal into a backlog.
• In the third, Product Backlog Refinement, I detail the moment when the groundwork is laid for the Sprint.
• The fourth explains Sprint Planning as the start of the Sprint.
• In the fifth I review the Daily Scrum, the one event that happens every single day of the Sprint and which helps us manage the Sprint.
• In the sixth, I discuss the event that closes the Sprint, the Sprint Review.
• And finally, the Retrospective, the perfect moment to sit back and dream up experiments.

Additional practices

In the series, even though my focus was on rediscovering Scrum in its most simple form, I have at times included things that are not simple. Some are not even part of Scrum, at least, as it is defined in the Scrum Guide. Very good examples are estimation and roadmapping.

I have included these things because I have found them to be essential skills for a team to function properly. For me, these are the minimal patterns, processes, and insights that fit the Scrum framework, as mentioned in the Guide. 

Take estimation. The reality is that most companies still want to be able to make predictions, however rough. 

But more important is the fact that estimation is a really valuable tool to teach teams to manage their work and improve their skills in breaking work down into manageable pieces.

The same applies to roadmapping. Most companies will not do without it, and it is a wonderful tool to help teams manage their Product Goal and work with stakeholders. 

My aim is to offer techniques that may help teams deal with these essential skills in a relatively easy and pragmatic way, and to their own advantage.

The Sprint Review

The hardest article to write was the one about the Sprint Review. Even though I really believe in what I’ve written, I will also be the first one to concede that the things I describe often seem quite hopeless. I was depressed after writing it, fully realizing how improbable it is in the reality of most organisations.

Going forward, I take it as my personal challenge to find ways to deal with the Sprint Review. I invite you all to help me in finding ways to make it what it is supposed to be.

A motivated team

In the series, I have assumed a motivated team, yearning to improve. I have done this because most of the teams I’ve encountered are like this. Yes, they may be frustrated and damaged by previous experiences with Scrum, but at their core they all want to excel and enjoy their work.

Additionally, I feel that motivation is a basic requirement to work with Scrum. If that is not the case, I think you have far bigger problems to work on before you can ever start to consider working with Scrum.

Conclusion

I use Scrum at home for home improvements. Every Friday, together with my wife, sharing a glass of Cava, we hold a kind of Sprint Review followed by a combined refinement and Sprint Planning, and then we start a new Sprint.

Of course, we don’t use these words. We just started doing these things because they are such an obvious thing to do.

We have a board drawn on one of our cupboards, with post-its stuck to it. During the week we often glance at the board. It keeps a sense of urgency alive and reminds us of what is important. We celebrate when a post-it moves.

The result is that we get things done, with a system that barely gets in the way, and we have fun with it! Moving a post-it down a board will always be such a rewarding moment.

Scrum can be so easy.

I think it all starts with emptying the cup. That is the real challenge for us Scrum Masters.

In my series I have attempted to explain the simplicity of the framework itself, wishing to make it easier for you to find your way with it, and hopefully leaving more room for you to deal with the real challenge: emptying the cup.