Intro to SCRUM

Why SCRUM?

SCRUM was created to improve how software was developed. So what problems is SCRUM trying to solve?

Organising the team

Organising a large number of people can be tricky for a single individual. To solve this traditionally, we created a series of middle management to help with this. If it's a very large number of developers on a project, we could have multiple levels of middle management. For every layer we put in place we remove the decision maker from the work being done and add more ways in which communications can become distorted.

Changes in Scope or Requirements

Writing a lot of documentation about a piece of software, like business requirements, functional requirements and technical specifications is expensive and time consuming. It means that when things change and the requirements change there is a financial inertia in accepting those changes and there is also a time impact as all that documentation needed to be updated with the new requirements. Often contracts were signed with the requirement being part of that, so contracts may need to be re-negotiated, or additional costs authorised. Many projects were cancelled at the cost of millions because this whole process took too long, or the cost of change made delivering software that was useful almost impossible.

Understanding who's responsible for what

Who was responsible for what in the software development lifecycle was often blurred. If a user needed something added or changed in the software they would often come directly to the developer and ask a favour. Support or salesmen would come and ask for a change as a customer really needed it right now, or they needed it to make a sale to a big customer. Development time is finite, so who actually decided what was the most important?

All of these problems are tackled by SCRUM.

What is SCRUM?

SCRUM is a framework, designed to move decision making closest to the people doing the actual work and where good communication is highlighted as an essential element of development. It defines:

  • Roles that people play, and what they're responsible for
  • How people organise
  • How work is organised and prioritised
  • A minimum number of required meetings (these defined meetings are also called ceremonies or events in SCRUM)
  • The overriding process that is used to pull all of these together

Roles that People Play

In SCRUM there are three roles:

Product Owner (PO)

"Build the right thing"

The Product Owner is a single individual who has the responsibility of creating the Product Backlog. They are also responsible for prioritising the work within the product backlog, making sure we deliver the most value in the shortest amount of time possible.

Development Team (The Team)

"Quality of what's built"

The Development Team is a cross functional team of people that, as a team, is able to take a backlog item and transform it into working software. Each team should include all the skill necessary to do this. This doesn't mean that all teams are the same as some backlogs will require different skills. For example, some teams will require web development skills, some teams would need to have database development skills and some would require both sets of skills. The skills required for each team depends on the type of work in the product backlog. The Development Team are responsible for the quality of the product they produce.

Scrum Master (SM)

"Fast Feedback"

The Scrum Master's responsibility is to ensure that the whole SCRUM team understand SCRUM, that the processes are followed and that the meetings are delivering the value that they should. Part of this responsibility is to protect the Development Team from external distractions and allow them space to focus on the work at hand. The Scrum Master should ensure that feedback happens as quickly as possible in all aspects of team communication.

How People are Organised

A SCRUM Team consists of one Product Owner, one Scrum Master and one Development Team (that has between 3 to 9 team members).

The team is self-organising. Why? This means that the team can adapt to the situation and current requirements as quickly as possible, without having to ask permission or wait for managers to decide if they think a new structure may be better or not.

Why that size of team? Its been shown that communication is key to successful teams. Teams need to be big enough that between them they have enough skills to be able to tackle the varied nature of work needed to deliver parts of a product without having to wait for someone outside of the team to become available. If a team is too big, then communication within the team starts to become more problematic, meetings take longer, its harder to agree consensus and changes to how the team works meet more resistance and so the team is slower to improve. Co-ordination in a larger team also starts to require too much effort.

How Work is Organised and Prioritised

Each Scrum Team should only ever have a single product backlog to work from. Why? This prevents the team from having to make decisions around which items have priority over other items, allowing them to focus on actually getting the work done.

There are two types of backlog in SCRUM:

The Product Backlog, owned by the PO. This backlog includes all the work that's required to either complete the product, or if we are talking about a larger product, the work that's currently on the product roadmap. Its the job of the PO to make sure this backlog is groomed (refined) and prioritised. In order to prioritise backlog items, the PO will often have to know how much work is involved in a piece of work and would have asked The Team to give each backlog item a size.

The Sprint Backlog, owned by The Team. This backlog is the list of work that the Team have committed to solely focus on for a set period of time in order to get it all completed by the end of the current timebox (these timeboxes are called Iterations in Agile, or more specifically Sprints in SCRUM - the terms are often used interchangeably). The Team only works on items in the Sprint backlog.

