Scrum is a term you’ll often hear in software development conversations these days. But unless you’re already familiar with it, you might not know exactly what it means.
Webster’s dictionary defines Scrum as a rugby strategy (we’ll get to that later) OR as “a place or situation of confusion or racket; a hubbub.” Not exactly what we’re looking for in our software development, is it?
Other people refer to Scrum as a new style of project management, a collaboration process, or even as a synonym for agile development.
All these miscues have created some confusion as to what the Scrum definition really is. In this post, we’ll clear up those miscues and answer the question: what is Scrum?
The Real Meaning of Scrum
The real meaning of Scrum derives from its rugby definition. A rugby Scrum is a rather elaborate and chaotic-looking strategy that depends on a combination of teamwork, skill, and strict formations.
This analogy was then applied to software development. Although seemingly complex and confusing, when you break a development project down with a more disciplined approach, relying on the skills and teamwork of its members, success can be achieved.
I like to refer to Scrum as a social engineering framework. It’s all about empowering the team, getting them to work together to make decisions, and boosting performance by offering both responsibility and accountability. A lightweight set of rules and practices is designed to enable groups of normal individuals to do the right things at the right times to produce extraordinary results. In this way, Scrum is more about creating situations where team members can collaborate effectively than it is about managing projects. You can read more about the origins of Scrum and the Scrum definition in the Scrum Guide.
Why Does Scrum Work?
First off, let me say this: Scrum works. It really does. I’ve been in the software industry for over 35 years, and nothing I’ve seen even comes close to Scrum’s effectiveness. I’ve literally seen Scrum transform a wide variety of businesses and development teams over the years – including my own.
But why does Scrum work so well? There are many reasons, of course, but I’ve narrowed it down to four key drivers:
- A short deadline
- A short-term planning cycle
- Accountability
- Communication
That’s it. Those four drivers are at the heart of why Scrum works – and how.
Production Sprints in Scrum
In a Scrum project, work is completed in fixed-duration production cycles called “sprints.” This time period, which ranges from one week to a calendar month, turns the traditional long-term deadline on its head and forces the Scrum team to produce results now.
Scrum’s short-term planning cycle
In Scrum, your to-do list – also called a product backlog – is reprioritized before every sprint. This makes sure that the backlog always represents what’s most important – and will add the most business value – right now.
From there, the Scrum team works together to create their own plan to accomplish those goals. This forces them to think through what they need to do, increases their productivity during the sprint, and allows them to keep their heads down and focus on completing the work.
Scrum empowers the team – and makes them accountable
One of the most unique features of Scrum is how it empowers the team to decide what they’ll commit to during a sprint, rather than telling them what they must accomplish. This gives the team true responsibility and ownership of their project – a key building block for ultra-productive teams.
This responsibility is backed up with accountability. Their work must hold up to the scrutiny of business stakeholders. Because they are the ones making the estimates and the critical decisions about how to do the work, they should be held accountable for the results. They will face those results during the sprint review ceremony once the production sprint is done. If they stumbled a bit and didn’t accomplish everything they expected to, they’ll need to explain why – and the team will help create an action plan for doing it better next time during their sprint retrospective meeting.
Scrum forces team members to communicate
In Scrum, you can’t be an isolated programmer or subject matter expert just doing your own thing and ignoring everything else. Since the entire team is accountable for their results, Scrum requires everyone’s involvement in making the team’s decisions.
The Scrum framework requires interaction – and encourages participation – in every aspect. From 15-minute daily standup meetings to sprint planning discussions, social interactions and collaboration guide the team more than any dependency on written specifications.
Scrum is not just for software development anymore
The Scrum framework can be applied to projects outside of software development, too. Any project with a to-do list and a team of individuals who need to work together effectively can implement Scrum to produce reliable results.
Some of the best fits for Scrum are projects where high degrees of uncertainty exist. Designing a new cosmetic product, or planning the itinerary for a political campaign, are both examples where Scrum could be effective.
What does the Scrum framework look like?
The Scrum framework is built with a handful of roles and some routine events called Scrum ceremonies. These give a much-needed structure – i.e. framework – for Scrum’s processes.
Scrum roles consist of:
- Product Owner
The Product Owner is the overall vision leader for the Scrum team. Their primary responsibility is to maintain the team’s to-do list, called the product backlog. As liaisons to the business stakeholders, they are tasked with creating the user stories for the product backlog as well as prioritizing them to best fit the needs of the business.
- ScrumMaster
The ScrumMaster is the owner of the Scrum process. They are tasked with helping the development team adhere to Scrum’s guidelines and removing (or initiating the removal of) any obstacles the team identifies along the way. This includes scheduling Scrum ceremonies, coaching team members about Scrum, and making sure each member is prepared and able to contribute in a positive manner.
- Development Team
The development team is the group of individuals who create the product. These members are referred to as the “developers” regardless of their area of expertise. The development team is cross-functional, with skillsets dependent on the type of product being built. An ideal development team consists of three to seven individuals.
- Scrum Team
The Scrum team is the “overall” project team. It includes the development team, product owner, ScrumMaster, and any other resources who are routinely involved in the project’s operations – such as participating in Scrum ceremonies. An ideal Scrum team should consist of five to nine individuals.
Scrum ceremonies are the routine events which drive a successful Scrum project. These include:
- Sprint planning
The planning event occurs once at the beginning of each sprint. Here, the Scrum team decides how they’ll complete the highest priority backlog items. They also decide how much work they can take on during the sprint and break down user stories to fill that capacity.
- Daily standups
These daily ceremonies are time-boxed to fifteen minutes and only the development team members are allowed to speak. Each member addresses what they’ve done since the last standup to help the team meet its commitments, what they plan to do between now and the next standup, and what obstacles they feel might be in their way.
- Sprint review
The sprint review provides an opportunity for stakeholders to inspect the work of the development team, often through the use of a product demonstration conducted by the team. It addresses whether the team met its commitments for the sprint – and if not, why? It also includes a discussion of what comes next, which the product owner uses when reprioritizing the product backlog. A hallmark of healthy sprint reviews is open and honest communication between the team and stakeholders.
- Retrospective
The retrospective is time set aside to reflect on the team’s experience with Scrum during the prior sprint. They discuss what’s going well with the process and what’s not going so well. The point of the retrospective is to identify how they’ll try to improve the process during the next sprint, and to push for continuous improvement and growth.
Learn More About Scrum
If you want to learn more about Scrum and how it could help you deliver more business value to your organization, check out our free webinar, Driving Business Results With Scrum. You can also contact us today and discover exactly how Ascendle’s coaching or development services can help you meet your business needs.
