I’d like to introduce you to The Team. I don’t know why they started doing Scrum: maybe the management heard of Agile and thought is was a good idea; maybe their project manager got enthusiastic about this new way of managing projects during a conference; maybe they decided themselves that they wanted to jump onto the agile bandwagon. But anyway, they started doing stand-up meetings, fixed-length sprints and sprint planning meetings. Their colleagues made funny faces when they gathered around their Scrum board and had their short meetings. Their stakeholders mumbled in their beards when they said they couldn’t change the planning for another three weeks. But they did Scrum! And it worked: they delivered some really nice new features after their first iteration, and got encouraged to proceed on the chosen path.
But after a few sprints, the spirit started to wane. Stand-up meetings started late or were skipped altogether, sprints lasted longer than originally decided, and the team slipped back into old habits. “After all,” they said, “Scrum is not a method, it’s a template! Which means you can change it!” So The Team changed the template to fit in more and more with their old way of working, until someone realized they weren’t doing Scrum after all. And then they decided that Scrum really wasn’t working for them. So they moved on, to PRINCE2, or KanBan, or RUP, and we lose track of them. Maybe they serve as an example in another book; The Team is a very common phenomenon.
The Team is us, of course, when we just started to do Scrum. But we didn’t decide that Scrum wasn’t working for us; instead, we decided we wanted to make this work. We went back to the basics, and tried again. We kept on going back to the basics, trying to make it work. And we got better! With each and every sprint, we gained some experience, we learned something new, until we could finally say with a straight face that we were doing Scrum.
The Team is also other teams I’ve been in, as Scrum Master, Product Owner or team member. Each team needs to work out for themselves how they can make Scrum work for them. Some problems are encountered by a lot of teams, and some are very special. But in each Scrum team I’ve been I’ve learned something.
Maybe you are doing Scrum, and you go through all the moves, perhaps you even are a Certified Scrum Master… but still you’re waiting for that mythical state of hyper-productivity. Even though you know how to do Scrum, it doesn’t really work. You’re getting along, but you ask yourself what the hype is about.
A problem with Scrum is that there is so little of it. There is not a lot to change if you want to do Scrum: a few roles, a few meetings and you’re doing it. That can feel unsatisfying, so some teams start to add their own from the start. But if they do that before they understand the essence of Scrum, they will probably never get it right.
For Scrum to work for you, you must do it properly until it clicks. After a while, everything will fall in place and you suddenly see why you do stand-ups, why you need a Scrum board or why story points are a good idea. But you need a little patience for that click to happen. Scrum probably doesn’t give you much after one sprint. But after four or five sprints, you should start seeing the difference.
But Scrum needs to be understood by the team. Even with full management support and an agile organisation, Scrum may fail if the team is not getting it right. And even if the team is completely on their own, they can be fairly successful at Scrum if they know how to do it. Scrum is done by teams. This book helps the team to become good at it.
Not every Scrum team will need to learn everything in this book in order, although it probably won’t hurt to read all the chapters. Some teams might be doing well in some areas but not so good in others. Some teams might get almost everything right but lack in one little detail. Learn from this book in priority order: discuss with the entire team what hurts the most, read the corresponding chapter and pick the advice you think is most useful. Pick two or three things at a time, and pay attention to them during a sprint. Discuss them in the retrospective: did it work? Is it better now? Follow more advice, until you feel you master the habit. Then move on to the next.
Scrum is hard. Even though the methodology, or the template, is easy enough, doing it right requires a lot of attention. It can take a team months to get it more or less right; some teams never get it. And when it doesn’t pay off, it becomes a burden. That is the moment that teams decide that “Scrum isn’t for them,” or “Scrum doesn’t work.” Indeed, something that slows you down can better be ditched. But even better is to make it work for you.