Meetings (Ceremonies/Events)

There are four official SCRUM meetings:

Sprint Planning

In this meeting the PO presents the Prioritised Product Backlog to The Team. The Team then selects as many items as they think they can complete in the upcoming Sprint. The Team then commit to trying to complete all of this work and will focus on these work items over the course of the Sprint.

Sprint Review

In this meeting The Team present to the PO and possibly other stakeholders what they've managed to achieve in the Sprint. They get feedback from the PO about what they've done and they learn and adapt from this feedback going forwards. The Product Backlog may also be adjusted based on both what was developed and any feedback given.

Daily Scrum (Standup)

This meeting is a planning meeting for The Team. It's an opportunity for the team to talk about what they did the day before, as this may implications for the work others are doing. The Team members should also discuss what they are planning to do that day so that help or advice from other team members can be given. If there's something blocking or slowing The Team down, then this can also be raised in the Standup.

Typically a team will review their progress through the sprint to make sure they are on track to complete all of the work they committed to.

This meeting is timeboxed to 15 minutes irrespective of team size. As it happens every day, with the whole of the development team, it's important to not let this meeting take too much time. It was originally called a standup as a meeting where everyone is standing is often shorter than when people sit down.

Retrospective

The meeting usually happens at the end of the sprint. The purpose of this meeting is to talk about what happened in the sprint and learn from it. Hindsight is a wonderful thing, although you can't go back in time and do a sprint differently, you can learn from your successes and failures and improve next time.

Grooming (Sprint Refinement)

There is a fifth meeting called Grooming. It's not officially part of SCRUM, but has become standard practice. In Sprint Refinement the PO gets to discuss pieces of work (which are called User Stories) with The Team and the outcome of these discussions is a better shared understanding of the work and an idea of how much work is involved in achieving the desired outcome. This enables The Team to work on the stories with more confidence that they understand the requirements, and allows the PO to better prioritise work in the backlog with an understanding of how much effort is required.

The SCRUM Process

A Sprint (a timebox of between 1 week and 4 weeks) starts with Sprint Planning.

Once The Team have a Sprint Backlog they start to create the Product Increment as a result of that work.

Each day of the Sprint, The Team meet in the Daily Scrum to plan and coordinate their work for that day.

At the end of the Sprint, The Team demonstrate the product increment they have created to the PO and maybe other stakeholders to both show the new functionality and gather feedback.

The team then holds a Retrospective to discuss and learn from the last sprint. They take these learnings into the next Sprint Planning session which kicks off the next Sprint.

Sprint Refinement sessions have no specific timing within the SCRUM Process, but its encouraged to hold them at a regular time and place within each Sprint.

The Four Agile Values

SCRUM is based on the following 4 agile values, taken from the Agile Manifesto:

We value... individuals and interactions over... processes and tools

We value... working software over... comprehensive documentation

We value... customer collaboration over... contract negotiation

We value... responding to change over... following a plan

SCRUM Values

When the values of Commitment, Courage, Focus, Openness and Respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum events, roles and artifacts.

Successful use of Scrum depends on people becoming more proficient in living these five values. People personally commit to achieving the goals of the Scrum Team. The Scrum Team members have courage to do the right thing and work on tough problems. Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. Scrum Team members respect each other to be capable, independent people.

(Scrum Values taken from: https://www.scrumguides.org/scrum-guide.html#values)

Good Practices that are not SCRUM

There are many good agile practices that are commonly used, but do not form part of SCRUM. Every team should probably know about these, but not every team would need to use all of these. Knowing that these do not form part of the SCRUM framework gives the teams flexibility to change one or all of these practices if they feel that they need to. You can be still be following SCRUM and not be doing one or more of these.

Mike Cohn, in his blog on March 14th, 2012 coined the phrase GASP (Generally Accepted SCRUM Practices) for these. Although there isn't a definitive list of these (as far as I'm aware), here is an example list of Good Practices that are not part of the SCRUM framework:

Generally Accepted SCRUM Practices

User Stories

Story Points

Backlog Refinement

Sprint Board

Definition of Done

Definition of Ready

Burndown Chart

Team Size of 5-9 People

Velocity Tracking / Capacity Planning

Scrum of Scrums

Dedicated Team Members (100% with team)

Co-located Teams

Release Planning