Almost every year, on or around April 1, Mountain Goat Software releases a new mock product for the agile industry. This year, we’re introducing the Scrum Police.
On the new, official Scrum Police site you can report crimes against Scrumanity, view a log of recent convictions, and even confess your own crimes before you are turned in by your teammates.
Join the Fun at ScrumPolice.com
The crimes range from truly silly to a little bit detrimental to your team’s well-being. Here are just a few examples of some that won’t really land you or your team in jail, but I wouldn’t necessarily recommend:
- Skipping a daily scrum
- Starting a sprint without a sprint goal
- Being both the Scrum Master and product owner
- Finishing a sprint without meeting the definition of done
It’s fun, it’s funny, but it’s also strangely true.
Agile Is About Recommendations, Not Rules
The idea for Scrum Police came from the fact that more and more people seem to want to codify agile into a set of strict rules: "You must do this" or "If you don't do this or all of that then you're not doing it right."
Here’s my advice: Make recommendations not rules. There are very few hard-and-fast rules to being agile:
- Work in iterations (sprints) of no more than a month long
- By the end of each iteration be "done" with something to some pre-agreed upon definition of done and solicit feedback from your key stakeholders on it
- Get together at the start of every iteration to figure out what you're doing to do during that period of time
- At the end of the iteration, reflect on how you did during that time (both in terms of what you delivered and how you delivered it)
- Talk a lot during the iteration
Beyond that, it's much more about recommendations. And there are plenty of things we've learned in the several decades now that agile processes have been around, even in informal forms.
For example, I recommend teams use user stories as their approach to requirements. I recommend teams use story points for estimating. I recommend that the team pick a day other than Mondays for starting their iterations. I recommend the Szechuan Chicken at Spice China.
But none of these things is required for success with agile. Each may help a team be better, and I have reasons I recommend each. But these things are not required.
There Is No One True Way to Be Agile–Or Is There?
No matter what the Scrum Police say, there is no perfect path to agility that works for every team, every time.
Like many things in life, multiple approaches can work.
For example, there are two equally convenient routes from my house to the airport. The fastest is to take a toll road that passes about a mile from the house and goes directly to the airport. But that costs $8. The other route takes about 10 minutes longer, but saves me those eight dollars. Sometimes I take the first route. Other times, I’ll take the second.
There’s no one perfect way for me to get to the airport. Similarly, there’s no one perfect way for a team to be agile. This is why agile is best defined by its principles rather than specific practices.
Despite this, there are people who think agile can be turned into a set of thou-must-do-it-this-way rules. Some people tell me every team benefits from timeboxed iterations (sprints). Others insist that two-week sprints are always the best. A popular book on Scrum insists that the daily scrum must be conducted left to right starting with the person to the left of the ScrumMaster.
They don’t. They aren’t. And it shouldn’t.
Scrum is deliberately incomplete. Sure, some group of gurus could get together and decide once and for all what sprint length is best. They could decide that all sprints should start on Tuesdays, and that teams must do pair programming on exactly 70 to 80 percent of all code they write. But these are decisions best made by the team.
And just like me en route to the airport, some teams will choose one way, and others will choose another. And that’s how it should be.
So, perhaps there is one true way to do agile—the way that works best for each team.
And for those who don’t agree, there’s always the Scrum Police.
