What Is Scrum, Anyway? An Introduction to Scrum Development

My conversation with Dominika started with the fundamental question: when we say “Scrum,” what do we mean by that? Her answer matched almost exactly the definition provided in the official Scrum Guide:

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

Oh, and Scrum is also a rugby term, meaning a “restarting of play after a minor infringement” (or so says Wikipedia, because I don’t know a thing about rugby). That’s where it got its name, actually.

But really, Scrum results from an evolutionary process to make work on complex products faster and better. It’s a set of guidelines for roles and events used by development teams around the world.

But really really, Scrum is an answer to a software development model called Waterfall. In Waterfall, all the features of the ordered product are delivered at once, as a complete package. You may design and order a piece of software, let the developers do their work, and then receive the finished product a year later.

I’m sure you can see the potential problems with Waterfall. It sounds convenient at first and is a better choice sometimes. But a lot can change during a year. What if the finished product no longer fits your vision? What if it’s no longer viable on the market?

Clearly, with complex and ever-evolving products, another approach is needed. Something more Agile.

In comes Scrum, which understands that you can’t eat an elephant in one bite, or complete a software project in one year-long marathon.

Work under Scrum is done in Sprints—time-boxed periods of one month or less, during which the Scrum Team creates a potentially releasable Increment of the product. Then they show each Increment to the client, confronting it with their expectations and making sure that features included so far fulfill their needs.

Scrum strongly favors the empirical approach, focusing on what works in practice. Every Sprint provides the team with important empirical knowledge they can apply in subsequent Sprints, improving the process every time.

This applies especially to time estimates. You may notice, especially if you’re a developer, that when you try to predict how much time a piece of work will take, you are often way off the mark.

In Waterfall, if you misjudge the time needed to complete a piece of work, the deadline for the entire project might get missed. In Scrum, on the other hand, it will at most affect the current Sprint, and any potential delays will be communicated to the client at the end of the Sprint.

The core of the Scrum process are Scrum Accountabilities—previously called “roles” (Developers, Product Owners, and Scrum Masters)—and Scrum Events, which we will outline next.

Scrum is geared toward teams and facilitating teamwork. The main idea behind Scrum is that teams performing highly creative work require autonomy to achieve excellence. A team works best when it is driven by objectives, not tasks. How they achieve those is for them to decide.

The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. It is a cohesive unit of cross-functional, self-organizing professionals focused on the Product Goal. All the roles support each other—the organization and the client. The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.

What is important to note from the get-go is that a Scrum Team has a flat structure. There is no boss, no manager, no “person in charge.” Instead, members of the team support each other to ensure that everyone is doing their best work and to guarantee effective communication.

(That goes only for the team’s internal structure, of course. Outside of the team, management can still support the process through what’s sometimes referred to as “servant leadership.”)

Let’s dig into each of the Scrum roles and see who’s who.

The core of the Scrum Team are the developers, the ones responsible for the “how,” who create the actual product. Without them, the whole endeavor wouldn’t make much sense. Their job is to deliver a releasable Increment of the final product each Sprint.

They are also responsible for the quality of the Increment they deliver. To use a quote from the Scrum Guide: “Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.”

The Scrum Guide characterizes the Development Teams as “self-organizing.” They are bound by predetermined rules established with the client, but within those boundaries no one, not even the Scrum Master, can tell them how exactly to implement the required features.

Another aspect of the Development Team’s independence is that its members should have all the necessary skills to deliver the required features. As a complete package, they do not have to rely on external help, lowering the risk of slowing down the Sprint. This is why Development Teams often include not only programmers, but also UX designers and software testers.

You don’t want your Development Teams to be too big or too small. If the team has fewer than 3 developers, there is little potential to deliver meaningful Increments during a Sprint. On the other hand, teams with over 9 developers take too much work to coordinate their efforts.

The Scrum Master (SM) The Scrum Master is accountable for the Scrum Team’s effectiveness, or the “how fast.” The Scrum Master ensures that the team’s work is as productive as possible.

Obviously, having just interviewed one, this is the role I’ve learned the most about.

Scrum Masters are the grease in the team’s gears, ensuring that work progresses smoothly. They do it in a variety of ways: by facilitating Scrum meetings, by asking difficult questions such as, “Why are we doing this?” and sometimes by holding one-on-one coaching sessions with other team members.

