Ten Capabilities that ALM Tools Must Support

Before starting, I'd like to point out that it is important to view the agile process from an appropriate perspective.  If you'd like to understand my views of agile before you begin this article, I review the original Agile Manifesto here, and clarify my view on each of its items.

As agile methods are adopted more frequently, it is crucial that ALM tools and processes grow to support these projects. Next generation ALM tools must not interfere with development by adding overhead. Instead, they must help increase efficiencies and productivity of all roles as part of the agile backbone. In an agile world, ALM tools and processes must support the capabilities listed below. I'm not going to pretend that this list covers the entire spectrum, but it does highlight some of the more prominent capabilities.

Changing Requirements
Requirements must change in a successful agile environment for several reasons.  The first is that the customer does not really know exactly what the requirements are.  Say the customer wants backups that can be done in less that an hour, but you show them a solution that allows continuous online backups, making his offline backups less urgent.  It's the best of both worlds.  Backups are always available and up to date, and offline backups can be done from the online backups.  "Yes, I prefer this," says the customer.

The development team can provide solutions that the customer doesn't think of.  The team, not the customer, is most familiar with its technology in almost all cases.  In another scenario, perhaps the team tells the customer that for 10 percent of the cost of the feature, 90 percent of the functionality can be made available.  Again, the customer may say, "Let's take the 90 percent and move the other 10 percent into a later release." The requirements then change, again because of the development team's input. Google then comes out with a new product that will make the customer's product look outdated.  Again, the customer says, "I need some new features that position us ahead of Google in the market when we release."  And new requirements are born.  No sense in sticking with the old ones if the product is doomed to failure.

A requirements baseline for the first release is no longer a static contract delivered to the development team.  Instead, it is an initial look at what the product might do.  In an agile world, the baseline might be incomplete at the start of the development cycle.  It will certainly change prior to the release date.  To cope with this, the development team must be able to start work from an evolving set of requirements.  

The ALM tool must be able to track the initial set of requirements and must manage new baselines along the way.  It must be able to quickly and easily show differences between any two baselines of the requirements.  It must allow the baselines to evolve both within a development stream (culminating in a release) and across development streams so that the product can move forward over time with new major releases.

The ALM tool must also make it easy to collect and organize requirements.  It must be able to track the potential impact to the requirements as development changes occur, as well as the impact to development as requirements are modified over time.

Rapid Customer Feedback
One of the key reasons for requirements change is that in an agile world, there is plenty of customer feedback along the way.  As the customer views the product's evolution, perhaps at the end of each iteration, feedback is provided identifying, for example, potential issues with the user interface, potential improvements based on demonstrated product capabilities, and clarifications to requirements once thought to be unambiguous.

The ALM tool must be able to track this customer feedback. Ideally, the customer has the capability to enter requests along the way (maybe from a smartphone or tablet interface).  When the customer is really multiple customers, or even an industry, the ALM tool must be able to track each customer's input and must be able to identify for each customer the status of each request.  Some requests may be at odds with other customer requests.  Some may be duplicated.  Some may be ambiguous.  The ALM tool helps to capture initial requests and move it along the work flow so that an unambiguous requirement results that can be added to the appropriate part of the development team's task backlog (i.e., current release, future release, next iteration, etc.)

Release and Iteration Backlogs
The customer requirements are turned into tasks or activities in an agile world.  This is a bit different from developing a new set of allocated requirements for the next phase of development, as is done in a traditional project.  The idea is the same.  The tasks are the allocated requirements with no need to track project management activities and internal (vs. customer) requirements as two sets of objects (i.e., one for a requirements management tool and another for project management).  In an agile world, these really become one and the same.  In fact, in a traditional project, I would argue that there should not be separate internal requirements and project management repositories.  This is duplication of effort and results in lower quality.

What's really important is that we know what the customer has told us (customer requirements, which continually change), and what our tasks are to accomplish those requirements.  We also need the traceability from the tasks back to the customer requirements, and ultimately from the test cases and test results back to the customer requirements.  This is where a next generation ALM tool can help make this traceability automatic.  For example, you create a new task, not by clicking on a new task button, but instead, by right-clicking a requirement and selecting “add requirement task"  (or "add activity" or "add internal requirement task").  The traceability is then automatically associated between the two items.  Similarly, as updates (i.e., change packages) are created from the tasks, a similar set of actions help to ensure that the traceability extends down through the process.

