Preface

When Jeff Sutherland taught his Certified Scrum Master course, I was most impressed by how he answered all questions: by giving an example of a team somewhere that had the same problem, and solved it in this or that way. I think Scrum should be taught that way: by example. There may be a lot of theory as to how to have people work together on large and difficult work; but it requires a lot of practice.

This is Scrum: Getting It Right, a collection of Scrum practices. I’ve been working with Scrum for over seven years now, and found out it is not easy to do it right.

So here are examples, tools and tricks to do Scrum well. For each trick it is explained why it helps. The practices themselves may be worth trying, but by understanding why it works you might come up with your own ideas that work better in your organisation.

That’s also why this book has become a collaborative effort between me and you, the readers. All teams are different; what worked for me might not work for you. Readers have come up with valuable stories of their own. Over time, I’ve included them in the book. Every example has helped someone, somewhere to become a better Scrum team, so every story might be helpful to you. Scrum’s motto is: “Inspect and Adapt.” Change small things one at a time and see what works.

Scrum is not done by project leaders or managers, but really by the teams. If you want Scrum to succeed in your organisation, the teams must do Scrum well. If the teams do Scrum well, the project leaders and managers, and the whole organisation, will benefit from it.

Scrum helps teams self-organize, which fits in remarkably well with developers, who usually don’t like to be micro-managed. At the same time, Scrum scales: self-organized teams can work together well, and one manager doesn’t have to manage all people.

I love to see Scrum teams develop into autonomous, proud and independent teams. Often teams fail to become powerful enough to change the organization, so they cannot perform to their full potential. A really good team can lead the stakeholders into trusting them. They will then make plans based on the team’s release planning instead of making roadmaps out of thin air, and thus make the organization much more predictable.

But most importantly, I see that developers like Scrum. That’s why I want them to succeed.

Acknowledgments

The first time I heard of Scrum was when Jeroen van Eekelen introduced it in our department at scale, and he sent me to the Scrum Master course. Two days with Jeff Sutherland made something happen: this could work. I wanted to try this with my team, and with other teams in the company.

We started experimenting, and went through a lot of growing pains. But we enjoyed it and learned a lot along the way. I decided to write down the lessons learned, so we wouldn’t forget; and I wanted others to benefit from them, too.

I wouldn’t have started this if it wasn’t for Simon Reason, who is the best Scrum Master we ever had. He taught us how to do Scrum. He was also the first one to read this and provide me with lots of useful comments. I owe a lot to Simon for that; thank you, Simon.

The people from The Pragmatic Bookshelf surprised me time and time again: by showing interest to begin with; by really caring about the best way to publish this; and by helping me turning a rough and plain pile of words into a real book. It is a pity it didn’t work out in the end, but I want to thank them for giving me the freedom to publish this book myself.

Special thanks goes to Jackie Carter from the Pragmatic Bookshelf, who turned it into readable English and bore with me while rewriting. Being critical and encouraging at the same time is a rare trait, indeed.

The proofreaders were very helpful and encouraging. It made me think it was worthwhile to go on with it. Thanks to Tim Ottinger, Jeff Langr, Robert Shaw, Henk Jan Huizer, Lasse Koskela, Johanna Rothman, Wouter Lagerweij and Venkat Subramaniam, for your constructive and detailed feedback.

Writing books in general, and working in different time zones in particular, is bad for families. Anke Petra made sure it didn’t all fall apart, indulged with evenings spent working, and sent me to bed to be able to get up in the morning. Home is where my love is.

A big “thank you” goes of course to the Scrum teams I’ve been working with at TomTom International BV. I learned everything from you, guys’n’gals. And thanks to David Stelpstra, for triggering me to put this book on-line.

The last and ever-growing acknowledgment is for the contributors of stories. This book wouldn’t be called “Scrum by Example” without you. In theory, there is no difference between theory and practice; but in practice…

Leave a Reply

Your email address will not be published. Required fields are marked *