The first thing any leader must know about Scrum is this: Scrum is easy to understand and hard to implement. I would go so far as to say Scrum’s simplicity is a blessing and a curse. That simplicity is where you must start your understanding, however. So, let’s get started.

What Is Scrum?

The official definition of Scrum is, “Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.”

This lightweight framework includes Scrum Theory, Scrum Values, the Scrum Team, the Scrum Events, and the Scrum Artifacts. Let’s discuss each in turn.

Scrum Theory

At the core of Scrum Theory are the concepts of Transparency, Inspection, and Adaptation. These concepts are so integrated into many organizations that it is easy to ignore the iterative gains they bring to a mature team or organization.

Transparency is the concept that everyone involved in the Scrum process must be dedicated to bringing forward the information, problems, stresses, and practices that help or inhibit our quest to create valuable solutions for our stakeholders. If the team feels comfortable fully examining and exposing reality, transparency will thrive.

When transparency exists, and it must for Scrum to thrive, inspection is the next logical concept that follows. “[P]rogress toward agreed goals must be inspected frequently and diligently to detect potential undesirable variances or problems.”

When we are able to inspect reality, we can make the changes needed to right the ship or continue on our current course. That is where adaptation comes into the process. Adaptation is where the rubber meets the road. The sooner we can make adjustments, the more likely we will be to achieve ultimate success.

In a nutshell, Scrum is about going through small iterations of transparency, inspection, and adaptation. This creates an environment of continual improvement.

Scrum Values

There are five core Scrum Values: Commitment, Focus, Openness, Respect, and Courage. The true direction of the Scrum Team comes from these five values. 

The team commits to achieving its goals and supporting each other. They focus on the work of each Sprint to make the best possible progress toward the goals they have determined are important. In alignment with the concept of transparency, the team is open about the work they are doing and the challenges they are facing. This openness is able to exist because of the respect they have for each other. Finally, the Scrum Team must have the courage to do the right thing, even when that courage is hard to conjure.

The way Scrum is implemented in your organization should seek to maximize, not diminish, these values. When the values come together with Scrum Theory, they form the lifeblood of trust within your organization.

Scrum Team

The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. They are all focused on one thing: the Product Goal. There is one very important concept regarding the team I want to make sure I impress on your mind: The members of this team must, collectively, have all of the skills necessary to create value each Sprint.

Perhaps there is no concept of Scrum more empowering and important than the next concept I want to discuss, however, the concept of a self-managing team. The team itself decides who does what, when, and how. This team, typically consisting of 10 or fewer people, is able to communicate effectively and take greater ownership when external control over how the work is performed fades, leaving intrinsic drive to take over. This is where the concept of trust is most valuable. They are empowered by the organization to manage their own work, and, when they are, magic happens.

The Developers are the people on the team who are committed to creating a usable Increment each Sprint. They create a plan for each Sprint, called the Sprint Backlog. (Note: There are two backlogs in Scrum. This is one of them. Yeah, confusing, I know.) The Developers do quality work, adapt their plan each day, and hold each other accountable.

The Product Owner is the individual who is accountable for maximizing the value of the product. They also are accountable for managing the Product Backlog (Note: This is the other backlog in Scrum.) The Product Owner develops and communicates a Product Goal. They create and clearly communicate the Product Backlog items. They order the Product Backlog, and ensure the Product Backlog is transparent, visible, and understood. The Product Owner can delegate these responsibilities, but they remain accountable for them.

One of the most important concepts you can instill as a leader is this: The entire organization must respect the decision of the Product Owner. That includes you. Trust them to do their job. I am sure, by now, the theme of trust is obvious. Trust is at the core of Scrum.

This brings us to the last person on the team: the Scrum Master. The Scrum Master is accountable for establishing Scrum. They help everyone in the entire organization understand and practice Scrum. The team’s effectiveness is at the heart of the Scrum Master’s job. Their responsibility is one of serving the team and the organization.

The Scrum Master can serve others by coaching the team and others, removing impediments, facilitating Scrum Events, helping determine techniques the team can use, and facilitating stakeholder collaboration. They lead, train, and coach. They plan and advise Scrum implementations within the organization, enact an empirical approach to the work, and remove barriers between stakeholders and the Scrum Team.

Scrum Events

There are five Scrum Events (sometimes referred to as ceremonies): The Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.

The Sprint is the container event for all of the other events. Sprints are fixed-length events of one month or less. Sprints are all about inspection and adaptation. Each Sprint may be considered a short project.

Sprint Planning is the first event within the Sprint. In this event the work that will be accomplished in the Sprint is planned by the entire Scrum Team. The types of things that are discussed are: Why is the Sprint Valuable? What can be done this Sprint? How will the chosen work get done?

The Daily Scrum is a short (at most 15 minutes) meeting held for the Developers. The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog, if needed. The Developers select the structure of this meeting.

The Sprint Review is held to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders in this event. The Scrum Team and Stakeholders also use the event to collaborate on what to do next. It is a working session, not a presentation.

The Sprint Retrospective is a meeting where the Scrum Team discusses and plans ways to increase quality and effectiveness. They determine the most helpful changes they can make to improve. The Sprint Retrospective concludes the Sprint.

Scrum Artifacts

The Scrum Artifacts include: the Product Backlog, the Sprint Backlog, and the Increment. Each Scrum Artifact is designed to maximize transparency. 

The Product Backlog is an ordered list of what is needed to improve the product. It is the ONLY source of work taken in by the Scrum Team. The team works to refine the items on the Product Backlog. Once these items are refined to the point where they can be accomplished within one Sprint, they are ready to be selected for a Sprint in the Sprint Planning event.

The Sprint Backlog includes the Sprint Goal (the why of the Sprint), the set of Product Backlog items selected (the what, selected by the Developers) for the Sprint, and the actionable plan for delivering the Increment (how the work is to be done). 

The Increment is the body of work completed during the Sprint, and it is additive to all prior Increments. The Increment must meet a Definition of Done, which is a formal description of the state of the Increment when it has met the quality needed for the product.

Why is Scrum Hard to Implement?

We’ve established the structure and simplicity of the Scrum framework. It seems simple enough, right? So, what makes it hard to implement?

Scrum asks organizations to expose problems instead of hiding them. It asks leaders to give meaningful decision-making authority to other people. It asks teams to manage themselves. It asks Product Owners to make difficult ordering decisions, and it asks executives to honor those decisions. It asks people to inspect evidence and change course. It makes dysfunction visible, rather than allowing processes that conceal it.

Most importantly, Scrum doesn’t magically fix any of these problems. It gives you a framework. Your job isn’t to make the team “do Scrum”. Your job is the difficult one of creating an organization in which Scrum can actually work. That, my friend, is anything but easy.