Jurgen Appelo posted a great slide share a few years back on Agile ALM.  While there is a lot of great content in the slideshare, including covering the difference between ALM 1.0 and ALM 2.0, my favourite section is the 7 tips for Agile ALM.  These tips provide guidance on what the tools should do, as well as how to go about selecting the tool.

I have quoted the tips below for easy reference, along with some personal commentary from my own experience, but I highly recommend reviewing the entire slideshare: http://www.slideshare.net/jurgenappelo/agile-alm

1. High-Bandwidth Commmunication

ALM tools should support high-bandwidth communication, and should not needlessly replace person-person communication with person-tool communication.

Example: facilitation and storage of photos, audio, video.

Any team member who spends their time trying to get the tool to work, or waiting for the tool to respond to a request, or download/attach large media files at a slow pace is wasting valuable development time. The tools need to be able to support the process in such a way that the team members will not feel the need to work around the tool to be more efficient.

One of the trickiest pieces is balancing the amount of communication done via the tool. Especially with requirements tracking and bug tracking tools, most of them are so capable of communicating state, details, and media that developers don’t necessarily need to talk to the product owner once a story is assigned to them. Globally distributed teams generally use the digital story boards, instead of the physical ones that are more favoured by agilists, which leads to a digital communication via the tool. How to solve this?

One simple way is to add into the description a piece that states “Speak to <person name> for more details”. This implies to the team members that all of the details are not present, and invites a conversation to occur.

2. Agile Best Practices

ALM tools must natively support all common Agile practices.

Example: user stories, acceptance testing, iterative planning, continuous flow, unit testing, refactoring, automated builds, continuous integration, etc.

While a great tip, it is very difficult to find a tool that will do all of the agile practices in one, and do all of them well. The most complete suite I have seen comes from Microsoft in their Team Foundation Server ALM set. It captures all of the common practices, but is not best-in-breed in all areas. Some other tools may have better user story tracking, or better automated builds. As an organization, the decision needs to be whether to try to attempt a “single truth” approach, or to take best-in-breed tools from a variety of vendors and attempt to find a way to simulate the “single truth” via tool integration.

3. Bottom-Up Infrastructure

The ALM infrastructure must be selected, built and maintained by the team(s) themselves. Nothing should be mandated by those who don’t have to work with it.

Example: a team can select its own favorite automatic build system or Agile planning tools.

With small groups, this works very well. However, I have seen the mandated tool issue happen in larger organizations, as the budgetary investments in licensing is far more efficient if all teams consolidate on a single set of common tools. When there are 20 or 30 separate development teams, having them all agree to want to use the same tool is incredibly unlikely. In these cases, a decision needs to be made on cost versus adoption. Allowing each team to choose their own tools can lead to very large licensing costs, as well as the need to have ongoing experts and support staff for each toolset, and training for employees as they move from team to team.

Sometimes it may be more efficient to try to get input on tool selection from the mass group, and then choose tools that address most, if not all, the desires of the team.

4. Multi-Vendor Approach

A healthy ALM strategy will allow for multiple vendors of tools. The benefits of specialization (of tools) often outweighs the cost of integration. There is no “single truth”.

Example: use Visual Studio Team System except source control

It is interesting that in 2010 this slideshare referenced using Visual Studio Team System without source control, given this year’s announcement from Microsoft of the capability to integrate Git as the source control for Team Foundation. Finding ways to roll together multiple specialized tools can provide the best experience for users, while still providing a combined view.

5. Distributed Information

ALM tools should aim for accessibility. The goal is collaboration, not centralization. Information should be radiated, not concentrated.

Example: status updates on whiteboard and in task tracking tool.

The concept here is very consistent with most co-located agile best practices. Information radiators for stories, investment themes, etc. However, geographically distributed teams will not be able to take advantage of the information radiators. In these cases, effort needs to be taken to make sure the tools involved become a part of the daily activity (browser home page, shared during daily stand-up, etc.)

6. Agile Improvement

Modeling of processes is a form of prediction, and thus unreliable. Allow for emergent design of the ALM infrastructure. Grow it in an Agile way.

Example: use a continuous improvement backlog for the ALM infrastructure.

Switching planning over to an agile model is the easier part of the decision. ALM infrastructures do not require 5 year plans in order to be successful, and can be planned as iterative improvements. However, it needs to be expected that along with using an emergent design will come the need to refactor. ALM tools previously built into processes may no longer be sufficient as new tools come on board, or may need to be upgraded or have their configurations altered to more fluidly work with newer tools. This should be expected, and not feared.

7. Adaptable Tools

ALM tools must be extensible, customizable and adaptable, so that they can grow together with the project.

Example: open API’s, web services, plug-ins, widgets, macros, etc.

Most vendors these days will provide these pieces in order to compete with each other, but rarely do the APIs support full integration for one tool to another. It can be quite expensive to get these tools to adapt together, depending on the tool, so when choosing an ALM tool be sure to investigate the integration capabilities of the tool.