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.
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.”1
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
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.
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.
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.”8
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.
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.