As agile methods are adopted more and more, 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 to increase efficiencies and productivity of all roles as part of the agile backbone.  To explore what this means, we look at several components of an agile shop.

Before starting, I'd like to point out that it is important to view the Agile process from an appropriate perspective.  Near the end of this article, I review the original Agile Manifesto, clarifying my view on each of them.  If you'd like to understand my views, you may wish to jump ahead before continuing.

ALM Support
In an Agile World, all next generation ALM tools and processes must support the following capabilities:

1. Changing Requirements
2. Rapid Customer Feedback
3. Release and Iteration Backlogs
4. Priority-based Scheduling
5. To-Do Lists
6. Peer reviews/comments
7. What's In the Build
8. Continuous Builds
9. Custom Dashboards
10. Process Guidance

I'm not going to pretend that this covers the entire spectrum.  But it does highlight some of the more prominent capabilities that stand out in my mind when considering how ALM can support an Agile World.

1. Changing Requirements
Requirements must change in a successful Agile environment.  Why?  There are several reasons.  The first is that the customer does not really know exactly what the requirements are.  Say the customer wants to ensure that backups can be done in less that an hour, but you show them a solution that allows continuous on-line backups which ensures that his off-line backups are less urgent.  OK - it's the best of both worlds.  Backups always available and up-to-date, and off-line backups can be done from the on-line 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 teams tells the customer that for 10% of the cost of the feature, 90% of the functionality can be made available.  Again, the customer may say, "Let's take the 90% and move the other 10% into a later release".  So the requirements change, again by way of the development team's input.

Then Google 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 next generation ALM tool can track requirements.  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 possible a set of minor releases), and across development streams so that the product can move forward over time with new major releases.

The ALM tool must do much more than that.  It must make it easy to collect and organize requirements.  And 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.

2. 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 (e.g. current release, future release, next iteration, etc.)

3. 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.  But the idea is the same.  The "tasks" are the "allocated requirements" - 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 are changing), 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" or whatever).  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.

So we eventually get a set of Activities or Tasks and we start prioritizing them - first by allocating them to a particular target release (release 1, release 2, etc.), and then by prioritizing them within each release.  Now if we don't start out with a full set of requirements, we won't 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.  And we can 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.

4. 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, just 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; and 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 road blocks 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 the 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.

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

Figure 2.  A sample Update Review Station (from CM+)

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 the tests in the ALM tool, preferably 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 type of questions must be easily supported to help with the effectiveness of the review process.

