BROADCASTS.com

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 \u201cbig design upfront\u201d process like waterfall.

A big one is that they think it\u2019s a silver bullet

Adopting Scrum doesn\u2019t solve problems overnight. It doesn\u2019t 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 \u201cthe way we\u2019ve always done it\u201d wins out. One example of this phenomenon is when there\u2019s 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\u2019s 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\u2019t really adopt Scrum

\xa0In 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 \u201cProduct Owner\u201d used\u2014or maybe I should say abused\u2014as 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\u2019s another way this behavior manifests. They\u2019ll use the name of Scrum events without understanding their underlying purpose. A Sprint lacks the focus of creating a usable increment. \u201cDaily Scrum\u201d is a daily status report. \u201cSprint Review\u201d 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\u2014and the rules that bind them together\u2014you\u2019re not using Scrum. You\u2019re probably perpetuating your existing system. You know, the one that wasn\u2019t working for you before. This is the realm of \u201cScrum, but.\u201d And \u201cScrum, but\u201d is not Scrum at all.

They don\u2019t make other necessary changes

Even when an organization adopts Scrum\u2019s mechanics, they sometimes find that Scrum doesn\u2019t provide the benefits they hoped for. Delivery improves a little, but it soon plateaus and it\u2019s a struggle to keep improving. That\u2019s 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\u2019s in usable condition. Teams organized by layers or components face numerous handoffs and challenges integrating their work. There\u2019s 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\u2019t tell you to do that, but it works best if you do.

Scrum also doesn\u2019t tell you to adopt good DevOps practices, or incorporate Kanban techniques, or to refactor your code. They\u2019re all still good ideas.

Scrum is incomplete for a reason and that\u2019s so that you can identify what works best for your organization. You have to go beyond Scrum. I talked about the pitfall of \u201cScrum, but,\u201d earlier. But \u201cJust Scrum\u201d isn\u2019t enough. You need \u201cScrum, and.\u201d

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

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

See available training courses at agilethought.com/training.

Visit the website and catch up with all the episodes at AgileThought.com!

Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!