The Scrum Master’s moment-to-moment work focuses on communication and motivation. One moment, they may be checking if the client is aware of upcoming meetings and is prepared for them; the next, the SM might be asking the team, “What can we change?” during one of the meetings.

They may also be looking for ways to visualize the team’s progress, showing that more tickets are being completed than created, or illustrating how the team’s planned improvements have been implemented since the previous Sprint.

The SM is also an educator, teaching the team about the psychological processes that influence their daily work, showing the factors influencing team relations and helping them maintain a positive and productive mood.

A Scrum Master strives to focus on facts, not opinions. You’d be surprised how often we can’t differentiate between the two. “Our backlog is not prioritized” is a fact. “We can’t get anything done with this messy backlog” is an interpretation of that fact. The Scrum Master keeps the conversation focused on facts and practical solutions instead of emotions and doomsaying. If the team complains about, say, getting “too many emails,” the SM comes back to them with actual email usage data, which may show that the actual time spent on emails has been declining.

The Scrum Master also protects Developers from unnecessary external influence, often coming from the client. On the whole, the role of the SM is to help the others understand which of their interactions with the team are helpful and which aren’t.

The SM makes sure that the team does not become overburdened with work at any point. Any new features that the client orders can become a serious impediment, and shouldn’t be passed to the team during a Sprint.

After all, interrupting a sprinting person is just asking for them to trip up.

There’s a popular opinion that the Scrum Masters don’t really do much, because their work doesn’t result in a concrete product—but as you can see above, the SM provides plenty of value. Without a Scrum Master, the Scrum Team may soon forget how to use Scrum properly, losing out on both motivation and efficiency.

The Product Owner (PO) handles the product, or the “what.” They make sure that the features of the upcoming product are clearly defined for the developers and valuable for the client. In many sources, especially in Scrum Guide, the Product Owner is presented as a value maximizer of the product, which seems to be the shortest and best definition of this role.

The Product Owner is the one that communicates the needs of the client, and what the client needs is simply the best product they can get. Therefore, the Product Owner is also in charge of the product vision, keeping in mind both its features and overall design, but also the associated costs and the market situation.

Their typical stance looks a little like this:

“The main users of the system spend too much time looking for a single transaction in the application. In the next Sprint, we need to make that time shorter. If you have any questions about the requested features, feel free to ask me.”

The PO is also in charge of the value of the work that Developers perform. They need to have the product vision and spread it among the team and the stakeholders. To succeed, it is crucial that their decisions are respected by the whole organization.

One of the PO’s top responsibilities is managing the Product Backlog—making sure that items in the backlog are clearly defined, understood, and prioritized. This doesn’t mean that the Product Owner must define and prioritize items alone, but they are the person held accountable for keeping the Backlog in order.

Dominika stressed that Product Owners do not have to be technically minded people. Instead, they should have strong business skills to facilitate communication between the client and the team.

While the Scrum Masters usually work in the same room as the team, Product Owners can be both internal and external, i.e. either on the client’s or the contractor’s side. Either way, they will do all they can to ensure clear priorities and communication.

To make sure that every Sprint is a success and results in a releasable product Increment, Scrum employs a range of Scrum Events, sometimes called ceremonies. Each has its own objectives and characteristics.

Scrum is simple to understand and difficult to master—by definition.

Regarding “simple to understand,” we hope this article provided you with a basic overview that will help you improve your work with Scrum teams in the future.

As for “difficult to master,” keep in mind that implementing Scrum is just the first step, after which you need to stick to its rules and let it run its course before reaping the benefits.

Not every software house manages to see that process to the end. They end up with half-baked Scrum-like practices that don’t really bring much benefit at all and also contribute to some misconceptions about Scrum as a whole. Although implementing only parts of Scrum is possible, the result is not actual Scrum.

We discuss the Scrum misconceptions and mistakes as well as the three pillars of Scrum in other posts. If you want to be the first to get our new blog articles, stay tuned by following our social channels—here’s our Facebook, Twitter and LinkedIn.

Over the years, we’ve helped a number of clients implement Scrum at their companies, particularly Evalueserve, who singled the change out as a key contributing factor in what they called their “best year ever for product innovation.” You can check out the full case study here to learn more.

And if you have any questions or needs related to Scrum or Agile, just reach out to us and we’ll gladly support you however we can!