Application lifecycle management aligns all application teams to the process of planning, developing, and testing software applications. Doing this increases control, visibility, and predictability throughout the entire process. It also enables change management, risk-based prioritization, and communication across disparate teams.
Developers are often resistant to participating in ALM, but without their cooperation, ALM cannot deliver all of its promised benefits. Application lifecycle management must evolve to adapt to the people that enterprises need to utilize it.
Why Developers Need ALM
Most enterprises haven’t tried to standardize across a single platform for ALM because they know developers want to use the best-of-breed tools of their choice. But while that approach helps developers do their jobs, it also causes problems.
For example, suppose Team A, a global company, uses Java, Eclipse tools, and agile processes, while Team B uses Microsoft Visual Studio and waterfall processes. In the absence of a comprehensive ALM system, Team A and Team B cannot keep up to date on each other’s activities. Stakeholders on Team A may not be aware of the identification of a software defect or the changes made in response to it by Team B. Disjointed communications and a lack of traceability lead to lost productivity, project delays, and costly rework later in the application development process. Developers simply cannot properly communicate without ALM.
Why ALM Needs Developers
Most ALM solutions connect business analysts, testers, and project managers on a single, unified platform, but that’s not enough to make a project successful. ALM won’t give a comprehensive view of the application’s lifecycle if it doesn’t capture the most up-to-date development work as well.
What’s needed is an end-to-end solution that provides a common application management platform that all project stakeholders share, while allowing development teams to use their tools of choice. By introducing lightweight processes and tools that enable developers to work in their familiar environment, it is finally possible to bring the development team into the ALM fold.
ALM of the Future
Along with addressing the needs of developers, the ALM solution of the future will allow them to use the tools of their choice, while letting them quickly assess the current state of any application, including:
- The business goal. Why is the new content or new code being checked in? What functionality is it supposed to deliver?
- The motivation. Is its aim to fix a defect, or is it a derivative of a new requirement or a new user story?
- Traceability. To which build does the content belong? Which requirement or defect?
- Release progress. How does this content contribute to the progress of the release or the iteration? How does the new piece of code help the team achieve its goals for the release?
- Risk assessment. How stable is this code? Does it have areas that are fragile and need further attention by the testing team?
- Governance. How can we ensure that developers are spending their time in alignment with business priorities?
This kind of context-driven coding helps developers better understand where their work fits in the bigger picture. In addition, context-driven reporting—in which the ALM system is automatically updated as the developer codes—can tell the rest of the team what’s happening. Tasks should be presented in the development environment in a way that frees developers from the need to report progress, update status, and add a description of their work. Integration between the developer’s environment and the ALM system enables this kind of context.
The next phase of ALM must deliver capabilities that can serve the needs of the business and get developers involved. That’s the only way to take full advantage of the full promise of ALM: control, visibility, predictability, and less risk.