Manage Learn to apply best practices and optimize your operations.

The Agile method remains confusing for software professionals

The Agile method is subject to interpretation, according to a recent voke inc. survey. More than 200 software professionals defined Agile differently.

What is Agile software development? A new voke inc. survey revealed that the answer to this question is subject to interpretation, and that confusion about Agile has led to cost overruns and, in some cases, project failures.

Greater than 200 software professionals recently surveyed by voke, a software and application lifecycle management analyst firm, gave more than 100 unique definitions of Agile. Additionally, 57% of enterprise companies and 34% of technology companies expressed confusion about Agile's practices; 64% found the transition to Agile confusing; and 9% could not define Agile at all. The result of this confusion? The majority of software organizations practicing Agile development don't know exactly what Agile is, are doing very different processes, and are dependent upon Agile consultants for direction, according to Theresa Lanowitz, co-founder of voke.

Businesses' desire for software speed and flexibility has been misinterpreted as a mandate to participate in Agile, a movement that Lisa Dronzek, voke co-founder, calls a "developer-centric movement." This business directive spurred a rush to adopt Agile, a generalized methodology that isn't process-specific, which may or may not be appropriate for all organizations or projects.

Voke surveyed business leaders within a broad demographic that included different types and sizes of companies and various management titles. Forty-four percent of respondents represented small businesses; 21% Fortune 500; 16% Fortune 100; 8% Global 2000; 7% Fortune 1000; and 4% government organizations. About 14% were QA/test managers, followed by 10% who were senior-level executives; 9% were developers; and 1% were operations managers.

Searching for the meaning of Agile

Seeking to define Agile, Dronzek and Lanowitz turned to the Agile Manifesto, the document that established Agile in 2001. From it, they concluded the following:

  • Agile is a developer-led movement that places less value on processes, tools, documentation and following plans than other methodologies.
  • Agile is a movement.
  • The Agile movement was created to sell Agile services, a conclusion drawn from the Manifesto, which stated, "We are uncovering better ways of developing software by doing it and helping others do it."
Some of the things you see now, like the branding of different flavors of Agile -- I definitely think that's people try to make a buck.

Lisa Crispin, Agile coach

"It's a very brief and not very specific document," said Lanowitz. By not specifying practices or techniques, the Manifesto leaves Agile up for individual interpretation. One Agile coach's approach could be very different from another's and still be labeled Agile. For example, survey respondents reported that they thought they had fully adopted Agile development, but were told -- by Agile consultants not hired for that project -- that they were "only" doing Scrum and not Agile. Yet many respondents considered Scrum and Agile synonymous and chose Scrum for its step-by-step process. "And they said, 'Well, this was working for us, but should we change to be more Agile?'" said Lanowitz.

And what would "more Agile" be? It's unusual for a software development methodology to remain as nebulous as Agile is, said Lanowitz. Indeed, voke's respondents often referred to it as a mindset. Of course, many software methodologies start as general guidelines, but most evolve into standard practices. Examples include the following:

  • The Capability Maturity Model (CMM) started as a guideline but now has a clear definition. Also, unlike Agile, CMM processes are shepherded by a central group.
  • The Rational Unified Process (RUP) is owned by IBM, which has set standards and manages certifications.

When asked which Agile methods they used, respondents pointed to continuous integration, iterative development and communicating with the line of business. All are good practices, said Lanowitz, but they were being used before Agile came on the scene.

Agile, then, seems to be a hodgepodge of practices, many of which are taken from other methodologies. "Agile is not what a standards body has said," Lanowitz said. "It's not what a software vendor has said. It's not what some entity has said. Agile is a movement … designed to sell services." 

With an elusive methodology like Agile, organizations are challenged in training and certifying in-house staff and are more reliant on consultants, said Lanowitz. "If you want to go be certified on Agile, what if you're going to Certification A and then someone else on my team goes to Certification B?" she said.  "Would both team members learn the same things? Who's to say whether Certification A or B is better?  There's no established criteria to say what one should really know to go forward and be Agile," said Lanowitz.

An Agile coach's view of Agile confusion

As an Agile coach, Lisa Crispin sees Agile confusion in her work often. "People say they wanted to do Agile development, or they may even say they're doing it," she said. "But start going down the list of core practices that are needed for any development project to succeed, and they're not doing it." Some think their project is Agile because they do daily standup meetings or have two-week iterations. "They think that's what it's all about."

More on the Agile method

Are you Agile? Take the Agile acid test

What is Application lifecycle management (ALM)?

Dig into the Agile Manifesto

Crispin doesn't agree with voke's analysis of the Agile Manifesto. In her view, Agile wasn't created by developers for developers, nor is it a movement in which to participate. "It's simply about delivering value to business frequently [and] adapting to changing business needs  at a sustainable pace -- to borrow Elisabeth Hendrickson's 'Agile Acid Test'," she said. "That doesn't specify any particular practices or techniques, but it does imply you have to focus on people, striving for continual improvement while managing technical debt." Crispin is co-author of the books Agile Testing: The Tester Role on an Agile Team and Testing Extreme Programming .

Agile was started as a way to solve problems in software development, said Crispin. She thinks it has succeeded and has become a victim of its own success. "Some of the things you see now, like the branding of different flavors of Agile -- I definitely think that's people trying to make a buck. But that happens with everything, I guess."

Let the Agile buyer beware

Look at best practices and not the Agile label, advised Crispin and Lanowitz.

Don't try to adopt every idea that comes out with Agile tagged to it, Lanowitz said. Really investigate who's saying that a practice is Agile and whether it provides a tangible benefit. Make sure a practice is the best practice for the organization. Delve into possible hidden costs.

Rather than labeling practices as Agile, said Crispin, look at problems and think of ways to reduce the pain, even if only by a little. Always innovate, she advised. She pointed to Google's 20% practices, which encourages its employees to devote 20% of their time to working on any project they want. She's heard people dismiss the success of the 20% rule by saying that Google has more time to invest in innovation. "They're never going to be able to solve problems creatively by always hacking something together to get it in the customer's hands," she said. 

Overall, said Dronzek, business leaders must understand the nature and the context of Agile development. Ensure that each Agile practice serves the business.

What is the bottleneck in your Agile projects?


Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.