7.  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.  And this 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/changesets 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 (e.g. 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 - a reduction in documentation effort without a reduction in documentation.

8.  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 definition 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.

9.  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 centred 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.

10.  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 well understood process.  But process should help the agile development, 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.

And 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.

The Agile Manifesto
Well, 10 is a good number to stop at. But just to finish off, I'd like to review the agile manifesto.  What does it imply?  What should it imply and what shouldn't it imply.  Just so that everyone knows where I stand, the rest of this article sets out my views.

According to the Agile Manifesto, Agile methods value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Now although I whole-hearted buy into Agile methodology where appropriate, there are various interpretations of the manifesto that tend to de-emphasize processes/tools, documentation and following a plan.  I'd like to spend a few paragraphs ensuring we're on the same page.

Individuals and interactions over processes and tools 
For me this is a tough one. The is because I believe it should be primarily the processes and tools which facilitate the capabilities of individuals and their interactions.  Interactions are important.  But sometimes it's better not to have them.  

For example, if I can peer review code and add my comments on-line through the tools, I'm sure my review is accurately captured.  And I can do the review right away, rather than waiting for a scheduled meeting.  On the other hand, if there are issues that arise that require a meeting, its important that a meeting is held.  

At the same time, I need to ensure that my review comments follow a proper protocol.  I've seen reviews, live and written, fall into a feud. Individuals are important and should not be attacked. If the comments are public (i.e. within the product team), there's less chance of a feud happening - comments are more objective, as are responses. So the tools that make them public are important.  

Similarly, I don't need an interaction to tell me what problems have to be fixed. As long as they are assigned to me, and have well-formed problem descriptions, I can fly with them.  However, if there's ambiguity, I need to interact.  The interactions may be live, but perhaps sometimes a Q&A addendum to the problem report can document the clarification for future reference.

So to me this one is more:  effective tools and processes that enhance the productivity of individuals while encouraging interactions only as necessary.   Tools and processes are important.  They help ensure that interactions are more effective.

Working software over comprehensive documentation
Software has limited value if I don't know the extent of what it can do.  In some cases, an overview is good (e.g. word processing software) because I'm familiar with the application.  In other cases, I need comprehensive documentation.  This applies equally well to Requirements and to User Guides. Defining/learning a new programming language is an excellent example of where comprehensive documentation is key, both up front and after the fact. The fact that the compiler works well supporting some of the language features is less important if I don't understand those features. Also, if I have an Open Source application that has all sorts of features that I can't use because they're not documented, what a waste.

One of the key issues here is that this item tends to support a view where coding can get underway immediately. This results in less up-front architecture, and often in a lot of rework.  The push is to get something working fast, rather than to document a good architectural framework on which to build.  At Neuma, we definitely work towards getting features working/demo'd and adjusted, ahead of comprehensive documentation.  However, there are two caveats:  we always write a clear set of objectives (our "user stories", suitable for a "release notes" document) for all new features, prior to design and implementation so that we are sure to implement the correct feature; and, in the beginning, we spent a lot of time on architecture, prior to getting any working software done, and this paid off in spades, both ensuring we had a leading-edge capability in our products, and ensuring that we could go forward with a "working software" first capability.  Sometimes we'll throw out the original feature objectives part way through as we think of better ways to bring the capabilities forward.  And we do that before we do customer documentation.  We always do feature demos as part of the peer review process, and we ensure that our update "unit tests" are attached to the update, providing both test cases to draw from, and more specific details of how the features work.

Get your architecture right so that you can put working software first.  And be critical of the working software.  If it's going to require more documentation than users feel it should, perhaps the spec should be simplified.  "Why do I have two different panels coming up instead of one?" "Why can't I just click on this to get the information?"  "Why is this not consistent with the way other features work?"  Working software is great for bringing out these questions.  Specifications can be just too wordy to accomplish the same, especially those where they cut-and-paste 80% and then just fill in some blanks.  What a waste!

Customer collaboration over contract negotiation
Almost always.  It's better for the customer.  "You said you wanted this, but if we do this instead, not only do you have that capability - perhaps a bit different than you wanted - but you also get X, Y, and Z which you didn't ask for."  "Wow, that would be great."  It comes down to this.  If you're an expert in building software in your niche field, you understand the customer requirements better than the customer.  A few iterations and the customer quickly appreciates this and wants more.

Still, at times the customer is on a tight budget and timeline, or have hard requirements based on external integration specs.  So contracts still have their place.  But if you told the customer that you could do 80% of his features for 50% of the cost (30% is profit - that's why it's not the 80/20 rule), your customer would likely say - yes, let's start there and then we'll look at how we get the rest of the functionality we need, perhaps in the next release.  More than likely, a lot of that functionality either won't be needed or becomes obsolete based on your architecture.  For example, I wouldn't dream of integrating CM+ with a Database Vendor's reporting language just because the customer asked for it, or is familiar with it.  I'd show them the capabilities in the CM+ architecture that exceed their requirements, and then ask them if they really still need it. Of course, if it's needed to meet a blind requirements checklist, we'd show them how easy the integration is anyway, even though we wouldn't expect them to ever use it.  Collaboration is the way to go.

Responding to change over following a plan.
Planning is good.  It gives you a baseline.  The problem is that if you plan out further than you can see, your plans will become heavy millstones.  That's what's good about Agile - you plan out a couple of iterations or so in advance (after establishing a good architecture), and then you continue to run on a priority basis, based on what the customer tells you (and often the customer is the market).  I'm sure many mobile device companies were working on some nifty pointing devices prior to seeing the iPhone.  That changed the game.  If they didn't change and respond, they were toast.

At the other end, if you have a lot of features that are highly interactive (i.e. impact one another), then this could complicate your verification cycle.  As you reach the 75% completion point, you may want to carefully plan your iterations, or at least your release backlog, the rest of the way, and in such a way as to minimize the chances of destabilization or reduced quality.  Yes, your continuous integration is going to help you with quality, especially in the site of changing requirements, but at some point, you have to spend time to make sure that your product is 100% ready, not just stable enough to keep improving.  

Responding to change is following a plan - it's just a more fluid plan that focuses on priorities more than dates, and on minimizing acceptance risk more than content completion risk.  Your customer collaboration will help you deal with any specific risk items adequately.

OK.  You've heard a lot of my views... maybe you agree 100%, but more likely you don't.  I welcome your comments and will respond to them in a timely fashion. 

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment