Scrum for Teams

A Guide by Practical Example

Dion Nicolaas

• Publisher: Business Expert Press
• Year: 2018
• Print ISBN: 9781948198431
• eBook ISBN: 9781948198448
• Topic: Business
• Subtopic: Project Management
• Index: Business

Scrum is an agile framework for completing complex projects. This book gives 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 the readers will be able to come up with their own ideas that work better in their organization and situation. All the practical examples in this book have helped someone, somewhere to become a part of a better Scrum team.

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-to succeed in an organization, the teams must do Scrum well. If the teams do Scrum well, the whole organization will benefit from it. Scrum helps a team self-organize, which fits in well with developers, who usually don't like to be micromanaged. At the same time, Scrum can scale: Self-organized teams work together well, and one manager doesn't have to manage all the people.

The lessons from this book help 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 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.

CHAPTER 1

Introduction

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 it 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 two 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 anymore. 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 part of, 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 are even a Certified Scrum Master . . . but still you’re waiting for that mythical state of hyperproductivity. 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 bits 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 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 in an agile organization, 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 a retrospective meeting: Did it work? Is it better now? Follow more advice, until you feel something has changed. 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.

CHAPTER 2

What Is Scrum?

Scrum is an agile framework for managing projects. What does that mean?

It is agile:

The process is lightweight and flexible.

It is a framework:

Scrum gives a clear structure to agile practices; that makes it ideal to get started with agile development.

It is iterative:

The work to be done is chopped up in pieces and done in equal periods of time, reducing complexity and giving a clear view on progress.

Scrum was inspired by the lean manufacturing practices in use by Toyota. Jeff Sutherland and Ken Schwaber presented the Scrum methodology in 1995.

Scrum is really simple. The driving principle is that you should do product development feature by feature in small, equal-sized iterations, called sprints in Scrum. That allows you to work on the most important thing all the time, to stop whenever you’ve done enough, and to measure your progress. All of these reduce the development time of a project and the risk involved.

Scrum introduces roles, meetings, and artifacts to add some structure to this principle. That way it provides a framework to organize your project. All you have to do is fill it in with your product ideas, your expertise, and, most important of all, your people.

2.1 The Product

A company has a vision, a product they would like to create. Or maybe they have a customer that wants some new features. That’s where it starts. They have a team of people that are going to do the work.

Figure 2.1 shows the Scrum process. It shows the roles, meetings, and artifacts that you use in Scrum to organize the project.

Figure 2.1 The Scrum process

2.1.1 The Product Owner

The Product Owner owns the product vision. He or she needs to share the vision with the rest of the Scrum team, so that they can make it into a real product.

The Product Owner can be the real stakeholder for the features, but it can also be that he or she represents the customer. Either way, the Product Owner needs to know exactly what the final product should do. If someone in the team has questions about how things should work, the Product Owner must answer them. If the team comes up with an interesting idea to do something, the Product Owner must be able to decide whether it is valuable. The Product Owner is the link between the team and the stakeholders.

2.1.2 The Product Backlog

To help the team understand what they need to do, the Product Owner chops the product up into bite-sized chunks: single features that can be created by the team in less than a week. Often these features are written in the form of user stories. The complete list of user stories is called the product backlog.

The Product Owner orders the product backlog by business value: User stories yielding the highest return of investment come first. Now if the team works on the product backlog from the top down, the most important features are done first.

2.2 The Process

Once the product backlog is there, the process can start.

2.2.1 The Scrum Master

If the product backlog is ready, the team can start working on the product. They follow a simple work process, which the Scrum Master leads.

2.2.2 The Sprint Planning

Together with the Scrum Master, the Product Owner organizes a sprint planning meeting with the team. The Scrum Master chairs the meeting where the Product Owner presents the product backlog to the team.

2.2.3 The Sprint Backlog

The goal of the meeting is to decide on a sprint backlog : a list of user stories that the team thinks they can do in a fixed period of time (usually 2 to 4 weeks). That period is called a sprint.

The team decides what they can do. The Product Owner just sets the priorities. But if the team decides they can do a certain amount of work, they commit to that, so that the Product Owner knows what to expect.

2.2.4 The Sprint and the Stand-Up Meeting

Now the team starts the sprint. Each day, they have a stand-up meeting : a very short meeting (at most 15 minutes) where they align their work. The team members discuss what they did yesterday, what they will do today, and whether there is anything blocking from doing their work, so-called impediments.

The Scrum Master is responsible for removing the impediments. While the team does everything that is necessary to implement the user stories, the Scrum Master does everything that is necessary to let the team do their work. The Scrum Master owns the process; he or she makes sure the team can work as well as possible.

2.2.5 The Scrum Board

During the sprint, the team uses a Scrum board to keep track of their progress. On the Scrum board there are three columns, labeled To Do, In Progress, and Done. Initially, all the work that needs to be done in the sprint is placed in the To Do column, in priority order from top to bottom. As the sprint progresses, items move from To Do to Done.

The Scrum board usually also has a burn-down chart, in which the amount of work still to be done is plotted against the time. But a lot more can go onto the Scrum board . . .

2.2.6 The Spri...

Table of contents

• Cover
• Half Title Page
• Title Page
• Copyright Page
• Contents
• Preface
• Acknowledgments
• Chapter 1 Introduction
• Chapter 2 What Is Scrum?
• Chapter 3 Make the Most of Stand-Ups
• Chapter 4 Everything on the Board
• Chapter 5 Planning Is Half the Work
• Chapter 6 Practices Make Perfect
• Chapter 7 Demo, Demo
• Chapter 8 Look Back!
• Chapter 9 Done, Done, Done, Done, Done
• Chapter 10 Power to the Team
• Bibliography
• Index