Why Does “Agile” Scrum Seem So Inflexible At Times?

Written by Paul D. Race for BreakThrough Communications, btcomm.com. Copyright © 2016 All Rights Reserved.

Agile software development methodologies were largely attempts to escape rigid top-down methodologies that held sway during the mainframe era. The movement was christened “Agile” because its promoters believed they were opening the doors to a new kind of flexibility in development processes.

Sixteen years later, the most widely-used “Agile” methodology is “Scrum,” which can seem anything but flexible to initiates. Scrum co-founder Jeff Sutherland claims that Scrum doesn’t achieve its maximum effectiveness unless organizations adopt the whole package. This includes specific ways of

Based on my experience, just defining Scrum roles, practices, and terminologies to a class of initiates takes hours. Giving Scrum newbies enough practice and understanding to set them up for success would take much longer than I usually have. But asking them to learn everything about Scrum “by rote” and to start working in (or even setting up) a Scrum environment the next day inevitably leads to complaints like “why is Scrum so complicated?” and “I thought this was supposed to make things easier for us.”

The truth is, in most settings where Scrum is implemented properly, life does get easier for everybody eventually. Nobody gets overscheduled, the end user gets the high-demand items first, people learn to size tasks more accurately, and so on. But that doesn’t happen unless organization completely commits to change. And that change has to affect every aspect of the development environment.

Change is hard. Even well-meaning people who are attempting to bring about change bring their own preconceptions and work habits to the project. And – frankly – the kind of changes Scrum requires gets a lot of professionals, especially old-school managers, out of their comfort zone. So they attempt, or request “compromises” like:

Yes, some of these “compromises” might improve the “comfort level” of folks who are responsible for development organizations. But any one of them allows the project to begin drifting back toward counterproductive old habits. Any two or three of them will keep the organization from ever realizing Agile’s potential benefits. In many organizations, such “compromises” have already caused projects to become “Agile” in name only – nothing substantive has changed.

Thirty years from now, consistent application of Agile principles may be “second nature.” Corporate cultures might be used to automatically practicing:

But in the meantime, there’s nothing “automatic” about getting out of decades-old habits and ruts. So making the adjustment takes commitment and deliberate action. And that means clearly defined roles, processes, procedures, and planned events. For now, at least.

If it helps, think of Scrum or related Agile frameworks like the scaffolding builders erect outside tall buildings during the construction process. If and when it’s time for any Agile framework to be removed from our software development environment, the result should not only be better software products, but also a better organization – one that is predisposed to operate according to the overriding principles that were intended to govern Agile in the first place.

In the meantime, we’ll certainly be facing some adjustments.