Get started Bring yourself up to speed with our introductory content.

Tracking the evolution of ALM tools

Modern ALM tools evolved from physical story walls. Matt Heusser explains what was lost in translation and what can be gained.

Typically, the metaphors for our software are borrowed from the physical world. For example, the idea of a "desktop"...

with "folders" and "files" on the personal computer comes from the very real desktop, folders and files. Similarly, the virtual card wall found in many application lifecycle management (ALM) tools comes from the physical card wall it replaced. Exploring where ALM tools came from and how they have evolved can help us understand where they might be headed.

One popular project management system today is David Allen's Getting Things Done. The first step in this system is to take an inventory of all ongoing work. Visualize each task separately and put all the tasks in a single box. Then you can go through the box to prioritize and decide which tasks to do first. That is exactly what Ken Schwaber did with his team at Individual Inc. when he was developing Scrum in the early 1990s.

Call them stories, use cases or features, the idea was to focus on the work people were actually doing, instead of the whole of what the customer would see. Breaking down requirements and specifications into individual tasks makes them easier to understand and act on. By placing these stories on cards on a board, sorted into categories of "to do," "doing" and "done," the team could visualize the work in progress, as shown in Figure 1.

LeanKit's ALM tool
Figure 1. A much younger author (left), with Jeff Koslowske in this 2004 photo, working on an early card wall.

Working a real card wall had advantages. The team could visualize if they were doing too many things at one time. Management could see which stories were blocked through the use of colored stickers and could go through the blocked items as a list, removing impediments. And the card wall had a physical space limit. If a customer wanted to put a new card in place at the top, something had to come off the bottom.

From physical boards to the Web

What looks to the user like a card wall is really a database with a Web-based front end.

Early Web-based project management tools started with a goal -- like getting the SquareCalc CD shipped to the duplicator on October 1 -- then broke the project into tasks, tickets or to-do elements. Each of these items could have discussion; when they were done, the tool crossed them off and eventually made them disappear, much like a to-do list.

The next generation of project tools took the card wall example and put it on your desktop. Suddenly anyone could create an account, double-click to create a card, save and move. The best example may be LeanKit and Trello, whose initial products were essentially "a card wall on your desktop." A recent image from LeanKit shows the product still living up to that idea (see Figure 2).

example of early card wall
Figure 2. An example of LeanKit's ALM tool.

The power of these tools is that now everything is flexible. Want to add a new column? Just right click and add a new column. Pictures of who is doing the work can magically appear on the story because the person who created or moved the story is logged in. Multiple teams can each have their own card wall.

Using a Web-based card well effectively

What looks to the user like a card wall is really a database with a Web-based front end. That means the system knows everything about every card -- when they were created, when they moved through each state and when they finished. That makes it possible to calculate the average cycle time (time spent on work) at each step of the process, and for the whole process. The team can say, "If you put a card in the number one slot as the first thing to start on next, it typically takes two weeks or less to get it done." That sounds better than, "We have 18 months of requirements to work on in our backlog." Cycle-time metrics change the team's thinking toward what to do next and help identify bottlenecks.

Of course, it is possible to calculate these metrics with a physical card wall, a spreadsheet and a little tracking, but the new breed of ALM tools made it an implement-once, use-by-anyone feature. Here are tips for using Web-based ALM tools effectively:

Keep the virtual card wall small. If your virtual card wall is too complex to "zoom out" and see the work of the entire team, the team is likely either too large, doing too much, blocked by something external or some combination of the three.

Limit work in progress. A card wall without work in progress will likely explode with work. This leads to multitasking, which slows delivery times. So, limit the work in progress at any step. When a contributor cannot work, because they cannot "push" work onto the next step (because it is at a limit), that person has to contribute by working on the bottleneck, which improves flow, or research and other tasks that can improve velocity.

Trade the customer view for the view of the work. A virtual scrum board, or kanban board, can present what the team is working on right now, making status visible. Still, remember the difference between a story and a specification, and carefully consider the two. Some teams may want a tool that can display both what is being worked on and what the customer expects to be delivered -- and when.

Balance between a team and many teams.Most successes come from a separate virtual card "wall" by team, with management able to zoom out to see the whole picture.

Let the computer do the spreadsheet work.Look for an ALM tool that can track progress and make predictions. If you have multiple teams and can assign stories to projects, see if you can zoom out to get a portfolio view, to predict what projects will end when, and what teams are available to start the next project.

Avoid comparing teams by story count and other productivity measures. Teams working on different assignments will "chunk" and process work in different ways. Manage teams by delivered value, not by comparing their work. If the value delivered is low, consider finding more valuable assignments for the team to work on.

Putting the card wall on a computer adds a great deal of physical constraints, like work in progress. The key is to keep that a feature without creating new bugs in the process.

Next Steps

The expanding role of ALM in the enterprise

Working with enterprise ALM: Mobile, cloud and more

Should you use cloud-based ALM tools?

This was last published in March 2015

Dig Deeper on Application Lifecycle Management Tools and Processes

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

2 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What do you think is the best use case for ALM tools?
Cancel
I believe the best use of ALM is in data warehousing for software development. I think if you focused on customer specifications for software development and used it for backlogging themes this would be the best case.  If you also focused on collaboration for efficient software, so there are no failures, this would also be a solid base.
Cancel

-ADS BY GOOGLE

SearchMicroservices

TheServerSide

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

Close