Five Imperatives for Application Lifecycle Management
Table of contents
Overview
Real–time Planning
Lifecycle Traceability
In–context Collaboration
Development Intelligence
Continuous Process Improvement
Choosing an ALM Solution for Your Team
Overview
Many organizations are faced with hastened delivery schedules due to competitive pressures and the need to innovate. Yet software development is difficult, and the software systems that are maintained and delivered by the world’s IT and device development organizations are astoundingly complex. Teams challenged by reduced time to delivery must do so without increasing their budgets or sacrificing quality. Their strategy, instead, must be to improve software development efficiency. A solution to this dilemma is to improve Lifecycle Collaboration with Application Lifecycle Management.
Designed for the execution of a software delivery project, Application Lifecycle Management solutions coordinate people, processes, and tools in an iterative cycle of integrated software development activities, including planning and change management, requirements definition and management, architecture management, software configuration management, build and deployment automation, and quality management. In addition to the capabilities, the fundamental features of an ALM solution include traceability across lifecycle artifacts, process definition and enactment, and reporting.
The most important benefit of an ALM solution is coordinating the people, processes, information, and tools involved in a project to deliver innovation to your stakeholders. Because there is no one-size fits all solution, we advise our clients to focus on the following imperatives as they implement an ALM approach best suited to their environment and culture:
- Use Real-time Planning
- Establish Lifecycle Traceability of related artifacts
- Enable In-context Collaboration
- Cultivate Development Intelligence
- Practice Continuous Process Improvement
Real-time planning
We plan because we want to accomplish a goal and want to know when we are done. The only way to know when the work is complete is to ensure the plans are fully integrated with project execution and always up to date. The following table provides several typical dos and dont’s related to planning.
 Actions to avoid |  Recommended actions |
