How do we avoid Scrum adoption pitfalls?

In this episode, Professional Scrum Trainer Sam Falco addresses the question: "How do we avoid Scrum adoption pitfalls?"

Last week, a student asked me what are some common pitfalls that we see when organizations shift to Scrum from a “big design upfront” process like waterfall.

A big one is that they think it’s a silver bullet

Adopting Scrum doesn’t solve problems overnight. It doesn’t solve problems at all! Scrum will surface the problems in your ability to deliver so that you can fix them. Too many organizations falter when Scrum runs up against an organizational impediment and “the way we’ve always done it” wins out. One example of this phenomenon is when there’s an onerous change management system that prevents code from getting into production. Scrum teams complete an increment and it sits there waiting until someone approves it to be moved to production. Sometimes, the wait is so long that multiple increments pile up.

Some organizations will cling to that change management system even though it’s getting in the way. Success comes when they adapt to the new way of working. At one organization I worked with, the solution was to set up an experiment with one team working on a less risky area of code. Once they proved that they could safely put code into production without breaking things, it paved the way for broader changes to their process.

Another pitfall is that the organization doesn’t really adopt Scrum

In many cases, organizations claim to adopt Scrum, but what they really do is apply Scrum terminology to existing roles and processes. I frequently see the term “Product Owner” used—or maybe I should say abused—as a new name for a Project Manager. But those Project Managers carry on pretty much the way they did before. They lack any of the accountabilities or authority of a Scrum Product Owner. They shift from using Gant charts measured in weeks to plotting out a project in Sprints over several months.

And that’s another way this behavior manifests. They’ll use the name of Scrum events without understanding their underlying purpose. A Sprint lacks the focus of creating a usable increment. “Daily Scrum” is a daily status report. “Sprint Review” is a carefully orchestrated smoke-and-mirrors show with limited, if any feedback or collaboration with stakeholders.

Without using all of its roles, events, and artifacts—and the rules that bind them together—you’re not using Scrum. You’re probably perpetuating your existing system. You know, the one that wasn’t working for you before. This is the realm of “Scrum, but.” And “Scrum, but” is not Scrum at all.

They don’t make other necessary changes

Even when an organization adopts Scrum’s mechanics, they sometimes find that Scrum doesn’t provide the benefits they hoped for. Delivery improves a little, but it soon plateaus and it’s a struggle to keep improving. That’s because other changes are necessary to really reap the gains of Scrum.

A common organizational structure is to have teams organized around technical layers or components. For example, a User Interface team, a Data Access Team, a Service gateway team, and so on. Scrum requires that we produce a working increment each Sprint, which means one that’s in usable condition. Teams organized by layers or components face numerous handoffs and challenges integrating their work. There’s a loss of transparency, and they struggle to compete that working increment.

The solution is to form teams that can deliver complete features that cut across all layers. Scrum doesn’t tell you to do that, but it works best if you do.

Scrum also doesn’t tell you to adopt good DevOps practices, or incorporate Kanban techniques, or to refactor your code. They’re all still good ideas.

Scrum is incomplete for a reason and that’s so that you can identify what works best for your organization. You have to go beyond Scrum. I talked about the pitfall of “Scrum, but,” earlier. But “Just Scrum” isn’t enough. You need “Scrum, and.”

Adopting Scrum requires a shift in organizational mindset. Without that, people revert to familiar behavior, even if that behavior wasn’t effective. And adopting Scrum can’t be an endpoint. It’s the beginning of a journey of experimentation and continuous improvement. In the Trainer Talk episode “Why Does Scrum Have So Many Meetings?” a few weeks ago, I mentioned that implementing Scrum requires intentional, thoughtful organizational redesign. That’s true of implementing the basics of the framework, but it’s equally true about the wider ecosystem that Scrum teams work in. And just like I said in that earlier episode, that’s why you need a good experienced Scrum Master—and sometimes more than one—to guide your organization’s Scrum adoption.

Want to Learn More or Get in Touch?

Register for our upcoming web meetings by visiting agilethought.com/events