The Scrum Survival Guide: How to Make Scrum Work (Maybe)

Every time I write an article about Scrum, there's always a sizable group telling me I’m doing it wrong. They insist that I need to read the Scrum Guide to truly understand it. Well, I’ve read the Scrum Guide—several times, in fact—but I decided to give it one more go, just to see if they have a point.

And because their objections are always so earnest, I decided to take them at their word and truly steelman their position—using the steeliest steelman I could muster.

It was no easy task. As commonly practiced, Scrum is highly constrained and riddled with problems. However, if you disregard anything not in the Scrum Guide, squint really hard, and use a few of Scrum’s ambiguities as loopholes to sneak some things in, I’ve come to believe that—maybe, just maybe—you can make it work.

But here’s the catch: for Scrum to work this way, your organization will need an extraordinary level of flexibility and open-mindedness. In my experience, I’ve never seen a company willing to make anything close to these concessions. And honestly, if I ever did encounter such a unicorn of an organization, I’d probably recommend using something else entirely—Kanban at the very least, if not Basecamp’s Shape Up.

However, if you find yourself with an unusually open-minded employer and, for some reason, you’re determined to stick with Scrum, here’s a list of practices to help make it the best it can be. If you can secure all of these, you might actually have something workable. If not, aim for as many as possible—any ground you can gain will be to your advantage. When making your pitch, remind your organization that Agile encourages self-organizing teams, so anything not in the Scrum Guide should be left to the software developers. Good luck with this list of ways to make Scrum work for you:

Pick the Largest Possible Sprint Size

The Scrum Guide allows sprints up to one month long, so always opt for the maximum length. Even if you prefer shorter iterations, you can run smaller “stealth” iterations within the larger sprint and keep them a developer-only thing. This way, you’ll gain some autonomy.

When it comes to choosing what to work on from the backlog, longer sprints benefit you as well, because you waste less time sizing and dividing the work. All you really need to determine is whether something can fit into a month—and a lot can fit into a month.

In fact, if you use the Shape Up method I describe in the next section, you won’t have to estimate anything at all.

Don’t Bother with Estimates

Forget story points, velocity tracking, and Scrum poker. None of that is required by the Scrum Guide. With longer sprints, you can tackle larger backlog items without stressing over their size. Since you're doing month-long sprints, you can adopt a strategy outlined by Basecamp in their online book Shape Up, which they’ve graciously shared with the world.

In a nutshell, Basecamp runs six-week development cycles (though to stay strictly to the Scrum Guide, the best you can do is four weeks—but that’ll work in a pinch). When it comes to deciding what to work on, a senior group “[will] define the key elements of a solution … at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves.”¹

Once the high-level description is assigned, they leave the rest up to developers—essentially asking for the best possible version that will fit within the cycle:

..we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. This is completely different from other methodologies, where managers chop up the work and programmers act like ticket-takers.²

Because the team owns the scope, they adjust it as they go. They shape the work to fit the cycle. This is the secret to skipping all those painful estimation and task division exercises.

I have to admit, reading this almost brings a tear to my eye. Working like this sounds exhilarating. I want to go to there!

Oh, and as a bonus, you can ditch those backlog grooming and refining meetings. You don’t need them. And lucky for us, they’re not required by the Scrum Guide anyway.

Keep Metrics Internal to the Team

The Scrum Guide doesn’t prescribe any specific metrics or tracking, so kick that stuff to the curb right away. Occasionally, you might want to track a few things for your own reference, but don’t share this information with your manager. Follow the advice from the authors of Peopleware:

Work measurement can be a useful tool for method improvement, motivation, and enhanced job satisfaction, but it is almost never used for these purposes. Measurement schemes tend to become threatening and burdensome.

In order to make the concept deliver on its potential, management has to be perceptive and secure enough to cut itself out of the loop. That means the data on individuals is not passed up to management, and everybody in the organization knows it. Data collected on the individual’s performance has to be used only to benefit that individual. The measurement scheme is an exercise in self-assessment, and only the sanitized averages are made available to the boss.

