Turning Scrum into Best Practices

Ryan once worked with an organization whose Project Management Office created a 500-page Scrum manual that detailed the processes and “best” practices that all their Scrum teams had to follow. Not surprisingly, these “Scrum” best practices looked a lot like the old waterfall processes the company used prior to adopting Scrum. We aren’t against teams creating their own practices within the Scrum framework—that’s actually a good sign of a team that’s working well together. But we’ve seen many organizations take the idea of “best” practices too far (like with the 500-page manual). A best practice is a practice you adopt and use everywhere all the time as the best way to do your work. But the type of work that Scrum teams do is typically too complex for any particular practice to always be the best approach, so there’s no such thing as a best practice in Scrum.

At the other end of the “Scrum as a best practice” spectrum is the tendency to modify the Scrum framework itself. This can be very tempting, but don’t do it. When a team only uses part of the framework, they lose most of the benefits of working with Scrum. What do these framework changes look like? Here are some examples:

• Treating every Scrum event as optional. We have enough meetings as it is!

• Skipping the sprint review when there isn’t any work to show. I mean, it’s just a demo, isn’t it?

• Holding the daily scrum biweekly. Just because it’s called the daily scrum doesn’t mean we have to do it every day, right?

• Canceling the sprint retrospective in favor of getting more work done. Because who has time to improve?

• Ignoring the Scrum event time boxes. I mean, who doesn’t love a 45-minute daily scrum? (Spoiler: no one loves it.)

Scrum is a collaborative framework that teams work within to help them deliver working software frequently. Your team needs to deliver an increment every sprint so they can determine whether they’ve met stakeholder expectations, whether customers actually want the product that they’ve delivered, whether they’ve created value at a reasonable cost and timeframe, and whether they’re using the appropriate technologies. This feedback loop that the Scrum framework implements (between the Scrum team, stakeholders, and customers) is an example of risk reduction.

Along the way, you and your teams will discover that it’s really hard to deliver product increments. Changes will be required at all levels of your organization, from the Scrum team all the way up and down the org chart. Changing the Scrum framework, ignoring the rules of Scrum, and simply swapping out old jargon for new-and-improved terms won’t get you there.

When an organization is reluctant to fully adopt Scrum without making lots of customizations, we’ve found it useful to make a clear distinction between the Scrum framework and other complementary practices that the Scrum team is using. Often in our consulting engagements, we spend most of our time tearing out complementary practices in order to simplify things and firmly establish the core Scrum elements. Scrum teams should strive to get the basic elements of the framework solidly in place before they add any additional practices that may be needed.

Where does your team stand in terms of having the basic Scrum framework elements in place? To find out, try this simple exercise alone or with your team:

1. Write each element of the Scrum framework on a separate sticky note: Product Owner, Scrum Master, Development Team, Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, Product Backlog, Sprint Backlog, and Increment.

2. Next, grab a different color sticky note and write down each complementary practice your team uses (one per sticky note), such as story points, poker planning, or sprint burndown charts.

3. Now that you have a list of the Scrum elements and a list of the complementary practices, on every sticky note, write a score from 1 (we aren’t doing this at all) to 5 (we’ve mastered this).

4. Finally, reflect on how you can get every Scrum element sticky to a 5. Are you spending too much time and effort on complementary practices? Are any complementary practices prohibiting a Scrum element from getting to a 5?

Best practices work well for work that is repeatable or can be standardized, but Scrum is designed for solving complex problems. All too often, we cling to best practices as a way to feel like we know exactly what’s going to happen. Wouldn’t it be great if we could follow a 100-step process (filled with best practices) and always get the results that we expect? However, complex work doesn’t play out that way. We need, instead, to be transparent both within the Scrum team and to the wider organization, to have frequent opportunities to inspect and evaluate our work, and to have the ability to make adaptations as needed. Scrum is a simple framework with 11 elements that provide a means of using empiricism (transparency, inspection, and adaptation) to your advantage. Adding complementary practices to Scrum may enhance the framework, but you must be doing Scrum well before you adopt any additional practices.