Practitioners of Agile software development methodologies are experiencing improvements in both process and product.
But like most things in life, there is a yin and yang. Challenges for Agile developers include communications and documentation and adapting Agile for distributed teams and large-scale enterprise projects.
However, enthusiasts are forging ahead. "First, a team needs to recognize that Agile is good. The opportunity is there," said Scott Ambler, practice leader for Agile development at IBM.
Results from SearchSoftwareQuality.com's 2008 Agile Trends survey found that 67% of Agile practitioners have seen process improvements. Topping the list of improvements, according to survey respondents, was faster time to market (66%), followed by increased productivity (62%).
Nari Kannan, CEO of Ajira Technologies Inc., a Pleasanton, Calif., developer of service process management solutions, sums it up simply: "We're able to get stuff done."
Getting a deliverable into the hands of customers earlier is helping to make a better product, Kannan said.
"The main thing we've learned is, when you begin, you think certain features are important to customers, but those often are not that important, so the definition of the product itself has evolved, which is the biggest improvement," Kannan said. "There's no way we could've guessed all the [important] features unless we deployed [it]. Requirements gathering is a farce unless you roll something out and start using it."
Mike Turner, president of Northstar Analytics and author of Microsoft Solutions Framework Essentials: Building Success Technology Solutions (Microsoft Press, 2006), agreed, saying that project sponsors are the biggest benefactors of earlier deliverables.
"The sponsor sees something real sooner, because even when you write the spec the sponsor doesn't fully understand what they want until they see it. The Agile benefit is that it gives them something real," he said.
And that "something real" has fewer defects, according to 45% of survey respondents, and costs less to develop, according to 34% of respondents.
"It's simply the physics of testing multiple times a build—we just catch that much more," Kannan said. "If you wait until the end [to test] you waste so much time doing design and development that you don't have much time for testing and you rely on the users to figure it out, which is a really bad way to do it. Every time we do a build we go through a whole bunch of testing, so the probability of catching defects is that much more."
Steve Whatmore, a Java architect at Toronto-based LYNXDev Inc., which provides business solutions to the financial services industry, said his company also experienced faster time to market as well as fewer defects, with the end result being a more robust system.
"The benefits [have] been not only time to market with our solution—which is substantially faster than what our clients expected with the size of the team that we assigned to the project—but also the robustness of the system as a whole," Whatmore said. "Due to the fact that the base architecture has essentially been tested and re-tested from day one of our development cycle, we have been able to flush out a lot of the defects that would otherwise be found very late in the game with a waterfall approach."
In addition to fewer errors, Danny Allen, director of security research at IBM Rational, said Agile processes can also help improve security. "Applications developed using an Agile process end up being more secure," he said. "You're not only doing functional testing early and often, but you're also doing the automated security testing. You're catching mistakes early."
Challenges using Agile processes
While development organizations are reaping benefits with Agile, practitioners acknowledge there are some challenges to this style of development. Respondents to the SearchSoftwareQuality.com survey cited communication as the top Agile challenge (52%), followed by documentation (48%). Resistance to change and tool integration were also cited as challenges (both by 24% of respondents).
Communication, no matter what methodology developers use, "is just a tough thing, always," said IBM's Ambler. And, he added, "popular methods like Scrum and XP don't explicitly address documentation, which is what Agile modeling is all about. You can't ship without adequate documentation."
Kannan agreed that documentation is a challenge. "The reality is, no matter how much you try, documentation is never up to date." He said Ajira uses "express documentation," which is two to three pages with requirements in bullet points. The design document is about the same length, with screenshots and diagrams. "It's a trade-off between spending three months doing documentation and writing code, only to find out a lot of that is not needed."
In contrast with the survey results, though, Kannan said communication is enhanced with Agile. "It's not a problem because when you're doing this many builds communication increases," particularly with users/customers providing feedback throughout the cycle. "Communication is the best benefit of Agile."
For LYNXDev's Whatmore, managing the modifications with minimal documentation is a challenge.
"The single biggest hurdle that we found is managing the level and number of modifications to the system, both in terms of functionality and UI design," he said. "Since we did not have a document which fully described the system, the number of changes that we had to manage once the client reviewed the application became at times burdensome, and the tool that we managed for defects was not exactly appropriate for managing these types of modifications. Thus we found that we maintained some of the change requests in emails, in spreadsheets, on paper, etc."
He continued, "If I were to go back, I would ensure that we have a single system of control and management of these so that we have a single point to refer to when questions arose. As the ALM [application lifecycle management] space continues to flush out in terms of breadth and depth of their solutions, I fully expect this problem to get covered.
Distributed Agile teams can be difficult
Agile development teams that are distributed also face challenges. Among respondents to the survey, 48% said their Agile teams were distributed.
"Distributed development is tough, period," Ambler said, adding that distributed Agile teams have to "be smart" about communications. "You have to address that issue with better processes and better tools."
Ambler said IBM does distributed Agile development, but acknowledges "it's harder." At IBM, he said, distributed Agile projects have subteams that handle one or more subsystems or components.
"You have significantly less overhead for communications because in effect each team can act as a reasonably co-located team by itself," Ambler said. "A common mistake [of distributed Agile] is organizing around job function. You have lot of communication overhead doing handoffs, and it increases risk."
Northstar Analytics' Turner agrees that "it helps if subteams are co-located." However, he said, a benefit of Agile is the ability to have timely customer feedback, which can be a challenge for distributed teams with time zone differences.
Scaling Agile for the enterprise is another hurdle, Ambler said. "The Agile community has gotten real good at developing high-quality solo projects, but not real good at the enterprise level. This is the next major challenge," he said.
Despite the challenges, Ambler recommends organizations give Agile a try. "When you look at the results people are getting, the vast majority are positive or at least neutral; very few are having negative results. Experimenting with Agile is an incredibly low-risk decision to make. There is a big upside and the downside is small."
Editor in Chief Michelle Davidson contributed to this report.