How to use Scrum
Scrum is the most popular and influential framework for agile software development. It has been around for decades, is used all over the world, and is changing how people work. This article will give you a quick guide on how to use Scrum to maximise the value of your product development work.
Brief history of Scrum
Before we get into the details, let’s look at a very brief history of Scrum, so we know where we are starting from.
Scrum was created by Ken Schwaber and Jeff Sutherland in 1993. They both had backgrounds in the traditional “Waterfall” approach to software development, and had frustrations with long delays and failed projects using that system.
Inspired by a Harvard paper from 1986 called “The New New Product Development Game“, which used the rugby term “Scrum” to describe a collaborative cross-functional team, they developed the Scrum framework. A paper on the framework was presented at a conference in 1995, and Scrum started spreading from there.
Ken and Jeff went on to become signatories of the Agile Manifesto, and the rest is history.
The Scrum team
So how do we use Scrum? It is most important to understand the concept of the Scrum team.
A Scrum team is a small, stable, cross-functional and empowered team, who are wholly responsible for building and developing a product.
There are some really key parts to unpack from that simple statement, however.
The Scrum team is small – ideally no more than ten people. Smaller teams communicate better, work more efficiently and require less meetings.
The Scrum team is stable – although the Scrum guide doesn’t talk much about this, the team is ideally long-lived. Rather than continuously throwing random people together for a project then splitting them up and moving them onto another project, you keep the team together, for as long as you can. This lets you climb the famous Tuckman “Forming Storming Norming Performing” hill and build some long-term productivity gains.
The Scrum team is cross-functional. This is a big one! It means the team has all the people needed to develop the product, whoever they might be. No more “analys team hands off work to the dev team who hands off a bunch of work to the test team who hands it off to the release team”.
The idea here is that each team should own the entire value stream for their product, “from concept to cash”. This means they don’t have dependencies on other teams and other teams don’t have dependencies on them. No more handovers!
So to get started with Scrum, you need to form a Scrum team. Importantly, there are three roles or accountabilities that are performed in this team.
The Scrum Roles
There are only three roles in Scrum, and they are all in the Scrum team. They are Developer, Scrum Master and Product Owner.
Developer
Developers are people who are committed to creating any aspect of a product increment.
Note that it doesn’t necessarily mean “software developer”! The actual job title and skills involved could be literally anything.
For example, they could be a UX designer, tester, business analyst, database administrator, software engineer, content author, and so on. And remember, those people all get to keep their job titles. Developer is their Scrum role (or accountability), not a job title.
The Developers also create the Sprint Backlog – the plan of work for the sprint. And Developers get to choose what gets worked on – they pull work into each sprint.
Product Owner
A Product Owner is someone accountable for value of a product. They own the Product Backlog. They are completely 100% accountable AND empowered to control the Product Backlog for a product.
If they are not empowered to do this, they are not a product owner – find someone who IS so empowered and they are your product owner!
The most important thing to remember is that the Product Owner is in the Scrum team. They are not a stakeholder – they are outside the team. Stakeholders get to inspect the product and provide feedback at the Sprint Review. We will get to that soon.
Product Owners can create, change, reorder and remove product backlog items, whenever they want.
Scrum Master
A Scrum Master is someone accountable for the effectiveness of a Scrum team.
It is a difficult role to describe and one that is often misunderstood and misused. They are not a project manager – or a manager at all.
They are a servant leader. They are there to help, guide, coach and improve the team, and the organization.
Most importantly: they are (or at least are supposed to be) a master of Scrum. Their main responsibility is coaching the team and the organization on Scrum.
The Scrum events
There are a few key events in Scrum. Let’s look at each of them.
The Sprint
A sprint is a short block of time, from one to four weeks, in which some work is done, and one or more product increments are created. Some very important rules:
- Every sprint has the same duration / timebox. You can’t extend a sprint by a day to squeeze work in.
- As soon as one sprint ends, a new one begins. No “downtime” between sprints
- There is no sprint zero, or “post-release” sprint. No “hardening” or “defect fix” sprints. You just keep doing sprint after sprint after sprint.
- Every sprint has a sprint goal.
The Daily Scrum
This is a short daily meeting, timeboxed to 15 minutes.
The purpose is to “inspect progress towards the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work”.
It is not run by a Scrum Master, or project manager, or anyone! The meeting is instead is a quick way for the Developers to discuss and coordinate their work. It is not a status update for a manager!
Some people like to structure it by answering the “three questions”:
- What did I achieve yesterday?
- Next, what am I trying to achieve today?
- Finally, what are the main impediments or blockers in my way?
The Sprint Planning
Each sprint begins with Sprint Planning. This is where the team chooses the work to do in the sprint. Nobody, and I mean NOBODY, not even the Product Owner, tells the Developers the work they will do in the sprint.
Work is not pushed onto the Developers – they pull work into the sprint.
There are three things to discuss in sprint planning:
- The why, i.e. what is the sprint goal
- The what, i.e. which product backlog items will the team try and complete in the sprint
- The how, i.e. how will the team get this work done by the end of the sprint.
These things combine to form the Sprint Backlog, one of the Scrum artifacts.
Sprint Retrospective
The final event of the sprint is the Retrospective.
It is an opportunity for the whole team to reflect on how the sprint went. It is an opportunity for the team to consider opportunities for continuous improvement.
Some of these items can (and probably should) go onto the sprint backlog for the next sprint!
How to use Scrum effectively
There are some key principles you need to follow to use Scrum effectively.
Set up the team right
The most crucial thing is setting up the team right. That is, making it a true cross-functional, empowered and independent team. Make sure the Product Owner is empowered to make product backlog decisions. And make sure the team doesn’t have dependency on a test or release team. Make sure the team are trusted and given the tools and power to get the job done.
Focus on meeting your sprint goals and sprint review
Make sure to set a meaningful sprint goal every sprint (and not just “get all the sprint backlog items done”) and ensure every Daily Scrum involves discussing progress towards that goal. And try to get a potentially shippable increment done at the end of every sprint. And get stakeholders to attend the sprint review, inspect the product, and provide feedback.
Transparency is key
Transparency is one of the key pillars of Scrum. Don’t hide problems! Make them visible. We don’t want watermelon projects (“green on the outside, red on the inside”).
Make all the impediments to a team’s progress visible to stakeholders. Bring them up and discuss them regularly. Escalate them if the team cannot solve them themselves.
The team needs whole of organization support
A Scrum team needs support from the organization to succeed. They need to be trusted, left alone, and given the tools and resources they need to develop a product increment every sprint. There may be changes required to other parts of your organization, such as HR, Finance or Operations, to get the best benefits out of Scrum.
How not to use Scrum
There are few easy ways to not do Scrum well.
Wrap a Waterfall project in sprints
Taking your big old-fashioned Waterfall project, with separate build and test teams and phases, and wrapping sprints around it, might seem like a good idea. It might make progress a bit more visible. But it is not Scrum and will not get you anywhere near the benefits from a real Scrum implementation.
Fake or absent product owners
A common mistake is to have fake or “proxy” product owners. These are usually business analysts (BAs) who report to a product manager. Whenever a decision comes up, they have to defer and go run back to their manager to get a decision. That is not a real product owner!
Another way not to use Scrum is to get a senior executive to be a product owner. They might feel they are a product owner (the name makes them sound powerful), but they are usually an “absentee landlord”. They are too busy to attend daily scrums or respond to questions, and just turn up to sprint reviews.
That is a stakeholder, not a product owner! Product owners are in the team and commit to focusing exclusively on working with the team to develop the product.
Locked in scope
The whole point of Scrum and agile is to have flexible scope – to build and release small increments, and course-correct based on progress and feedback. If you have a project with hard scope all locked-in from the beginning, this is not the time and place to use Scrum!
Summary
I hope this article has given you some good information on how to use Scrum. Do have any more questions on this topic, or experiences you would like to share? Drop them in the comments!
