What is Scrum?

Have you ever heard someone say that they use Scrum in their workplace? If you are not familiar with the term, that’s okay. I’m here to give you a crash course in Scrum, why it is so popular in the workforce, and how it can be used in settings other than software development, where it is used most frequently.

Origin of Scrum

Long ago, in the dark ages of Waterfall and other early software development life cycles, software changes moved at the pace of a snail across the sticky side of duct tape. As the tech industry bloomed, it became clear that software needed to be delivered faster than the four releases per year average that Waterfall offered. Enter Jeff Sutherland and Ken Schwaber, the creators of Scrum and two of the 17 signors of the Agile Manifesto, written in 2001:

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

agilemanifesto.org

Their work continued diligently and in 2010, Jeff Sutherland and Ken Schwaber co-published the first version of the Scrum Guide, the culmination of their beliefs using Agile principles, empiricism and thinking borrowed from Lean manufacturing.

So, what is Scrum, exactly, and how do people use it?

The Basics of Scrum

First and foremost, Scrum is a framework, not a strict set of unwavering rules that must be followed. That means that it is intended to be widely applicable to many different applications. Software development just happens to be the most well-known use case for it, but it’s spread far wider than that by the time of this writing. At its core, it’s simply a way for complex problems to be overcome by disciplined teams who regularly look inward to improve their best practices.

The pillars of Scrum called out in the Scrum Guide are Transparency (being honest and open with one another), Inspection (looking inward to honestly assess the current state of things) and Adaptation (relentlessly improving on a regular basis). The Scrum Guide also states that “successful use of Scrum depends on people becoming more proficient in living five values: Commitment, Focus, Openness, Respect, and Courage.”

In order to achieve this, the Scrum Guide defines certain things that typically make Scrum Scrum.

Scrum Ceremonies / Events

Scrum is iterative. That means that Scrum is practiced in regular cycles of set lengths, wherein certain ceremonies (meetings) are practiced on regular intervals.

Sprint (or Iteration) – Work is captured and contained in a set period of time that the team and organization decides upon. One of the more common lengths for a sprint is two weeks.

Sprint Planning – The team decides at the beginning of the sprint what work they want to commit to completing, and they set a Sprint Goal, to help keep themselves focused on the value of what they are delivering at the end of the iteration. The work they intend to complete makes up the Sprint Backlog.

Daily Scrum – Every day, the Scrum Team meets to decide on the plan for the work the team will handle for the day, as well as discovering and discussing anything that might be stopping them from getting their work done.

Sprint Review – At the end of the sprint, the team reviews the work delivered with the stakeholders. By getting the completed work in front of the stakeholders on a regular basis, the team gets valuable feedback they can use quickly to improve the product.

Sprint Retrospective – The team meets together to review the health of the team and comes up with regular introspective (processes and behavior) and retrospective (how the past sprint went) feedback. The goal of this event is to continuously improve and mature as a team.

Scrum Accountabilities and Responsibilities

The Scrum Guide calls out only three accountabilities (previously called roles), to make a successful Scrum team.

Developer – This is any person who works on the work brought in to the team’s Sprint Backlog. In the software development world, these are engineers, database administrators, UX designers and others who all fit the role. These are the people who actually do the work, no matter what industry the team is a part of. A team typically is no less than three people and no more than nine, to keep things simple.

Product Owner – This is one person, not a committee, who manages the Product Backlog, the body of work to potentially be done in the future by the Developers. They are empowered to make decisions for the product, and they work with the Developers to help them understand the desired outcome and define acceptance criteria for the work called out in the Product Backlog. Teams pull from the Product Backlog to create their Sprint Backlog, and communicate often with the Product Owner to make sure they are aligned with the intended outcome.

Scrum Master – The Scrum Master is a servant leader who guides the team in their growth as a Scrum Team. They are not simply a meeting scheduler or a facilitator, although those often do fall under the Scrum Master’s regular responsibilities. They challenge developers to continue to look inward to improve as a team, and they work with them and the Product Owner to understand best practices of Scrum. They are protective of their teams and help shield them from outside distractions and impediments. A good Scrum Master is relentless in helping the team grow and maximizes their morale while keeping them on track with the work.

Who Can Benefit from Using Scrum?

While the most common application of Scrum continues to be in software development, its potential is much greater than that. It is possible to use the Scrum Framework in many different situations, both professional and personal. If there is a complex problem to be solved, Scrum was specifically designed to be able to be used to help solve it. Here’s an example, just to prove how powerful of a tool it is.

The Scrum Household

Can you run a household on Scrum? Absolutely.

In this example, let’s pretend my own family has decided to use Scrum. My wife Jodie, being a fantastic organizer and a wiz at checklists already, will serve as the Product Owner. I will serve as the Scrum Master, and my son and all three of us will also be developers, the ones doing the work.

We have determined that we will have one week sprints starting on Sunday and ending on Saturday. On Sunday we get together as a team to put together our Sprint Backlog – every chore, including the ones we do on a daily basis, are written down on a notecard. We use a form of a Kanban board to visualize the workflow, splitting the work into sections – To Do, Doing, Done. If we really want to be granular, we could even add an “Accepted” section, where Jodie determines if our work really meets her defined acceptance criteria.

Each card could be something like “vacuum the floor” or “make dinner”, and we could have one for each day of the week. We could also add other tasks on there that are not standard, like going to an appointment or calling to set up a consultation with a contractor. This can all be handled at Sprint Planning on Sunday, and discussed daily at our Daily Scrum.

We can even set limits for how much work we can have in the “Doing” section, so we can stay focused on one task at a time, maximizing the flow of work across the board. These may be facets of Kanban, but Scrum teams often tend to borrow them because they are good Agile practices, after all.

At the end of the Sprint, we can review how we did. In this case, we are also the stakeholders, so there isn’t a LOT to demo in the Sprint Review on Saturday, but sometimes there might be. The Sprint Retrospective would be an awesome opportunity to talk about what improvements can be made the next time we do this whole thing over again (the next day).

And, there you have it.

Conclusion

Scrum can be applied to many different situations. Any time there is complex work that needs worked through, it is possible to consider Scrum to complete it. Is Scrum always the best solution to every situation? No. But you may find that Scrum can apply to many more scenarios than you may ever have considered before.