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.
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.
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.
There are only three roles in Scrum, and they are all in the Scrum team. They are Developer, Scrum Master and Product Owner.
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.
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.
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.
There are a few key events in Scrum. Let’s look at each of them.
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:
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”:
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:
These things combine to form the Sprint Backlog, one of the Scrum artifacts.
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!
There are some key principles you need to follow to use Scrum effectively.
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.
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 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.
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.
There are few easy ways to not do Scrum well.
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.
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.
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!
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!