Stop Hating Scrum: A Practical Guide That Actually Works

Plenty of people hate Scrum. One Reddit user calls it “a whole bunch of nothing,” adding that the methodology is little more than fluffy statements about what should already be obvious. They have a point. Scrum should be obvious. Small, invested teams naturally tend to operate in many of the ways prescribed by the Scrum framework.

At larger enterprises, however, people often start behaving strangely. They try to function like an assembly line when building software, losing the cohesion a creative team needs. It’s these employees, the ones who start to feel like cogs in a machine, who say things like “not in my job description, not my problem,” who benefit the most from the Scrum framework.

Then there’s another problem. Agile training, as an industry, has suffered an influx of people without the necessary technical skills. People who have never written a line of code are trying to tell you how to build software. No wonder so many people hate Scrum!

The good news is that Scrum isn’t dead. You’re just not doing it right (yet).

Advantages and Disadvantages of Scrum

There is a prerequisite with which we should all start (more on that later), but there’s no silver bullet or one-size-fits-all approach. You’ll get where you need to go as long as you begin with the end in mind.

Benefits of Scrum

The Scrum methodology offers several advantages. The following should be your goals when implementing the framework. You can measure your success empirically by establishing key software delivery metrics, taking a baseline reading, and measuring change over time.

Regular Feedback

Through two-week iterations (or one-week, or three-week, or heck, how about one-day!), teams establish consistent feedback loops that allow early issue identification and quick course corrections. The customer has opportunities to provide input on actual working features, not just ideas. This guides prioritization of the feature backlog.

Consistent Delivery 

Each sprint produces working software, so the product stays in a shippable state. This enables more regular deployments and, combined with the feedback loop, keeps things moving in the right direction. 

The development team deploys features, which is not the same as releasing them. Features go into production, then the product owner can decide when those features are presented to the users. This is called feature flagging.

Reduced Risk and Increased Agility

Breaking work into small chunks allows teams to adapt to changing requirements without derailing entire projects or steering the product too far off course. It also prevents teams from spending too much time building the wrong features.

High Adaptability 

Contrary to misconceptions about rigidity, Scrum can be tailored to different team sizes and project complexities, from small startups to large enterprise organizations.

These benefits work together to create a development environment that prioritizes collaboration, transparency, and continuous improvement.

Why You’re Not Seeing Those Benefits (Yet) – Common Drawbacks of Scrum

Scrum isn’t perfect, and there are potential drawbacks. If it’s not working for you, it’s probably because of one of these problems:

• You haven’t achieved self-organizing teams.
• You’re thinking about projects instead of products, or trying to plan too far ahead.
• You don’t have organizational buy-in.
• You’re trying to force outdated management practices into a modern framework.

Almost all of this can be avoided by having a facilitator who understands the process. A facilitator with a strong background and technical know-how is even better, because a team of developers might not love being told what to do or how to work by a non-technical team member. Good facilitations and small mindset shifts will help you avoid confusion and frustration among team members.

What Scrum Is and Isn’t

At its simplest, Scrum is a set of rules and definitions that keep everyone on the same page. This isn’t about rigidity, it’s about defining the game. Baseball would be much harder to play (and watch) if some players got a fourth strike sometimes, and some teams put first base 70 feet from home instead of 90. We agree upon rules and workflows to bring order to complex processes.

Scrum vs. Kanban

Scrum and Kanban are both agile methodologies, but they’re not synonymous:

• Scrum uses fixed-length sprints, defined roles, and regular ceremonies to plan and deliver work regularly.

• Kanban is a continuous flow system that limits the number of ideas in progress at any given time as they move through stages like “to do,” “in progress,” and “done.”

Scrum is great for managing ideas, problems, and products. Kanban is great at managing projects and workload. We prefer Scrum because we’re committed to product thinking.

Agile Methodology vs. Scrum Framework

We hear it all the time: “Is Scrum the same as agile?” The short answer is no, but it’s easy to see why some people use them interchangeably. Scrum is a specific framework for implementing agile, which is a broader methodology as defined by the Agile Manifesto.

Scrum Guide: Getting Started with Scrum Methodology

The Scrum framework is well defined at scrumguides.org, but this quick overview covers the basics.

Key Roles in Scrum

There are three primary roles in the Scrum framework:

• Scrum Master – This is a facilitator who guides communication, removes obstacles for the team, and ensures smooth progression through sprints. Scrum leaders don’t control the vision, but they control the process.
• Product Owner – Product leaders act as proxies for stakeholders, especially the end users. A product manager articulates the vision, manages the product backlog, and prioritizes features. The role of a product leader is not to be confused with project management.
• Development Team – These are the people who actually carry out the work. A team of software engineers self-organizes around the jobs to be done as outlined by the product leader, then brings the vision to life.

Scrum Values

The 2020 Scrum Guide lists five values: “Commitment, Focus, Openness, Respect, and Courage.” Realizing all of these values is an exercise in cultivating productive mindsets. Some of it comes down to the personality traits of the individuals involved, but putting the right process in place goes a long way. Live up to these values to improve agility, reduce risk, get better feedback, and ultimately build better products faster.

Scrum Process

At it’s simplest, the process behind the Scrum process is to plan a sprint, go through the sprint, hold a retrospective, then repeat infinitely.

Imagine a stack of index cards. Every index card contains a description of something you want to do to your product, normally in the form of a user story. This is your product backlog.

The product owner selects a subset of the most important index cards that can be completed in a two-week period. This becomes the sprint backlog. The sprint backlog is the centerpiece of the sprint planning meeting, which has two objectives:

1. Define the work to be done.
2. Plan the technical and design tasks required to get the work done.

Technically, you really could use a stack of index cards for spring planning. Sticky notes are great, too. Modern teams normally use Jira to achieve the same level of visibility and transparency.

The daily standup is perhaps the most well-known of all the Scrum ceremonies, which makes sense—it happens every day. The daily standup is a checkin to review progress. Team members update each other on completed tasks, upcoming work, and obstacles to their progress.

At the end of a sprint, hold a retrospective. The sprint retro is an opportunity to review and reflect upon the sprint. This is where you highlight actionable opportunities for improvement.

How to Make Scrum Work for You

Scrum is highly adaptable. It works for software development teams at startups and enterprises alike. It can even work for marketing teams. But you have to learn to play by the rules before you adapt or even break them. Picasso didn’t start with abstractions of the human form.

This is one of the most common stumbling blocks. If Scrum isn’t working at your organization, it’s possible you tried your own version before learning the basics. Our version of Scrum at Sketch is highly adapted, but we started at the beginning and made changes that worked for us. After all, the other big stumbling block is getting caught up on dogma instead of focusing on productivity.

Whether you’re trying to take your first steps with Scrum, or just struggling to find that middle path between the disorder and the cult of big-A agile, let’s talk.