The Next Generation: ALM Tools for an Agile World

of the product manager and development team based on things such as ease of solution, potential risk to stability, and availability of personnel and other resources.  Time has to be allotted into a schedule based on the expected problem volume, which in turn is a function of the team's skills, product architecture, and design practices.

But all in all, problems form part of the product backlog, though not all problems will make it into a specific release or iteration backlog.

Figure 1.  A Product Backlog Dashboard (from CM+) showing both activities and problems.  Clicking on a bar of the graph
results in a scrollable list of activities/problems.  Clicking an activity/problem to zooms in to details. Right-click for actions.

5. To-Do Lists
Everyone in an agile shop needs to know what they are working on in each iteration.  In a next generation ALM tool, they click on their to-do list and drill down into details.  If they need to see what someone else is doing, they click on their to-do list.  The ALM tool serves as a communication tool.  It does not replace communication, but it fills in a lot of the details that don't need to be communicated verbally, allowing for more efficient and more relaxed verbal communication.

To-do lists come in two forms: those assigned to specific users, and those assigned to teams or groups.  For example, if you have a dedicated problem fix team, you might have all accepted problems assigned to the team, rather than to individuals.  Members of the team select work on a "what's next" basis.  As long as your ALM tool allows you to customize this behavior, you're in good shape.

But to-do lists go well beyond implementation tasks.  There are documentation tasks, testing tasks, document reviews, peer reviews, and perhaps a number of other to-do lists.  The ALM tool must allow you to manage all of these lists, and it must also allow you to customize each user's view of these lists, based on things such as roles, assigned work and user preferences.

6. Peer Reviews and Comments
Let's make a basic assumption that when changes are made to the product software, the modified files are packaged into change packages/updates/changesets, or whatever you want to call them.  Next generation ALM tools support this concept.  So the ALM tool must also support a way to identify the specifics of each change - the delta, or difference, reports.  The tool must either allow a variety of presentation formats for viewing differences, or else allow the tool(s) of your choice to be plugged in to provide the presentation of choice.

The most important use of delta reports is for peer reviews.  In some shops, peer reviews are done with a bunch of people around a table watching a presentation of the delta report.  This would be considered a waste of time and resources in an agile shop, especially if there's extra administration and delay trying to get everyone together for the review.  What's important is that the right team members review the delta report and identify any issues or potential issues.  This is usually most effectively done one-on-one, but with appropriate tools, reviewers can do reviews on their own time while at the same time ensuring that their comments are captured in the repository.

Ideally, an ALM tool will present reviewers with a "review station" where they can select the update they wish to review, and enter comments directly into the review station.  This might be the form of an annotation tool, or in the form of a review comments field.  The comments, in either form,