The agile manifesto was forged in February 2001 when a group of developers convened in Utah to find an alternative to documentation-driven, “heavyweight” software development practices, such as the then-gold-standard waterfall method.
Although actual agile practices predated the Utah meeting, that gathering served as a watershed event that helped propel the concept. Fast-forward a decade, and agile software development is becoming more commonplace, with software houses adopting agile methodologies like Scrum and XP (Extreme Programming). Despite potential pitfalls, experts in the agile space agree that implementation of agile practices has benefited software development overall.
“I’d say we transformed the industry,” says Ward Cunningham, a signatory to the manifesto who worked for Tektronix at the time. Discussion about the failure of computer programming and the programming crisis has died down as a result of agile, he says: “I just don’t hear people talking about that anymore.”
The Agile Manifesto has more than met its goals, says Scott Ambler, chief methodologist for agile and Lean at IBM Rational.
“It’s had a pretty significant effect on the industry,” Ambler said. “You’d have a hard time these days trying to find people who don’t want to be agile. [And] the expectations for success for agile and iterative seems to be measurably higher” than with traditional development.
But Kent Beck, who also signed the manifesto and is the founder of XP, is less committal about the benefits of agile nearly 10 years after the manifesto: “I don’t have a sound-bite answer for you on that.”
Agile has “contributed to people thinking more carefully about how they develop software,” Beck says. However, not everyone is on board with agile, he notes. “There’s still a tendency for some people to look for a list of commandments” to use for a project, which is not what agile is about, Beck says.
Solid programming skills are necessary for agile development, Cunningham stressed. “There’s a lot of people who get into this field who actually find programming tedious and don’t want to do it,” Cunningham says. “If you enjoy doing it and want to do it well, that helps a lot.”
Organizational obstacles can arise in implementing the agile philosophy as well. “[Agile] works well as far as looking to deliver [software] more frequently and to think about things in smaller chunks instead of the whole project,” says Skip Angel, an agile coach with BigVisible Solutions. “What I think is a challenge for organizations is that they don’t [have their] organization set up in a way that could provide for quicker delivery.”
Projects can get bogged down in time-consuming processes, Angel adds, and developers need to use continuous integration to avoid bottlenecks.
Agile is no silver bullet, notes Ian McLeod, executive vice president of SmartBear Software, which makes application lifecycle management tools. “You still have to do it well…. You can do agile poorly,” he says.
Beck recalls using agile in developing the successful JUnit Java unit testing tool in 1997. The team used short iterations, lots of unit testing, and close communications with customers.
“It helps us develop quicker and keep better track of what it is we need to do,” says Wade Weston, CEO of AttainResponse, which develops unified communications systems. AttainResponse does weekly development sprints. “We do short sprints, and we are highly focused on the items that we need to do that week,” Weston says.
Getting everyone on board still can be an issue, however. “One of my guys keeps telling me that he would like to have more specified requirements. I keep telling him we’re going faster because we don’t have specified requirements,” Weston says. A hardcore requirements document is a “waste of time,” he adds.
Sometimes, developers can call practices “agile” when they are really not, says Damon Poole, CTO at AccuRev, which offers project management software for agile projects. Developers might not build fully developed items, or “stories,” after two-week iterations, he says. “If you’re really doing agile, then the user stories are ready to actually ship after that two weeks,” Poole says.
“What distinguishes XP is that it is a system instead of a solution,” says Cunningham, a contributor to XP’s development. “It’s a systematic approach to programming.”
Scrum is focused on how to manage and deliver the work while XP hones in on how to do the work, Angel says.
Poole notes, “Scrum and XP are definitely two of the main methodologies out there and often you’ll see Scrum teams adopt XP and XP teams adopt Scrum.”
Another methodology is Kanban, which was derived from manufacturing processes and the concept of Lean software development, Poole says. Kanban has fewer constraints and focuses on the flow of value back to a customer, he notes. Lean focuses on organizational efficiency, optimizing values, reducing waste, and trying to make sure of good process flow, Angel adds.
RUP (Rational Unified Process) also is mentioned as a method of agile, although whether it actually is could be debated, McLeod says. RUP features a lot of documentation, which goes against the grain of agile, he explains. RUP can be an agile methodology, Ambler says: “The thing with RUP is that it’s a process framework. It completely depends on how you institute it.”
Ambler also cites DSDM — Dynamic Systems Development Method — as falling in the agile domain. “DSDM is sort of like RAD [rapid application development] with a little bit of extra process thrown in.” RAD differs from agile in that it focused on iterative development but not on increased collaboration, he notes.
McLeod sees agile methodologies as being like those using iterative development. “There’s not a ton of difference,” he says.
The term “agile,” Cunnigham says, was a word picked out at the Utah meeting. “People were referring to it as lightweight methods,” he recalls. But some thought the word “lightweight” carried with it the negative connotation of being superficial, he says.