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

• Defining roles,
• Organizing and prioritizing software updates,
• Defining update requests,
• Scheduling development activities, and
• Using meetings and reports.

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:

• Calling the project leader the “Scrum Master” but keeping all of his or her old responsibilities and authority.
• Letting “busy people” skip the “Daily Standups.”
• Adding Scrum responsibilities and tasks to everyone’s workload without removing any of the old responsibilities or tasks.
• Prioritizing easy updates over the updates that the end users need most.
• Telling the team how many updates they need to complete this cycle, rather than letting team members estimate the size of tasks and commit accordingly.
• Assigning tasks to team members directly instead of letting the members choose their assignments.
• Letting “requirements” that are vague or untestable as written into the workflow because we don’t have time to “nit-pick.” Or, just as bad, planning every update to the last detail six months in advance.
• Having a flexible “definition of done” that allows updates to skip rigorous testing and cause problems later.

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:

• Continuous customer engagement
• Self-governing teams in constant communication
• As-needed detail planning
• Incremental development with small, frequent updates
• Effective definition and prioritization of individual requirements, and better tracking through the development cycle

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.