Eventually we get a set of activities or tasks and we start prioritizing them.  This is done, first, by allocating them to a particular target release (release 1, release 2, etc.), and then by prioritizing them within each release.  If we don't start out with a full set of requirements, we won't then have a complete activity/task list.  But we will have the beginnings of a product backlog, which will grow over time in an agile world.  We can also trace this backlog back to the requirements that have been addressed.

We will also need to track versions of requirements, or more accurately, changes to requirements.  Our traceability needs to be at the level of requirement revision, so that if a requirement changes, we can identify impact and create additional tasks, traced back to the later revision.

As we look at the tasks for each release, that is, at each release backlog, even though incomplete, we can begin to identify which tasks will be addressed first.  The ALM tool allows us both to prioritize tasks and to assign them to an iteration.  It must also allow us to right-size the tasks.  No sense in having a 4-month task with 2-week iterations.  The agile process being used must allow tasks to be broken down into roughly iteration-sized tasks, though some may have to span multiple iterations.  The ALM tool must allow a representation of such a work breakdown, and must also facilitate it's creation by allowing us to track and identify sizing.  Furthermore, the ALM tool must allow us to express dependencies between tasks, so that if we see one, we can rapidly and easily record it so that the ALM tool will bring it to our attention if we try to implement one task before its dependencies have been completed.

In the end, we will have a product backlog, release backlogs for the product, and iteration backlogs for each iteration within a release of the product.  The ALM tool must make it easy for all team participants to view these backlogs.  Some want to view it from a product perspective, some from a developer's perspective.

Priority-Based Scheduling
The basic process we've just discussed is really a priority based scheduling process.  What we're doing is taking our requirements, converting them to tasks and prioritizing those tasks. This process isn't really much different from a traditional approach except for a few key points:  We don't know all of the requirements yet.  After prioritizing tasks, we don't have to associate start/end dates with them, but rather iterations, and this is done in an ongoing, rather than a big bang, fashion.  We do some right-sizing of the tasks to fit our iterations, though some tasks may span more than one iteration.  Finally, we allocate requirements to tasks, rather than to the next level of requirements.   

Such a priority-based scheduling capability within an ALM tool will also be able to support a traditional project, provided the ALM tool can also assist with traditional scheduling.

In an agile world, we're going to hit roadblocks along the way and we'll have to adjust priorities.  This is fine if we're using a priority-driven development process, as most Agile methods are.

Now as well as these tasks that come from requirements, there are problem reports/defects/bugs or whatever you want to call them. These have to be factored into the schedule.  There are two ways to do this. One is to create tasks for problems.  The other is to treat problems differently from tasks.  The latter is the better practice, even in an agile world.  

Problems are different animals than feature tasks.  They require different processes.  A feature creates new functionality that must be specified, documented, designed and implemented, perhaps with a change to training courses.  A problem corrects behavior to correspond to existing specifications and documentation.  The main effort in fixing a problem is usually in reproducing it, and the problem report should already identify how that is done.  Often the first response is to develop a workaround, which effectively reduces the priority of the problem.  A problem could take a few minutes to fix, or a few days.  Problems are used to measure product quality.  Problems don't look good in a product, much worse than the lack of a feature.  They're different.

A next generation ALM tool will support separate tracking of problems and tasks/activities.  Scheduling of problems may be similar to or different from feature tasks.  A typical agile strategy might suggest that emergency problems pre-empt any current work, high priority problems be scheduled into the current or next iteration, and other problems fixed at the discretion 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.

To-Do Lists
Each person 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.

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/change sets, 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, then become part of the change package, a record that the developer can deal with as necessary.  Again, communication is improved.  Or the same form can be used in a one-on-one review.

Peer reviews are essential in agile shops because each iteration must maintain the stability of the software.  Perhaps design managers will review their staff's changes.  Perhaps a quality team will do an independent review. The key is to make is easy and presentable and to have the ability to capture comments in context.  And the review should also cover the (change) unit testing performed by the developer.  This can be facilitated by capturing tests in the ALM tool and, preferable, is done in executable format so that they may evolve into test cases.  The tests can be reviewed, and demos should be encouraged as part of the peer review where possible.

One more key capability that the ALM tool must provide as part of a review station is the ability to zoom into to the questions that come up during a review:  What are the details of the task/problem from which this change results; where is this identifier referenced?  When was this line or that line (not part of this change) added into the code, and why?  These types of questions must be easily supported to help with the effectiveness of the review process.