…The individuals are inclined to do exactly the same things with the data that the manager would do… The manager doesn’t really need the individual data in order to benefit from it.³

Read that to your manager and see what they say!

On a related note: I once told my boss that I didn’t think he needed to see our burn-down chart, and he promptly scheduled a long 1:1 to discuss why I didn’t trust management. Needless to say, I didn’t get that promotion I was hoping for.

Use a Low-Tech Tool to Track Engineering Work

The Scrum Guide outlines two backlogs: the Product Backlog and the Sprint Backlog. While the Product Backlog falls under the purview of the Product Owner, the Sprint Backlog is entirely within the developers' domain. The Product Owner will likely choose something nauseating like Jira to track Product Backlog items, but according to the Scrum Guide, developers are free to manage their sprint work however they see fit.

For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done… How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.⁴

So do yourself a favor and pick your own tool. I recommend something low-tech. If you’re co-located, you can go old-school with index cards on the wall. But even if you need to go digital, Google Sheets is all you need⁵, and it’ll still be pretty hard for your boss to milk that for “productivity motivating” information.

The Scrum Master Should Be a Developer

The Scrum Guide doesn’t require the Scrum Master to be a dedicated role, so a developer on the team can easily take the job. In fact, I recommend rotating the responsibility among any developers interested in giving it a try.

Not having an official Scrum Master will save you the trouble of convincing someone whose job depends on maintaining a complicated system that the system doesn’t need to be complicated. As Upton Sinclair put it:

It is difficult to get a man to understand something, when his salary depends on his not understanding it.⁶

Developers Should Run Their Meetings

The Scrum Guide doesn’t specify who must run meetings, except for stand-ups, which it explicitly states should be run by developers. This gives you solid backing to insist that all your meetings be developer-led—it is the development process, after all.

But seriously, at the very least, no one practicing Scrum should tolerate not being able to run their own stand-ups. The Scrum Guide is clear about that. Don’t let anyone tell you otherwise:

The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.⁷

Ban Public Shaming in the Review Meeting

Contrary to the beliefs of some Scrum Masters, the review meeting is not an opportunity to crack open Jira and publicly ask developers why they didn’t complete their sprint work, especially in front of stakeholders—who may include department heads or even the CEO. This kind of public scrutiny is a special kind of torture no one deserves. I worked in such an environment for a time, and it took a toll on my mental health. Limit this meeting to a demo of working software. After all: “Working software is the primary measure of progress.”⁸

The demo/review meeting should focus on the product, not on individual developers. It’s a chance to celebrate progress, not punish those who didn’t complete their work (for any number of reasons).

Insist that developers lead this meeting and use it for the right reasons.

Daily Stand-Ups: Make It Bearable

The Scrum Guide mandates daily stand-up meetings, so you'll have to live with that. However, you can improve things by ditching the typical "Yesterday, Today, Blockers" format, which turns the stand-up into a daily status report. The Scrum Guide gives developers full discretion to decide on the stand-up format, so you have the freedom to make it much better for yourselves.

To improve it even more, allow developers to simply say “pass” if they have nothing to share. Or better yet, don’t ask for individual reports at all—just start with, “Does anyone have something they want to bring up?” and let people volunteer information. That should make stand-ups far more bearable — and maybe even a little useful.

Allow Specialization

It’s common to hear people say that in Scrum, everyone must be able to work on any task, essentially banning specialization. This is not supported by the Scrum Guide, which simply states that the team must collectively have the ability to work on any task. In other words, the team should be cross-functional—nothing more. Requiring uniformity of skills is neither practical nor useful.

