Prediction #4: The single vendor ALM stack becomes extinct in organizations with more than two developers

Development managers at large organizations with monolithic application lifecycle management (ALM) stacks once had it good. ALM components were well integrated, played nicely with one another, and when they didn’t, there was someone to call. But lightweight issue trackers started to move into the organization, popularized by the need for developer-centric collaboration facilities. At a cheap or free price point, these were often deployed without the corporate IT department’s knowledge or approval.

Then the Agile project tracking tools moved in, and with the excitement around Agile, team and product leads pushed them through without consideration of standardizing across the organization. In the meantime, quality management tools like HP Quality Center remained so entrenched in their domain and so valued by management that they did not budge when the newer tools moved in. As a result, the large organization’s tool stack resembles an ALM history museum, ranging from the old in-house defect tracker that’s still running, to the freshly-installed Kanban tools intended to address disillusionment with Scrum. No two ALM stacks look alike.

The success of open-source ALM components has driven diversity into even the smallest software shops, and the new norm for the ALM tool stack is heterogeneity. While this brings the benefits of choosing your best-of-breed solution, it also means dealing with new complexity in terms of navigating the landscape of tools and options when considering how to modernize your ALM stack to support Agile. This post is a brief guide to helping you navigate that complexity by focusing on the options you have for modernizing the most core part of your ALM stack: the issue, project and change management layers.

Tool support on this front boils down to capturing different stages and granularity levels of software development tasks, much as Salesforce has succeeded at capturing and tracking tasks across the various stages and stakeholders in the sales process. At the base level, we have tasks related to the code itself, consisting of defects, feature requests and tests. This is the realm of the issue trackers. At the next level, tools abstract over development-specific items to capture tasks relevant to management and planning, such as user stories and requirements. The new breed of Agile tools is popular here. Then, there are the enterprise ALM tools that can capture and track across products, releases and portfolios of projects.

In 2010, some ALM surveys included over 100 different issue trackers and change management tools to choose from. This enormous diversity has driven innovation, as vendors strive to differentiate their offerings in order to win over customers and to add value over the steadily rising bar of commoditization coming from open source.

Last year we saw the price points of basic issue tracker support for small teams drop to dumping levels in an effort by vendors to displace their competition. In terms of feature sets, issue trackers are starting to look very much alike and, as with cars, their most visible differences are colour combinations and dashboard designs. In 2011, the issue tracker will be well on its way to becoming a commodity. The key thing to look for is that your issue tracker supports developer collaboration along with good ease-of-use for comments and updates, and that it is integrated with the workflow of the developer.

The issue tracker also needs to be integrated with your planning loop. If you are a small team or organization, that may be as simple as managing a field with your release or iteration or setting up a wiki-based Kanban board with hyperlinks to the issues. But once you start scaling beyond a small team, tool-based planning features are required to scale your planning process across teams and geographical locations. The next layer in the ALM stack is the project planning and tracking tool. With Agile starting its move into the enterprise, competition between vendors in this area is becoming fierce.

Numerous ISVs are clamouring to lead the trends, implementing the latest Agile and Lean fashions as quickly as the books and blogs defining them are published. A few vendors, including Rally, VersionOne and ThoughtWorks Studios, have differentiated themselves by combining Agile tools with thought leadership and training. This helps organizations adopt the cultural aspects of Agile while bringing the vendor’s tool-based support for Agile practices along for the ride. These vendors have been key to many of the Agile rollouts to date, and have driven much of the management level adoption of Agile and Lean methodologies.

New players have appeared in this space, introduce a wide range of expertise, and provide a spectrum of tools from simple layering of functionality on top of the issue tracker to full-blown enterprise ALM solutions. Picking the best solution here often depends on the size of your development organizations, how opinionated you want your Agile tool to be in terms of enforcing a particular Agile workflow, and selecting a tool that integrates with the rest of your diverse ALM stack. The latter often proves to be the greatest challenge. If your development process needs to plug into a project, product and portfolio management loop, and also requires a connection to quality and requirements management, you need to reach one more level up the stack into the realm of enterprise ALM.

Just as lighter-weight tools offer increasing benefit the closer you get to the developer’s desktop, the visibility, predictability and planning needs of a large organization with thousands of developers are addressed by these more heavyweight enterprise ALM tools. When you have a team of five developers, requirements management can often be handled by a shared understanding of the customer and the problem space. When you have a team of five thousand developers, many of whom are remote or outsourced, it’s almost impossible to be effective at managing delivery without this level of tool support. For large organizations the crux of the problem tends to be that the open source, lightweight issue trackers and Agile tools they have deployed do not provide this level of ALM support. This is the reason why enterprise ALM tools such as IBM Rational Team Concert (RTC), Microsoft Team Foundation Server, and more recently HP ALM, are providing support for the entire change management cycle. The trouble with getting the full benefits of those tools is, once again, the heterogeneity in your stack.

At each of these levels of the ALM stack, the key is ensuring that in the presence of heterogeneity, the code being produced and deployed from the development level is connected to the goals and product strategy determined at the planning and management levels.

Failing to automate the connectivity between these layers means that the organization falls back to less reliable communication formats such as excessively long email threads, more tedious meetings, and the wearing new channels into the office carpets as you walk back and forth between cubicles. What’s needed to bring sanity to ALM stacks is a “task federation” layer. At small organizations, the top-most system of record for the planning loop becomes the issue tracker. At medium-sized organizations it’s the Agile project tracking tool. Issue tracking facilities in Agile planning tools will increasingly displace the standalone tracker, or in the cases where the issue tracker is sticky or provides additional value, a task federation layer will provide linking between the tracker of choice and the Agile planning tool. At large organizations, task federation will become a critical part of the planning loop.

For example, if you are deploying IBM RTC as your ALM tool you probably have HP Quality Center deployed already and do not want to lose its benefits for quality management. Task federation provides you with the bi-directional synchronization of tasks between the two systems, while ensuring that a tool like RTC has all the information needed for planning and that the quality management tool is the system of record for tests and defects. Or you could deploy HP ALM’s Agile features in combination with open source issue tracking and change management. What’s important is that task federation provides you with the options needed to modernize and streamline your best-of-breed stack, while ensuring that development is connected to your ALM solution of choice. While no two ALM stacks are alike, in 2011 we will start seeing the developer and manager stakeholders insulated from the intricate details of ALM stack implementation, with ISVs taking on the burden of integration.