|---|---|
| Avoid creating an environment where requirements, designs, and development and test plans are disconnected and managed separately or not at all. | Choose planning solutions that track the work of the entire team, populate development and test plans from requirements and link individual requirements, development work items and test cases. Use plans that track all tasks for all disciplines in the life cycle-from multiple perspectives. Having plans with multiple views of the same data, such as ranked lists, work breakdown, roadmap or task board views, ensures that you can assess and balance the work of all team members to optimize time to delivery. |
| Avoid having plans that are not inside your ALM environment and are separate from team activities and assignments. | Use plans that are fully integrated with execution. Make sure all plans are visible and accessible to everyone on your project team. To keep plans accurate, make sure you can update the time spent directly on the task. Team members can see the effect changes have on delivery dates and can balance the workload to prevent critical paths or bottlenecks for delivery. |
| Avoid relying on manual updates because they can create errors. | To encourage full participation by the team, use plans with information at your fingertips and a user interface that makes it simple to update plan information in the context of the work. |
| Avoid creating a plan at the start of the project and then not using it again. | Practice continuous planning with real-time plans, life cycle queries and project dashboards so you can quickly respond to changing events or team changes. |
The following image illustrates how updating time spent directly from the work item in a matter of seconds makes easy to keep accurate plans.
Figure 1 Updating the time spent on a work item keeps plans accurate
The following three images show the same Sprint plan using different views. Using different views helps the team balance the work, plan effectively and respond to changes more quickly.
Figure 2 A planned time view illustrates when team members have more work than the others
Figure 3 An electronic taskboard view can be used across geographic locations by agile teams
Figure 4 A roadmap illustrates tasks over days and weeks in a more traditional view
The image below shows a Release Plan in Rational Team Concert containing links to a related Product Backlog, a collection of requirements in Rational Requirements Composer, and a test plan in Rational Quality Manager.
Figure 5 Planning includes taking the requirements and test plans into account
The IBM Rational Solution for Collaborative Lifecycle Management offers fully integrated real time planning.
Lifecycle traceability
Traceability isn’t simply one of those "nice to have" capabilities in the software development lifecycle. Traceability helps you understand what everyone else on the team is doing. For example, while the requirements analyst knows very well what requirements she has written, she still needs to know whether a given requirement will be addressed during a specific development iteration and, if so, which one. Or she wants to know if the implementation of that requirement has been tested and with what result.
An ALM solution that allows for lifecycle artifact traceability helps teams to answer the hard questions about the status of their project. By linking related artifacts, teams are better equipped to answer questions such as "which requirements are affected by defects?" and "which work items are ready for test?"
Figure 6 Important questions answered by an ALM solution
Traceability helps the each team member understand what the rest of the team is doing and how it impacts the overall workload. If you are working in a regulatory compliance environment, traceability helps you answer auditor’s questions such as "What changes went into this build, what tests where run and with what result?"
Below are typical do’s and dont’s associated with traceability:
| Actions to avoid | Recommended actions |
|---|---|
| Avoid solutions with complex user interfaces that discourage users from linking related artifacts. Avoid the temptation to overdo traceability links, or doing traceability for “traceability sake.” | Use a solution that makes it easy to establish and maintain traceability links with a simple, unified user interface so no one has to switch to another tools just to link two artifacts. Identify a few meaningful questions that you want to be able to answer and create a linking strategy accordingly. Try one and make sure you become competent at it before trying the next one. |
| Avoid running reports that quickly become outdated and traceability solutions that do not provide insight into project completeness. | Use a system that provides queries, reports, and views that make it possible to assess completeness and make fully informed decisions based on artifact relationships. You should also be able to see the traceability links directly in the plan. Examples of queries that identify gaps include “plan items without requirements” and “plan items without test cases.” Queries that help you assess completeness include “plan items with failing tests,” “defects blocking test,” and “requirements with open defects. ” |
| Avoid solutions that do not take compliance and other regulatory requirements and audits into account. | Invest in a solution that includes traceability for compliance – traceability that is easy to maintain and report about. |
| Avoid using disconnected project databases, building your own integration based on proprietary APIs and trying to combine unrelated sets of tools. Avoid solutions that do not provide open interfaces for creating linked data. Avoid entering links manually after the fact because some can be easy to forget and the process difficult to enforce. Avoid choosing a single ALM repository with proprietary integrations. | Integrate your cross-functional teams by choosing a solution with open services for linking data for the entire life cycle. Choose a solution that features open interfaces with open services (OSLC) for linking data over the life cycle. Select a product vendor that understands and supports the ALM integration challenges. Invest in tools with a longer-term integration roadmap in mind because they make it easier to establish links and traceability as your project executes. Choose a solution that can scale and can support open and flexible integrations so it can fit your needs over time. Times change, new products emerge, and your ALM solution should move with the times. |
The image below shows a traceability view in a release plan containing links to requirements and test cases. It also has a column to identify defects affecting the plan items. This demonstrates an integrated plan with traceability reporting. Rather than relying on stale and occasionally run traceability reports, using an integrated plan with a built-in traceability view, the gaps are obvious and easy to address through out the project.
Figure 7 A release plan with coverage across the development, requirements and test teams
When traceability links are established, the IBM Rational Collaborative Lifecycle Management solution leverages these links to automatically create traceability links on defects found during test execution by testers. The image below shows a defect with traceability links. The traceability links to the test result, test case, test plan, plan-item and requirement, are automatically generated when a defect is submitted from a test execution.
Figure 8 Lifecycle links automatically created on a defect illustrate the impacted test cases, plan items and requirements
In–context collaboration
Collaboration isn’t just about being friendly and collegial with each other. Collaboration contributes to higher quality and improved value to the stakeholders, which means, collaboration is a key to innovation. Collaboration features within an ALM solution can improve a team’s ability to connect with each other, to respond to changing events, and to improve project predictability.
Collaboration tools can also help teams focus on what matters. Teams should seek every opportunity to automate manual, non-creative tasks. A good ALM solution enables build and test automation, but automation can also apply to status reporting and information access. Project and personal dashboards play an important role in bringing automated information to the team by providing transparency into their work and access to real–time data with team reports and queries. A well–designed user interface automates access to information, by bringing information to the user instead of forcing a manual ‘context switch’ to access another application. This form of automation naturally leads to better collaboration.
| Actions to avoid | Recommended actions |
|---|---|
| Avoid relying on emails, chat programs, disconnected spreadsheets and “word of mouth” as your collaboration tools. | Use a system where information is immediately acessible to all team members right in the context of the work. Integrate all discussions about work items into the plan so your ALM environment becomes an essential single source of truth for understanding the past, which speeds up the process of developing product enhancements in the future. Unify your team by making sure they can share linked data. Hovering a mouse over a link should provide information about the artifact at the other end of the link. |
| Avoid ignoring stakeholders or assuming you know what they want. | Use online reviews, approvals, and threaded discussions to elicit and respond to stakeholder feedback early and often. |
The image below shows a dashboard mashup with widgets containing information from Rational Team Concert, Rational Requirements Composer, and Rational Quality Manager. The information in the dashboard provides up to date status about the project.
Figure 9 Mashup dashboards provide transparency across the team
The image below shows a "mini dashboard" that is always accessible from the side of the UI and is dockable on left or right. It serves as a portable mini personal dashboard that goes with a user wherever they go within the ALM solution, and can be shown or hidden at any time.
Figure 10 A mini dashboard is accessible through out the user interface
The image below shows a mini dashboard for a user in Rational Team Concert. On this mini dashboard is a widget displaying changes to requirements in Rational Requirements Composer. This is a mini dashboard mash up. Hovering the mouse over the link to the requirement causes a link preview (rich hover) to appear with information about the status of a requirement in Requirements Composer. Users in need of instant information gratification will quickly become addicted to using mini dashboards!
Figure 11 A rich hover on link from the Mini Dashboard
Development intelligence
How do you know if you’re improving if you don’t create success metrics? At any time in a project do you know if your team is trending toward a successful outcome? Implementing areas for improvement, setting goals, and tracking your progress toward achieving those goals cultivate development intelligence.
According to Capers Jones,1 projects with strong measurement practices have much better success rates than those that do not.
Figure 12 Projects with measurement practices have a better chance of succeeding
For example, the three measurements listed below are practiced by less than a 50% of all organizations in the Capers Jones study:
- Quality measures 45%
- Productivity Measures 30%
- Complete Measures 15%
Here are our suggested do’s and don’ts regarding measurement practice:
| Actions to avoid | Recommended actions |
|---|---|
| Avoid trying to apply performance measures from other organizations or from external sources to your projects. | Identify performance measurements that are appropriate for your organization. |
| Avoid relying on manually collected data, such as asking the team for status updates or keeping spreadsheets on your hard drive. | Make fact-based decisions by relying on automatically generated live dashboards and reports that are based on data coming from team activity. |
| Avoid trying to define all measurements for a project at the same time. | When defining a measurement, start small. Identify a weak spot, decide and choose on a practice for improvement and determine how you will measure the improvement. Use a tool that collects information about your team’s activity to steer the team toward the improvement you seek. |
The image below shows reports on the development team within a project dashboard. As work items are updated, the reports reflect the activity and trends of the team. Use burn down charts to track the team’s trend toward closing out planned work. Alternatively, consider charts that show the trend of Open, In Progress and Closed work items, where the ideal is to see the Open & In Progress trend getting smaller while the Closed trend gets larger.
Figure 13 A dashboard with reports and metrics to measure improvement
Dashboards and reports are key part of an ALM solution for measuring and responding to a team’s progress.
Continuous process improvement
Process is more than a documented set of procedures. We design processes based on best practices gleaned from industry experience as a means to improving a team’s collaboration and to help them succeed. Most behavior is habitual. When you define or change a process, you are asking an entire team of people to change their habits and adopt behaviors that at first may be difficult to understand. It can be quite hard to change one habit in one person. Yet, process changes frequently require new ways of thinking and new modes of behavior for a multitude of people. A well–designed ALM solution allows you to change that process incrementally, improve the team dynamic and continue to refine toward greater efficiencies.
| Actions to avoid | Recommended actions |
|---|---|
| Ignore process altogether or treat it like an unnecessary burden. | Realize that continuous improvement can help your team adopt best practices to establish a rhythm and reduce unexpected problems. |
| Avoid the temptation of al all-at-once approach to improvement. Avoid trying to define too much of an entire process at a time. | Promote incremental improvement by continuously customizing plans and dashboards to drive the team’s focus given the current status of the project. Use an approach that can improve upon where you are now. |
| Avoid defining a process once and relegating it to a hard drive, never to be seen again. | Promote breakthrough improvement by capturing best practices in the form of process specifications, templates and automation that many teams can reuse directly in the same tool. |
| Avoid insulting “process police.” | Encourage all team members to participate by choosing a system that makes continuous improvement easy and something that can be done in a tool that everyone shares. |
| Avoid defining process improvement without end result visibility. | Make the results of process improvements visible in dashboards when you define process improvements. |
| Avoid the expectation that you must get everything right the first time. | Understand that there is always room for improvement. To that end, review improvmeents continuously and identify the next set of improvements. |
Rational Team Concert provides process specifications that you can use to get your teams up and running. These process specifications provide work item types, state transitions, and rules that govern how to use them. In addition, teams can modify the process to suit their needs. A process can be deployed to an entire project, or modified for a team within a project. Processes can even be modified ‘in flight’ to adapt to the changing conditions on the project. The image below shows the default set of work–item types that are defined by Team Concert’s out–of–the–box Scrum process template.
Figure 14 Work-item types that support Scrum, come out of the box in Rational Team Concert
Tools that support the process and guide team members toward the expected behavior are important elements in an ALM solution.
Choosing an ALM solution for your team
Choose an ALM solution that supports and encourages collaboration regardless of role, organization, or geographic location. The IBM Rational Solution for Collaborative Lifecycle Management meets the five imperatives described above. The solution consists of IBM Rational Team Concert, IBM Rational Quality Manager, and IBM Rational Requirements Composer.
Rational Team Concert integrates work item tracking, source control management, continuous builds, iteration planning, and highly configurable process support to adapt to the way you want to work, enabling developers, architects, project managers, and project owners to work together effectively. Multi-platform development such as Java, .NET, and mainframe environments are all supported. Rational Team Concert has built-in integrations with Requirements Composer and Quality Manager, along with many other popular development tools. Learn more on the Integrations page on Jazz.net.
Teams seeking to add rich requirements definition and management use Rational Requirements Composer. Requirements Composer is being extended to provide both requirements definition and management capabilities for fast-paced, market-driven project teams. Requirements Composer has built-in integrations with Team Concert and Quality Manager, along with many other popular tools. Learn more about Requirements Composer Integrations on Jazz.net.
Teams seeking to improve their ability to meet quality goals use Rational Quality Manager, which has built-in integrations to Rational Team Concert and Rational Requirements Composer. IBM Rational Quality Manager helps organizations optimize project quality with a single, shared test management hub that provides integrated lifecycle support across virtually any platform and type of testing. It provides a customizable, role-driven solution for test planning, creation, and execution as well as workflow control, tracking, and end-to-end traceability.
By using these products together teams can live up to the five ALM Imperatives described in this article. The imperatives are built in, and ready to help you improve your ability to deliver high quality software innovation. What ’s great is that you don ’t have to use all three to reap the reward. The products can be used in any pair, or all together.
We welcome you to visit Jazz.net to learn more about Rational Collaborative Lifecycle Management, powered by Jazz.
1 Capers Jones, "Measurement, Metrics and Industry Leadership," 2009, and Software Engineering Best Practices, McGraw Hill, 2010.
About the author
Carolyn Pampino is the Program Director for Strategic Offerings focused on IT Software Delivery. She is a member of the ALM leadership team at IBM Rational, working closely with the Jazz team leads to define the Collaborative Lifecycle Management road map and strategy. She contributes blog entries and recorded demonstrations to Jazz.net. Carolyn is a co-author of an eBook, titled "Scaling Agile with Collaborative ALM." She is also co-author of an IBM Redbook titled "Collaborative Application Lifecycle Management with Rational products". She was a founding member of the team defining strategies for Rational and Tivoli product integrations, and contributed to Rational’s acquisition of Build Forge. Prior to IBM, Carolyn was the Director of Product Management, Development, and Competitive Intelligence at BroadVision, Inc.
Carolyn thanks Erich Gamma, Kim Peter, Robyn Gold, and Fariz Saracevic for their contributions to this article, and the entire Jazz Foundation and Collaborative Lifecycle Management teams for creating an incredible solution!
© Copyright 2011 IBM Corporation