Over the past several years, agile software development methodologies have slowly become commonplace. While not all shops look to adopt such processes, others have found these methodologies to be answers to commonly occurring software development issues. Lack of communication, prolonged delivery dates and missed opportunities for mid-course corrections, to name a few, are some reasons why people are adopting agile methodologies. However, once adopted, each organization tends to tweak the methodology to their own needs, raising the question: Is there such a thing as an “agile purist?”

In a 2009 survey, Forrester, an independent research company, found that most teams see agile as an ethos, not a creed. Asking 575 enterprise IT professionals, the survey, called Global Developer Technographics, found that 47% of its respondents view their methodology as a helpful guide, but diverge from it in order to deliver on time. Only 15% of respondents said they followed their methodology closely and seldom diverged from it.

Dave West, a senior analyst at Forrester, said there will never be one agile religion because “people take bits.” And although he believes key agile concepts, like short delivery times, will certainly be fully adopted in time, one methodology will never prevail over another or be the answer to all software development process needs.

Practicality and flexibility are typical essentials in any shop, and agile offers a means to them. But most shops want to tailor what works best into their own processes, not simply follow a process religiously.

“What I’ve found is pragmatic as opposed to purist,” said Bola Rotibi, principal analyst at MWD Advisors, a European IT advisory firm. “When people first start out, they probably do do it [agile methodologies] verbatim, especially if they have no experience. Then they’ll look to work out the things that don’t work but leave the core principles. That’s what I mean by pragmatic. That’s the beauty of it.”

Of agile’s core tenets—daily standup, iteration planning and unit testing—VerisonOne found in its fourth annual “State of Agile Development” survey that 69% of the 2,570 participants adhered to these three things. Conducted last year between July 22 and Nov. 5, research by the agile project management tool vendor also found that Scrum, or a variant of it, was by far the most commonly employed methodology.

Fifty percent of the participants, from 88 different countries, responded to employing Scrum while 24% adopted a Scrum/Extreme Programming (XP) hybrid. The survey also found that 84% of participants worked in organizations that used agile development practices to some degree.

Forrester’s survey, conducted from July to August 2009, rendered similar findings. Thirty-five percent of the respondents mix agile with other methodologies, such as agile with traditional methods or agile with no formal process at all. “Hybrid models are the reality of agile adoption,” the report said.

“Agile is a sewn-together quilt,” said Robert Haaverson, CEO of Imanami, a group management solutions vendor. “You don’t need to change completely; you take bits and implement them along the way,” he added.

The main patches of agile
At the forefront of the agile movement are Scrum and XP, the most popular methodologies in catering to a shop’s agile needs, according to the researchers. Whether used exclusively or together, the two processes are usually adopted to some degree during development.

Even a variation of Scrum exists. Known as “ScrumBut,” it was dubbed for shops that don’t fully comply with the methodology. It is for those who say, “We are doing Scrum, but…” While some people may view this as non-agile, others argue it’s simply a customization of an agile process to work better for that particular company and its structures.

“I see the methodologies as a continuum, and at the end of the day it’s all agile with the same principles and practices,” said Bruce Eckfeldt, CEO and managing director of Cyrus Innovation, an agile consultancy firm. “There’s nothing set in stone on how to do something. You’re always looking to improve.”

Needing improvement on delivery times and communications to their outsourced counterparts in Pakistan, Scrum was adopted at Imanami. Experimentation started three years ago, going into full swing after the first year. “We needed it five years ago,” Haaverson joked, but said it is helpful for all of them to know what the process is and to cut down on documentation by writing user stories.

However helpful Scrum has been for Imanami, Haaverson wants to propose coupling it with some waterfall practices. In agile there is no beta, he said, and it is hard to find a happy medium between getting a pre-release up to par and not jumping to release because engineering says it is ready. But after all, “it’s about tweaking the process,” he said.

Perhaps the methodology that lends itself best to tweaking is XP. “One part of XP is to change XP,” said Neal Ford, a software architect at ThoughtWorks, an IT consultancy firm. “You do things that work for you, not because it’s in a manual,” he said, adding, “As soon as you become dogmatic about it, you’ve lost the game and your work becomes lackluster. You need to understand why you’re doing what you’re doing.”

Ford does foresee, however, agile methodologies being purely adopted in certain software development circumstances. And once you find a way that works for you, you stick with that, he said. Also it must be kept in mind that if a previous approach works, agile or not, it would be difficult for most people to leave that methodology behind, he added.

Avoiding the dogma
But for one software configuration management vendor, old methods weren’t working anymore. Nellie Lemonier, a Perforce user interface designer and Scrum master, experienced first-hand the adoption of an agile methodology.

Implementing Scrum in-house a little less than a year ago, she and her team now develop in three-week sprint cycles, as opposed to their previous six-month milestones. Lemonier said she has found the team to be more empowered and have more internal awareness of what’s being accomplished.

Collaborative work, one of the tenets at agile’s inner core, allows her teams to look at a product backlog, and determine why a feature is important and if it can be accomplished in the sprint cycle, Lemonier said. “It also gives the team the opportunity to define what ‘done’ means,” she said, adding, “We tried to be textbook in the beginning, but it’s been an organic implementation.”

Of the initial agile adoption phase, Eckfeldt agreed that “things may be reasonably pure,” but then people start to see what works or not and begin “to look beyond the textbook versions of agile.”

Although some people view agile as a process best worked in pieces, and therefore can never truly be pure, others take what they regard as a pure approach. The Motley Fool, an Alexandria, Va.-based multimedia financial services company, define themselves as holistically agile. “It comes down to organizational acceptance—from the teams that are actually building the software and websites all the way to the execs. Everyone is accepting of it,” said Maxwell Keeler, vice president of The Motley Fool project management.

Prior to adopting Scrum, The Motley Fool took a more traditional approach of defining the scope, requirements and delivery date, oftentimes leaving the development teams waiting for the work, Keeler said. Now, since their company-wide Scrum “kickoff” in December 2007, they release every two weeks and make sure all teams are 100% utilized, he said.

Two years and 54 sprints later, Keeler considers the agile methodology a success, but estimated they are only about 80% aligned with “Orthodox Scrum.” Where they deviate, he said, is not following an estimation of hours to determine capacity, finding it was too much overhead for two-week sprints. They also bend rules about releasable products after each sprint, saying that during development, the product owner usually reviews 75% of the features and foregoes the final signoff at the end.

However, Keeler still believes The Motley Fool to be purely agile because the Scum methodology is accepted from the top down, despite some deviations along the way.

Agile methodologies can also never be followed religiously because every organization is different from its internal structure to what they develop in-house. Because of this, agile can never be followed stringently, said MWD’s Rotibi. “You have to be sensible,” she said. “A process is only as good as it’s meant to work.”

People may have adapted their own ways of doing things, Rotibi said, but they have taken short iterations, small teams and costumer involvement to a new level. “This way breaks down silos and that’s what agile is about, but it is also disciplined to ensure you’re able to deliver.”

Because of agile’s malleable structure, some skeptics also argue that it is not as structured as traditional approaches, citing less documentation and upfront design. However, Forrester’s West agreed with Rotibi that agile is actually driving more discipline into how people are doing software, but he said there is no “one religion.”