Tool choices are continuing to expand as more organizations adopt agile practices and extend them out across the enterprise. There are comprehensive tool suites and point solutions, older products that have been adapted to agile, and newer products that are purely agile. There are also free products, enterprise solutions and choices in between. Navigating the landscape can be confusing, which can lead to mistakes, not the least of which is buying a product based on solely on its features.
The agile world is all about speed, adaptation and constant improvement, which requires organizations to understand their workflows in considerable detail. A common mistake made early in the adoption phase is hoping a tool will prescribe the “right” way of working; however, adapting workflows to tools is counter to the tenets of agile. Instead, tools must adapt to workflows.
Tools are growing up and out
Increasingly, tools are being extended to support roles outside the development team. Earlier this year, VersionOne and Rally Software announced “Ultimate” and “Unlimited” editions of their agile application life-cycle management (ALM) platforms, respectively, that extend the capabilities of their Enterprise products beyond multiple development teams to other stakeholder roles, some of which are non-technical. Key additions to both new products are idea management capabilities that capture and track the results of customer ideas and feature requests.
Meanwhile, CollabNet, another agile ALM platform provider, is now targeting workgroups in addition to enterprises with its recent acquisition of cloud hosting provider Codesion. Its TeamForge ALM platform and ScrumWorks agile project management tool are now available as Software-as-a-Service solutions.
Electric Cloud has made an effort to accommodate the way customers work. Toward that end, its Electric Commander automated build-test-deploy solution provides a plug-in architecture so users can extend the product and use their tools of choice. It can also be adapted to provide the look and feel of existing systems to minimize learning curves.
Generally speaking, greater emphasis is being place on deployment and operations as these are common obstacles to agile release cycles, especially in organizations that have distributed development teams. XebiaLabs is wholly focused on deployment automation, and the company is not alone in pointing out that continuous integration and continuous deployment are both necessary for successful agile implementations.
Because no two agile teams or organizations are alike, it is important for agile tools to adapt to customer requirements. Levels of sophistication and degrees of agile adoption can vary greatly from one group or organization to another. A minority of companies are purely agile or purely waterfall; most are some sort of hybrid. However, “hybrid” can mean a combination of waterfall and agile practices, a combination of different agile practices, or some sort of derivative that is or is not driven by best practices.
“A key aspect of ALM adoption is that no two companies are exactly alike,” said Todd Olsen, product line manager at Rally Software. “If products can’t adapt [to suit customer requirements], they’re not agile.”
Rally provides an app framework that allows customers to extend apps like project management tools so they can better meet the needs of specific business roles and industries.
ThoughtWorks Studios deems its agile ALM suite “Adaptive ALM” because it is designed to adapt to the way teams and organizations work. The suite consists of Mingle, an agile project management module; Twist, a test management module; and Go, a relatively new agile release management module that enables continuous delivery.
Chad Wathington, VP of product development at ThoughtWorks Studios, distinguished continuous delivery from continuous deployment. He said continuous deployment allows users to press a button, but it doesn’t enable them to prioritize and think. Further, some organizations are not ready for continuous deployment, but they still need continuous release management to get feedback and to ensure they have working software.
Continuous delivery combines automation and engineering rigor with release management best practices, so release schedules can be driven by business requirements rather than compliance and resource constraints.
Seapine Software, another ALM solution provider, added agile capabilities to its TestTrack 2010.1 release. The solution includes built-in burn-down charts, task boards and ranking, which customers previously had to set up themselves. Using TestTrack, organizations can run agile and traditional software development projects in parallel using the same tool.
Aldon, an additional ALM solution provider, recently added a number of templates to its Community Manager Integrated Service desk for IT Services Management solution. Soon, the company will release a free, community-built agile project management tool called Aldon Agile Manager that will allow users to create and manage a backlog of stories.
Does one size fit all?
Solution providers are divided about whether the various agile methodologies are better supported by a single agnostic tool or tools designed specifically for Scrum or Kanban, for example.
Rally acquired AgileZen earlier this year, which is a project collaboration tool that provides a Web-based Kanban board for visualizing and tracking work as it flows through various stages of a process.
“With Scrum, you care about time boxes, iterations and releases,” said Olsen. “You have iterations and then assign stories and work through iterations. You also need reports like burn-down charts. Kanban is about visualizing work. Instead of time limits, you have work in progress limits, and instead of time boxes, you need cycle reports.”
He also acknowledged that there are common traits among the various flavors of agile, like requirements planning and decomposing larger items into smaller items.
Robert Holler, president and CEO of VersionOne, said Scrum and Extreme Programming (XP) camps have been adopting each others’ practices while Kanban, Scrum and XP all involve retrospectives and iteration planning.
“Eighty percent [of agile] has normalized,” he said. “The nuances are in the terminology, like ‘story’ versus ‘feature’ or ‘backlog item.’ ”
Another nuance is data presentation. VersionOne adapts by asking users which methodology they are using, and then superimposing a customizable template such as a list view for Scrum or a board view for Kanban.
Some, including Dan Magid, chief product strategist at Aldon, said that because there are so many commonalities among the different flavors of agile, specific solutions are unnecessary, particularly if the solutions can adapt to the methodologies of choice and provide the right perspective.
“Generally, you need the ability to track work, set boundaries and define what you’re doing over time,” said ThoughtWorks’ Wathington.
According to tool providers, most customers claiming to be agile have adopted Scrum. Some said Kanban often follows for more effective project management.
“Kanban is coming on strong,” said Victor Szalvay, CTO of CollabNet’s Scrum business unit. “Scrum and XP are more traditional agile flavors that are iteration-centric, and so the tools are iteration-focused.
“Kanban and Lean are [designed for] groups that [are not involved] in iterative development. Typical agile reports like burn-down charts are not sufficient to reach an end goal; they just provide a to-do list, which piles up. You also need metrics because you don’t want work in progress for too long. You need new tools and processes.”
How tool requirements evolve
Organizations moving to agile have to alter their approach to requirements since large planning documents are at odds with fast, iterative release cycles. According to Giora Morein, founder and principal consultant of BigVisible, requirements themselves are changing.
“Traditional requirements are attribute-driven,” he said. “[In the agile world], requirements are user-driven.”
The move to agile also requires a cultural overhaul, which is an obstacle to its adoption. Individuals have to adapt to working quickly on smaller projects, while teams and cross-functional groups must learn to work collaboratively.
“Organizations have typically created big things, so agile is a mismatch,” said Rally’s Olsen. “Because you’re not driving a huge plan, you need feedback and indicators about outcomes.”
Commonly, agile adoption starts with developers, which impacts other roles upstream and downstream such as requirements planning, testing and deployment.
“We’re seeing a clash of cultures,” said Andrew Phillips, VP of product development at XebiaLabs. “Operations still lags behind, [so] people are looking for a way to convince operations to deliver in an agile way and adapt to the workflow.”
The best way to adopt agile is to learn best practices rather than simply adopting tools, which is one reason many tool providers now offer professional services, training and other resources. Customers want and need assistance.
Professional service organizations usually custom-tailor recommendations to customers’ unique requirements, while classes tend to approach best practices more broadly. As a result, all of what is taught in class may not be applicable to all organizations.
“If your company is regulated, sticky notes on a white board won’t cut it, so [you need to figure out] how to translate [what you learn] into your own world,” said Jeff Amfahr, director of product management at Seapine.
As agile expands within an organization, security and other enterprise IT requirements become mandatory, which is why platform vendors commonly offer tiered solutions.
Tool suites vs. best-of-breed solutions
Solution providers are also divided about whether tool suites or “best-of-breed” point solutions are the better choice. On one hand, tool suite modules are usually deeply integrated to improve workflow efficiency, provide data visibility across solutions, and enable centralized reporting and analytics, among other things. The drawbacks to tool suites can be vendor lock-in and inconsistent product breadth and depth.
“[The benefit of a tool suite] is richness—seeing data in context. The problem is no one has done tool suites very well,” said ThoughtWorks’ Wathington. “The problem with best-of-breed tools is cobbling them together. You can do it, but it takes time. It’s hard to do, it’s hard to upgrade, [and] it has a high maintenance load.”
Amfahr and CollabNet’s Szalvay also stressed the importance of data visibility, because agile methodologies place a strong emphasis on retrospectives and continuous improvement. As a result, cross-team, cross-functional visibility is critical in agile organizations.
On the flip side, there is something to be said about best-of-breed products when they are truly best-in-class products. These products often become the tools of choice that may influence other tool purchasing decisions. The major problem with adopting best-of-breed products is usually integration.
“There is a greater shift toward best-of-breed [products] because of the fundamental tenets of agile. Agile is about choice,” said VersionOne’s Holler.
Of those interviewed for this article, four advocated best-of-breed products, three advocated tool suites, and Rally’s Olsen refused to advocate one over the other.
Regardless, integration is the operative word.
Aldon’s Magid said that in an agile environment, integration is essential to communicate status. Olsen said integration provides customers with options.
In large, complex organizations, it is common to have disparate teams and technology, so best-of-breed tools are the way to go, according to Usman Muzaffar, VP of product management at Electric Cloud. The trick is getting the full benefit of the tools. For homogeneous projects, he said a tool suite is preferable; however, the platform should be a platform for unification as opposed to a platform for standardization.
What’s next
Agile adoption is expected to grow within and among organizations, as it has become a competitive differentiator in some industries. In regulated industries, some teams are becoming partially agile to the extent they can, given their constraints. Either way, agile is anticipated to grow upward from single teams to multiple teams to entire enterprises, and outward to more roles, including business functions.
Olsen anticipates changes in requirements planning, while Szalvay said there might be some redesign around empirical project management. BigVisible’s Morein said the most modular and adaptive tools will likely become the most successful.
In the meantime, solution providers advise their peers to stop approaching agile as purists, since few organizations are purely agile. After all, tools should adapt to organizations, not the other way around.
