Despite all of agile's success stories, the development methodology has made many enemies.
More than half of development organizations worldwide are using or plan to adopt agile this year, according to various surveys, including June Capgemini-Sogeti 2010-2011 World Quality Report of 30,000 software managers. They praised agile for improving time to market, application quality, resource utilization and cost savings.
Requires Free Membership to View
|
 |
||||||||||||||||
|
|||||||||||||||||
So, why all the hate? This article explores agile from both sides…now.
A quick Google search of "agile" combined with any number of negative keywords will quickly yield hundreds of user groups, forums and Websites dedicated to halting further agile integration into software organizations. Their most common reason for hating agile is its communication requirement, which agile-haters say just wastes time and calls for meetings, as one writes, "every three minutes to discuss a change or alter a requirement?"
"Agile takes proven development techniques and discards them in favor of unproven ones," writes an anonymous software pro in a CodeRanch post,Agile Pair-programming sucks. "We've all been told since kindergarten, 'sharing and playing nicely are key,' but that's pre-grade school and this is real life." This CodeRanch poster said agile has held up production in his software organization with too many meetings. "Our team meets almost every three to three and a half hours, most of the time the discussion topics have nothing to do with my work, but I'm forced to be there and participate because 'we're an agile team, and there's no 'I' in 'team'.
Pair programming, an agile technique that puts two programmers working on the same workstation, has enemies in blogosphere. It appears that familiarity breeds contempt, as paired programmers are more often odd couples than not. Many write that a great match is rare.
Software methodology traditionalists form a solid block of agile haters. These are the tenured developers and engineers that have become accustomed to building one iteration (the project), testing that project after development has been completed and then releasing. "[Everyone that falls into this category] is very capable of transitioning to agile, but their organizations are driven by requirements and they depend on a recognizable, steady and predictable process," said Scott Ambler, IBM's chief methodology officer.
Proactive agile managers can sway haters
Obviously, agile has failed to work for the agile dissidents. That's a failure in management, say
the agile enthusiasts interviewed for this story. First of all, forcing agile on a team isn't the
best way to go. If your team isn't overjoyed to collaborate and able to work in a fast-paced
development project, chances are you will run into problems. There are ways to identify failure
before even starting an agile project. Simply get feedback from your workers, managers and other
staff.
Managers can't turn a blind eye to problems in agile development, hoping that they'll work themselves out. When your team is not doing agile well, it will quickly become obvious. Just look at the demeanor of your group: If they seem less than thrilled, overly-tired, overworked or non-compliant, then there is either a complication in the process or they are being managed poorly. At this point, managers can actually use agile to adapt the process, modifying the non-productive agile process in place by accepting other models and abbreviate the parts that aren't working. "Agile will persevere in almost any situation if fueled," said Ambler.
Agile-only isn't the only way
Agile is about flexibility, but it's not infallible. When the process line is followed to every
exact detail, there is still room for error, said Elizabeth Hendrickson, founder of Quality Tree
Consulting. Hybrid models should really ease off some of the steam the two different methodology
camps have been building, at least, that is the hope.
Even agile enthusiasts believe organizations should use whichever development method works, agile or not. "Waterfall has worked nicely for many years, and in many cases it continues to," says Bob "B.J." Reff. "Whatever route works and leads to successful software is the path teams should take." You may or may not have heard, but there are several organizations implementing a combination of waterfall and agile called 'the hybrid model.' Using the hybrid model has allowed these teams to function with flexibility while maintaining some rigor in the process stream. It really sounds like a nice fit.
 |
||||
|
|
|||
|
||||
Mike Croucher, a software engineer, brought agile development to British Airway's BA.com project quickly and with very few complaints; but he didn't stick to agile when it wasn't a good fit. "Right now, I'd say we are using a hybrid model of agile/waterfall and some other development methods in between. What has worked nicely for us is the flexibility agile provides, though we still have to adhere to some strict waterfall guidelines, agile allows some playroom to get things done quickly while still building within preset parameters."
While Croucher's team was able to go agile many places, he says the requirements that needed to be met is what kept BA.com from becoming fully-agile. Requirements gathering, elicitation and delivery are just some of the heavily-debated issues between the agile group and the waterfall camp. While waterfall development places the gathering of requirements to headline the project before development starts, agile allows requirements to be altered, changed or dropped throughout the software development lifecycle (SDLC).
Using tools to placate the meeting haters
Faced with too many meetings and a widely-distributed team, ISV Social Text created and uses
software to automate collaboration and communication, automating things like tracking the
completion of testing, documenting bug discoveries and their solutions, and sending IMs and text
messages to the group so that everyone on the team to know the status of the work – without a
meeting. Matt Heusser, lead tester at Social Text, reports that the company develops sotware
full-fledged agile and agile only.
Agile success = no-haters policy?
Having agile haters on an agile development team isn't going to work, period. For agile or almost
any methodology to work, it has to be supported by the team on a group and individual level, said
DamonPoole, founder and CTO of ISV AccuRev. In true agile projects, a chain is only as strong as
its weakest link." "If everyone is not onboard for completing a project on time and within budget
than maybe it is time to look into something else," said Poole.
Join the conversationComment
Share
Comments
Results
Contribute to the conversation