Agile ALM for Delivering Customer Value: Back-end Disciplines

Part 2 of 2
In this second part of a two-part series, Mario Moreira explores the back-end disciplines of a lifecycle that establishes an ALM framework centering on customer value. If your organization has adopted agile and you are looking at building your ALM framework, consider an infrastructure and tooling that will help you establish and build customer value throughout the lifecycle.

In "Agile ALM for Delivering Customer Value: Getting Started,” I introduced an integrated agile ALM framework that includes traditional ALM, value chain, and agile methods. These elements, when combined, establish an innovative and powerful agile ALM framework focusing on delivering customer value. They also introduce some of the front-end disciplines of a lifecycle that can help you establish and maintain this effective ALM framework. In part 2, we'll explore the back-end disciplines of a lifecycle that establishes an effective ALM framework centering on customer value.

Defect Tracking: Being Aware of What Bugs You, and Ensuring Value has Quality
Oftentimes we incorporate defect work as part of the sprint. Because of this, we need the ability to take bundles of defects and include them in the sprint if needed. This is more relevant to products that are beyond Release 1.0 since not only will teams be building new functionality, they will need to triage defects during the release.   

We also need the ability to differentiate between the defects associated with the current sprint, past sprints, and past releases. An effective agile ALM solution will allow us to integrate stories from a backlog with defects, using a defect tracking tool for a singular sprint backlog. An even better solution would be for us to use a backlog management tool that is also a defect tracking tool.  

IDE: Establishing a Work Area from Which to Build the Product Value More Effectively
An ALM framework should include an easy-to-use integrated development environment (IDE) for the users. This IDE should be integrated with several version control tools, unit tests, compilers, continuous integration, and build management tools. In other words, don’t be constrained to one tool; work in an environment that can plug in various tools within an IDE framework. You should establish and build the architecture framework from within the IDE or integrated with the IDE. Let’s explore the key integrations from the IDE user interface.

Version Control: Identifying and Keeping Control of the Customer Value Work and Associated Deliverables  
A version control system must be able to manage any type of element—e.g., code, documents, test scripts, executable, and more. These elements are the assets that must be managed. Whether the version control system is one tool or a collection of storage repositories, it should be accessible from one common user interface. This eliminates the need for multiple screens and commands to access the elements.

Since the assets are so important to delivering customer value, the version control system must be continuously backed up with tested disaster recovery processes with quick turn-around time for recovery. The interface may be part of the IDE, and it must be integrated with the continuous integration and build management system, so that what is built comes directly from a location of known integrity

Continuous Integration and Build Management: Building Customer Value Early and Often
One of the advantages of continuous integration is that we continuously see the tangible evidence of customer value (e.g., the functionality or product). This implies that we regularly merge and build the product. The continuous integration and build system should be integrated with the version control system, which provides effective branching and merging functionality. This integration results in the ability to initiate merge and build upon check in to parent branch, provides minute reporting of what was merged and built¾whether successful or unsuccessful, and includes the ability to inform the agile planning tool and test environment of the successfully built stories.  

Customer Validation: Allowing Customers to Validate that We Are Building the Customer Value They Expect
The customer validation process ensures that we are building something the customer values. Being able to initiate virtual customer validation sessions, like an end-of-sprint review, to demonstrate current sprint functionality in the version control or testing environment benefits the agile ALM solution. This process should be integrated with the collaboration system and agile planning to provide feedback related to specific stories and sprint, and the feedback should be readily available for the next sprint planning session.  

Additionally, the customer validation process should have the ability to trace current sprint functionality to the code that built it—e.g., integration with version control system—and record an end-of sprint or demo session for view or reuse during additional customer validation sessions.       

Test (in an Automation Framework): Establishing a Work Area from Which to Test the Product Value
While a prioritized scope delivers customer value, we need to ensure that value is of high quality—this is where the test function is important. We need the ability to run and repeat functional tests, system tests, regression tests, performance tests, and load tests in as much of an automated framework as possible. In agile, automation helps reduce the manual testing that slows the team down. As you add automation, you should be able to highlight velocity and quality data in order to recognize improvements. Finally, it is important to tie the appropriate automated testing into the IDE, continuous integration, and build.  

Integration: Establishing Traceability of Value from the Vision to Customer Delivery
Did I mention integration? A key attribute of an effective ALM product for agile is the ability of the various functional areas or disciplines to be tightly integrated. Customer value is thought of every step of the way and is traced from the vision, to the story, to the working functionality. It involves identifying it, building it, verifying it, validating it, and securing the value. Of course, this is easier said than done, but after all, this is in an ideal agile ALM framework.

ALM Infrastructure “In-the-Clouds”
As mentioned, in the agile world, there is strong focus on customer value. It is ideal when the team spends as little time as possible establishing and maintaining an ALM infrastructure. Instead the team should attempt to use all of their resources spending the maximum time building customer value. Having an effective and reasonably integrated ALM infrastructure is a step in the right direction.

With the advent of cloud technology, you now have a choice of deploying tools locally (i.e., physically installing it) on premise or utilizing the web-based cloud infrastructure (i.e., software as a service or application service provider model). The former approach (on premise) ensures that you have total control over the technology and data, while the latter (in-the-clouds) ensures that you ramp up quickly and have the ability to scale as needed.

There are distinct advantages of using cloud infrastructure for those who are agile proponents. One advantage is that a cloud infrastructure provider enables a team to use only what they need, which is directly in line with agile. This “use-what-you-need” approach minimizes infrastructure debt and allows the product team to adjust and scale to its need in a “just-in-time” manner. Otherwise, you may have an ALM system that has low utilization.

Another advantage to renting the cloud infrastructure is that it helps you minimize capital expenses and lowers up-front costs, since you do not have to buy hardware, software, and other components. Essentially, the infrastructure—including servers, software, etc.—becomes more of an operating cost instead of a capital expenditure.

A final advantage is that the agile team does not have to establish and manage the infrastructure. You do not need to hire and manage IT staff for maintenance and upgrade work. However, it is important to have people on your staff who know how portable the hosted data is, and how easy (or challenging) it is to get it off the cloud should the service provider go out of business.

As you can see, having an ALM infrastructure in the clouds can further reduce the time spent by an agile team on tool support, because it reduces infrastructure and technology debt. The team only uses the amount of ALM tooling that it needs. Keep in mind that agile ALM in the clouds could be built by an external vendor or could be built or hosted internally within a company so that teams can take advantage of this common service and have more time to build customer value.  

The marriage of ALM within a value chain and agile framework can be a powerful combination. This integrated framework strongly emphasizes customer value and validation, using iterative and incremental steps to continuously build, validate, and adapt. This ALM framework allows a product team to manage and trace customer value throughout the lifecycle. Additionally, having this agile ALM “in the clouds”—whether externally or internally through a service provider—allows the team to almost totally focus on building business value. If your organization has adopted agile and you are looking at building your ALM framework, consider an infrastructure and tooling that will help you establish and build customer value throughout the lifecycle. 

See Part 1 of this two-part series at Agile ALM for Delivering Customer Value: Getting Started

Infrastructure—On-premises or in the Clouds, by Mario E. Moreira in the November 2009 edition of the “Agile Journal.”

About the author

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.