ALM tools evolve in face of agile processes
January 15, 2010 —
(Page 6 of 7)
Related Search Term(s): agile, ALM
MKS, meanwhile, has a process-agnostic approach, and it doesn’t focus on attempting to “implement a given methodology for methodology’s sake,” according to John Cull, vice president of customer solutions. Cull said that MKS Integrity offers an agile framework because it is customizable to the project or application at hand, but MKS hasn’t made any fundamental product changes because of agile.
“The impetus isn’t on agile itself,” Cull said. “There’s been a number of other methodologies prior to agile that allow you to get to market fast. Agile is certainly the hottest buzzword right now, but there have been many methodologies that have preceded it.”
Rally, which was formed in 2002, started up with recognition that inventory management software from the 1980s and 1990s were “completely inadequate for operating at a much faster pace,” said Leavitt. So when creating products, the company made sure requirements, test and defects were connected tightly to planning and tracking.
“Operating at this pace changes everything,” he said. “If you talk to vendors of version control software or build environments, you’ll hear this also. I grew up on some teams where building your software took all weekend long, but now you can do several builds a day. Unit tests used to take weeks, but now if it takes more than a few minutes, people will get frustrated.”
Seapine’s Paula Rome said that Seapine makes sure that the products it provides are consistent with the terminology of agile development. She said people need to get comfortable with terminology like "user story" and "sprint," and Seapine has to ensure it is using the same language as the user.
“If you’re not calling something the same thing as your tool, there’s some cognitive dissonance,” Rome said. “Being able to call things with the names you use locally helps speed adoption and reduces some confusion.”
TechExcel’s DevSpec links requirements to a sprint, and as developers do their review at the end of the first sprint, they have a better idea of what that product is going to be, according to Johnstone. Every time a requirement is revised in DevSpec, everyone on a team can see what revisions happen and keep abreast of the current state of the requirement.