Beyond 3x5 index cards, Agile software developers utilize a variety of tools for their trade. Topping the "essential"...
list, according to SearchSoftwareQuality.com's 2008 Agile Trends survey are requirements management (56%), followed by bug tracking (51%), and project management and unit testing tools (both at 45%). Also cited were tools for functional testing, build, collaboration, configuration management, and documentation.
"Obviously requirements management is important. You'll find the more regulated the environment, the greater need for requirements management," said Scott Ambler, practice leader for Agile development at IBM. "It's the nature of software development these days."
Requirements gathering is "one bugaboo that the Agile community doesn't like talking about," Ambler continued. "They need to overcome this, and index cards are not going to cut it." Still, he acknowledged, "you do want to streamline requirements management and documentation, which is what we focus on in the Agile modeling method."
For Nari Kannan, CEO of Ajira Technologies Inc., a Pleasanton, Calif., developer of service process management solutions, bug tracking and test automation tools are essential for the company's agile developers. In terms of test automation, he said, "you're doing builds every week, so you don't want to type in every form yourself. We keep standardizing tests, and a lot of new builds go through test automation tools."
Bug tracking tools also save time for Ajira, he said. "Bug tracking is essential because with smaller cycles, you don't want to be having meetings about bugs," he said.
Steve Whatmore, a Java architect at Toronto-based LYNXDev Inc., which provides business solutions to the financial services industry, agreed a defect tracking system is critical for Agile development, and that ideally it should integrate with the integrated development environment (IDE). LYNXDev uses Eclipse with Mylyn, a task management subsystem, and integrates with the CodeBeamer collaboration platform.
"This allows a developer to be notified directly in the IDE that they have been assigned a bug, and it allows them to work on that bug, check in the code related to the fix for this defect and close the defect, all directly from the IDE," Whatmore said.
"Although we are not using a 'test-first' methodology, we do have a full suite of regression tests for our applications. This regression/automated test is run along with our twice-daily builds and provides notification of the results to the development team," he said. "All failures are dealt with immediately, and we have found over time that due to this approach the mentality of the developers has changed to ensure that not only does the build process work well, but we have very few unit testing issues with the application."
Continuous integration/build tools are also on Whatmore's list. "This is paramount to the success of an Agile type of methodology, where you always have at any point in time a working system. We currently execute a twice-daily build for one of the applications that we are building. This ensures that not only do we always have a working application, but it provides that application to the QA team [via an automated push to the QA environment]."
In addition, Whatmore said a source code control (SCC) system "is an absolute must. This system should be flexible enough to support the various requirements, such as multiple development streams, tagging, branching, etc., but should also not constrain the development process to work in the SCC's paradigm."
Regular meetings also an important tool
Whatmore also considers a daily development meeting a critical tool "to ensure that everyone on the team is up to date with the progress/status of the development team." He said his team holds 15-minute daily development meetings, covering the progress of each person's tasks, problems that a developer may be facing, and any changes/modifications to the application architecture or other functions that could impact the rest of team.
"We found that these meetings were invaluable in maintaining communication," he said.
Communication is what it all comes down to, no matter which tools an Agile team employs, according to Mike Turner, president of Northstar Analytics and author of Microsoft Solutions Framework Essentials: Building Success Technology Solutions (Microsoft Press, 2006). And the tools of choice have to fit the needs of the team, he said.
"It's obvious you've got to have a development environment, you've got to manage code, and you've got to manage communication, whether that's with instant messaging or a SharePoint collaboration," Turner said.
The tools also depend on the situation, if the team is co-located or not, and the circumstances of the people supporting the team, Turner continued. "You don't need much if you're in a room together, but it's wholly dependent on the extended team and what they need."
Sometimes the "tools" may even get a little creative, like Whatmore's "Build Pooch," designed to bring home the point that a failure in the integration/build of the application could bring the whole team to a halt. Thus, he said, "If you 'pooch' the build, you get the Build Pooch placed on your desk until you fix the problem."
Since no one wants the stuffed dog with the flashing bright light attached to its collar on his desk, Whatmore said, "breaking the build has become very rare indeed."