To be agile, according to the Concise Oxford Dictionary, is to be quick-moving, nimble and active. When it comes to software development, agile methodologies are adaptive rather than predictive and are people-oriented rather than process-oriented, according to Martin Fowler.
Fowler, the chief scientist at Chicago’s ThoughtWorks and renowned agile development guru, said that agile methodologies have evolved as a response to the regularly used techniques.
“Most projects we’ve seen over the years have been run in a very chaotic way or a very rigorous way,” he said. “Clearly the chaotic approach is broken, and the rigorous approach often doesn’t work well either, so people are looking for a middle ground, and agile is that. It requires more discipline and control than a chaotic project, but without the overhead associated with rigorous methodologies. That’s what’s really caught the imagination and attention of so many developers.”
Fowler explained that the necessity of a middle ground was obvious for members of the development community. It is the developers who suffer most when chaotic schedules get out of control and force the coders to put in large amounts of overtime, he said, noting that they’re the ones who are blamed for being late.
On the rigorous side, developers often spend a lot of time doing tasks that don’t add value to the project, Fowler said.
“Developers want to be doing useful stuff, and it’s frustrating to spend a day every week updating a document that you know nobody will ever read, let alone review it. This is irritating to developers who simply want to put good quality stuff out the door,” Fowler said. “Developers feel the pain if they put out crappy code.”
change to be welcomed
Part of the attraction of agile methodologies is that change can be implemented throughout the process and not simply as an afterthought or a fix up, Fowler said. He pointed out that software is supposed to be soft, so not only are requirements changeable, they ought to be changeable.
“Business needs change and one of the biggest problems with the rigorous approach is that it doesn’t recognize the need to respond to change effectively. Change is something that should be welcomed rather than resisted,” he said.
Fowler noted that a huge problem in software development is that despite the fact that software is intertwined with business processes, it is often unable to respond as well as it could due to various factors, including the design quality of the software and the process. It’s very easy to have the worst of both worlds, Fowler said.
the many flavours of agile
The agile family of methodologies includes Extreme Programming (XP), Scrum, Cockburn’s Crystal Family, Highsmith’s Adaptive Software Development, Coad’s Feature Driven Development and Dynamic System Development Method (DSDM). Unlike the traditional one-size-fits-all methodologies, the agile group of methodologies are, well, agile.
Rather than conforming a developing style to a methodology, agile practices are based on the way that people actually develop software.
“Part of the agile approach is to have just enough control to do what we need to do,” he said.
In many cases, agile practices are defined enough to be incorporated right into development tools including unit testing frameworks, continuous integration tools, and refactoring development environments.
“Each methodology has its own flavour,” Fowler said. “XP is very disciplined, which always surprises people. It requires a lot from those who want to use it, but it also gives a lot back. Crystal’s more tolerant and is aimed much more for a wider range of people. Scrum is focused on project management practices, but brings in XP ideas on the development side. Part of the point is that different methods appeal to different people and different projects.”
Like all methodologies, the practices under the agile umbrella present problems with no easy fix for developers. However, in Fowler’s opinion, the issues that plague agile programming are found in all methodologies.
“The biggest problem I see is the need to understand what technology’s working and what isn’t. I think developers need to get a better handle on that,” he said.
A second issue that frequently pops up in agile programming is handling the collaboration between the technology side and the enterprise side. Fowler identified the difficulty in persuading business people to get involved in the development process, which he called a perennial software problem.
“The agile world isn’t worse off – everyone has that difficulty – it’s just that in an agile environment, it’s more obvious.”
port and programming
Where agile methodologies are heading is anyone’s guess, but Fowler is well aware of the fact that the practices are still in the infancy stage.
“I liken agile today to where objects were in the early 1990s. You see pockets of interest in nearly every big company, but like any new idea it takes time to spread around. There are adoption curves, and we are still in the early stages,” he said.
Fowler projected that it will take 10 to 15 years for agile methodologies to be widely accepted and practiced. He told a story about the author of a book on Scrum presenting him with a bottle of Port as a thank-you gift for writing the book’s introduction.
“I explained to him that you can’t touch a vintage bottle of Port for 15 years. I told him that we’ll get together in 15 years to open the Port, and by that time we’ll know where agile has gone.”