So, drop this artificial requirement. Assign tasks to the people who are particularly good at them. It’s absurd not to give a networking task to your networking expert, or to keep your computer graphics specialist from working on the OpenGL tasks. I’m familiar with the "Bus Test," and frankly, I think it’s overblown. If someone really does get hit by a bus (heaven forbid), you’ll figure it out—especially if you make an effort to share knowledge across the team.

Let people excel at what they’re good at. Allow them to become star contributors in their areas of expertise. Developers crave this kind of mastery and recognition. Don’t let Scrum take that away.

Eliminate Management Where You Can

The Scrum Guide defines three team roles: Product Owner, Scrum Master, and Developer. Don’t let anything else creep in. You don’t need Architects, Team Leads, or Security Specialists. You don’t need special titles or committees—those just add extra bureaucracy. Work as peers, and you’ll be happier.

Exploit the ‘Sprint Goal’ Loophole

Now we get to the part where I really stretch the limits of what the Scrum Guide allows. In Scrum, when you start a sprint, you're supposed to set a Sprint Goal:

The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning.⁹

What’s a bit ambiguous is whether you can add things to a sprint, in line with the Sprint Goal, that aren’t in the backlog. While the Scrum Guide states that the Product Backlog “is the single source of work undertaken by the Scrum Team,” it also says:

The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.

As the Developers work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.¹⁰

I even tried to google for more clarification, and google’s AI seemed just as confused as me:

Google Search Query: in scrum can you do work that's not in the product backlog but relates to the scrum goal

According to Scrum principles, you should not be doing work that is not listed in the product backlog; however, if a task directly supports achieving the current sprint goal, even if not explicitly listed, it can be considered for inclusion in the sprint backlog and worked on with transparency and discussion with the Product Owner.

And this is when I started thinking, this might be a fortunate ambiguity. So, I’m going to go with the idea that, in the spirit of the Sprint Goal, you can pull in things you’d usually have to debate with the Product Owner about adding to the Product Backlog—things like refactoring, research, or training. I’m even going to go out on a limb and argue that you should occasionally insert a shorter sprint (which should be fine, since the Scrum Guide doesn’t require consistent sprint lengths) to rest and catch up on things you didn’t have time for during other sprints. A Sprint Goal to “take a break from constant deadline pressure” might sound lazy, but it’s a worthy cause. For more on this, check out Why Scrum Is Stressing You Out.

Conclusion

I know, I know—this is an absolute moonshot. But if even a small number of people manage to pull it off (or something even close), I’ll concede that the Scrum advocates are right: Scrum itself isn’t the problem—bad management is. However, if no one can actually practice a Scrum like this, wouldn’t it be fair to say that Scrum shares at least some of the blame for the chaos we face at work? Shouldn’t a good system be practical enough that someone, somewhere, can follow it without getting steamrolled by their boss?

Maybe there’s no perfect answer to this dilemma, but at least it was a worthwhile exercise in finding ways to survive Scrum a little better.

A Final Caveat: Product Ownership

There’s one thing I couldn’t find even the flimsiest workaround for. Scrum gives the Product Owner (PO) complete control over all product decisions. In the Scrum Guide, this is ironclad—they must have had a lawyer write this part. And I believe this is a major flaw. While you might be able to live with it for a while, I don’t think it leads to long-term job satisfaction. For more details on why, check out my article here.

1. https://basecamp.com/shapeup/0.3-chapter-01#six-week-cycles

2. https://basecamp.com/shapeup/0.3-chapter-01#six-week-cycles

3. Peopleware: Productive Projects and Teams by Tom DeMarco and Timothy Lister

4. https://scrumguides.org/scrum-guide.html

5. Suggestion courtesy of Kent Beck:

6. https://www.goodreads.com/quotes/21810-it-is-difficult-to-get-a-man-to-understand-something

7. https://scrumguides.org/scrum-guide.html

8. https://agilemanifesto.org/principles.html

9. https://scrumguides.org/scrum-guide.html

10. https://scrumguides.org/scrum-guide.html