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).
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.
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.
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.
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.
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.
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.
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:
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.
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 and Kanban are both agile methodologies, but they’re not synonymous:
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.
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.
The Scrum framework is well defined at scrumguides.org, but this quick overview covers the basics.
There are three primary roles in the Scrum framework:
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.
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:
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.
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.