Software developers can be so confusing sometimes. They have so many names for different frameworks and solutions, each somehow better than the other.
Let’s say you want to hire a software development company, for example. They tell you that they work in an Agile way, that they use Scrum - but what does that mean? What does work under Scrum look like, and why bother with it?
It’s time to clear up the confusion, I told myself as I sat down with Dominika Brzezińska, one of STX Next’s Scrum Masters. Our goal was simple: to find the answers to all the Scrum questions you might have. What you’re reading right now is the result.
In this article, you will find all the need-to-know info on what Scrum is, what the roles of Scrum team members are, and what working under Scrum really looks like. Armed with this knowledge, you can form your own opinion on the effectiveness of Scrum practices.
What is Scrum?
My conversation with Dominika started with the fundamental question: when we say Scrum, what are we talking about? Her answer matched almost exactly the definition provided in the official Scrum Guide:
“Scrum is a framework for developing and sustaining complex products.”
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 is the result of 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 another software development model called Waterfall. In Waterfall, all of the features of the ordered product are delivered at once, as a whole 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 the superior choice in some cases. 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, in the case of complex and ever-evolving products, another approach is needed. Something more Agile.
It’s all about pace and practice
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.
Instead, work under Scrum is done in Sprints, time-boxed periods of 1-4 weeks during which the developers create a potentially releasable Increment of the product. Each Increment is then shown to the client, confronting it with their expectations, making sure that features included so far fulfill their needs.
Scrum is a big fan of the empirical approach, focusing on what works in practice. Every Sprint provides the team with important empirical knowledge that 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 wrongly estimate the time needed to complete a piece of work, the whole project might miss the deadline. In Scrum, 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 the three Scrum roles (the Development Team, the Product Owner and the Scrum Master) and the four Scrum events, which we will outline next.
Roles within the Scrum Team
Scrum is geared towards teams, and towards 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 fed objectives, not tasks. How they achieve the objectives is for them to decide.
A software development Scrum Team includes three groups of members: the Scrum Master, the Product Owner and the Development Team. All of the roles serve to support each other, the organization and the client, and to contribute to the smooth production of each increment.
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 Development Team
Of course, 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 potentially releasable Increment of the final product each Sprint. They are also responsible for the quality of the Increment they deliver.
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 Quality Assurance.
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) is responsible for the Scrum process, or the “how fast”. The Scrum Master ensures that the team’s work is as effective 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 the 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 that we can actually influence?” during one of the meetings, or 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 were 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 unprioritized” 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 is found complaining about, say, getting “too many emails”, the SM comes back to them with actual email usage data, which may show that actually, time spent on emails has been declining over time.
The Scrum Master also protects the Development Team from unnecessary external influence, most 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 really do nothing, because their work does not 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) is responsible for 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.
The Product Owner is the one that communicates the needs of the client, and what the client needs is 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 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 the Development Team performs. 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 organisation.
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 by value. This does not mean that the Product Owner must define and prioritize items alone, but they are the person responsible 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.
In practice, 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.
1. Sprint Planning
The planning meeting is the first meeting of a new Sprint. At the planning meeting, the team establishes what part of the work they want to tackle during the coming Sprint. They look at the Product Backlog and choose the most valuable features that they can realistically implement in the coming 1-4 weeks, creating the Sprint Backlog and the Sprint Goal. This is also the time when the Development Team establishes how exactly the features will be implemented.
2. Daily Scrums (Stand-ups)
The Daily Scrum occurs, as you might guess, every day during the Sprint. It usually takes around 15 minutes and helps ensure that the team is aware of what work has been completed the previous day, what will be done today and what blockers may be impeding work during the coming days. Thanks to the Daily Scrums, the team always knows whether it is on track to achieving the Sprint goals.
The Daily Scrum is sometimes referred to as the Daily Stand-up due to the widely accepted practice of standing up during the meeting. This is to ensure that the meeting remains compact; nobody wants to stand around for an hour and a half, after all.
But if you were to ask Dominika, standing up is really not important as some practitioners might think. As long as the team establishes work synchronization and creates a plan for the day, they might as well be lying down on waterbeds.
3. Backlog Refinement
Backlog Refinement is not one of the official Scrum events, but Dominika nevertheless mentioned it as one of the most important points of a Sprint.
During the Backlog Refinement, the team discusses what the PO/client needs and how to deliver it. Individual elements of the backlog are revised and compared to the overall project vision. In short, the team wants to know “Why do we want this?” in order to avoid unnecessary work on impractical features.
The importance of working on the Backlog becomes apparent at the start of the next Sprint. With a refined Backlog, the team can be sure that the planned features fit the client’s needs. They can plan the Sprint accordingly and get to work on implementing the features.
The Backlog Refinement doesn’t necessarily need to be an actual meeting; what’s important is the process. If the team finds a way to refine the backlog piecemeal or along the course of the Sprint, that is absolutely fine.
4. Sprint Review
The Review marks the end of the Sprint, and usually takes place during a conference call with the stakeholders of the project. The team shows the effects of their work to the stakeholders, sometimes explaining why some features did not make it into the resulting Increment. This meeting is the most important to keep all stakeholders happy and informed, and to discuss the product vision together.
The Sprint Review is an opportunity for the stakeholders and developers to meet. It also helps programmers change their perspective: instead of ‘just doing the work’ they shift to true development with the product vision in mind.
The Scrum Guide recommends a 4-hour Sprint Review meeting for each 1-month Sprint, but the meeting will be shorter for shorter Sprints.
5. Retrospective (Retro)
The Retrospective marks the true end of the current Sprint. Although as a rule, the next Sprint starts immediately after the last one, the Retrospective serves more as a moment of reflection and preparation before the next Sprint properly kicks off with another planning meeting.
The team starts by discussing any problems that may have arisen during the last Sprint and any improvements they would like to introduce in the next one. This is the time to go over any difficulties with the goal of making each new Sprint better than the last.
Scrum is simple to understand and difficult to master - by definition.
As for ‘simple to understand’, I hope that this article provided you with a basic overview that will help you improve your work with Scrum teams in the future.
With regards to ‘difficult to master’, you should 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-but practices that don’t really bring much benefit at all, and also contribute to some misconceptions about Scrum as a whole.