What's In the Build?
The ALM tool should also help everyone to identify what's in the build.  What's going into the next iteration build or nightly build or integration build?  What went into the previous build or the previous iteration build?  These types of questions must be supported.  This also needs to be available at various levels of detail.  The most important capability is not what source code differences there are.  But instead, which problems were fixed, which features implemented, which updates/change sets were added to the build?

What's in the build?  This is a relative question.  If I'm doing truly continuous builds, the latest update is in the build as compared to the previous.  But more likely you'll want to ask:  What broke this feature that was working in the last iteration? What change caused this feature to stop working for this customer?  What features and problem fixes have to go into the next set of release notes?

One of the purposes of continuous builds is to help ensure that not too much changes between each tested build so that when a problem does occur it's easy to pinpoint the change that has caused it.  That's good.  Especially if you have an extensive set of automated tests that can be run on each build (i.e., nightly build).

But when a problem arises that is easily reproduced, but hard to diagnose, efficiency can be gained by allowing a preliminary view of the features, problems and updates that have gone into the failed build as compared to the last known working build.  In such a case, it's possible to save days of work if your ALM tools can help you locate potential causes without having to do so at the source line level, or by using a debug session.

Of course, if we want to stress working software over documentation in an agile shop, it helps if the ALM tool can also produce the release notes for us, based on the traceability information and the build content.  Imagine not having to create release notes and having a reduction in documentation effort without a reduction in documentation.

Continuous Builds
Agile is not agile without continuous builds.  Although there is some leeway in what is meant by continuous, the key is automation.  Automation of the build sequence encourages developers to create builds prior to check-in.  Automation allows early detection of potential issues.  Continuous builds encourage a culture of ensuring that developer changes are of high quality.  If automation can be advanced into the sanity testing phase, all the better.

Next generation ALM tools must support continuous build automation.   This includes easy and automated definitions of build contents (based on rules), retrieval of source code and whatever else is necessary to perform the build, launching of build scripts, packaging of the build artifacts, and collection of build results.

Custom Dashboards
There are various roles in an agile shop, as in any shop:  product owner, developer, customer/designated user, etc.  The key to keeping each role moving smoothly is to have effective dashboards.  Ideally, communications sessions should be centered on a single dashboard, showing what the past day’s/week's accomplishments were and what's in store for the next one.

Dashboards can cover a number of areas:  iteration status, problem/defect status, product/release/iteration backlogs, requirements traceability, quality metrics, etc.

It's fine to have an ALM tool with a number of canned dashboards.  But to really allow you to streamline your agile processes, you need to be able to rapidly and easily create and customize dashboards to your specific roles and tasks.  You need to be able to present information such as progress/burn-down charts, work breakdown structures, build content comparisons, etc.  Ideally, you should be able to sit down and, for each role or significant task, identify exactly what you want on a dashboard.  And then you should be able to spend a few minutes or hours to produce the dashboard.  This is one of the key differentiators between current and next generation tools.

Taking it one step further, you should identify what you need to run meetings from the ALM tool, using meeting dashboards.  A peer review station would be one example.  A problem review board meeting might need a specific dashboard.  Your weekly scrums should have their own specific dashboard.  The dashboard provides your agenda while at the same time allowing you to easily capture whatever actions or other information that come up during the meeting.  It also provides drill-down capabilities and traceability navigation so that both content and reasoning is accurately portrayed.

For a product owner, the dashboard should give you the capability of zooming into a release and/or iteration and it should consolidate the feature task/activity backlogs with the problem/defect backlogs so that a clear view of the current and future campaigns is always at hand and up to the minute.

Process Guidance
The myth that there is little process associated with agile methods comes from the focus on less overhead and administration.  This, in turn, actually means that there is a requirement for a well-understood process.  Process should help the agile development, though, not stand in its way.

The ALM Tool can support this by helping with a streamlined operation that focuses on the iteration model and continuous builds, but precisely customized to the project needs.  It's amazing how a single field on a form can slow down an action.  At the same time, the tool has to use the user context to capture information rather than forcing entry by the user.

When the user is unsure how to proceed, quick guidance must be available as part of the tool, perhaps as a diagram, perhaps in a role description or procedure.   Next generation ALM tools allow guidance to be easily customized from a reasonable starting point reflecting the team's overall methodology.

It's not that there's little process.  Rather it's the fact that the tool is knowledgeable and is able to help the user through each role, each task, while collecting valuable information from the user's context and actions.