Agile is no longer the new kid on the block. It has existed for over a decade, and many claim it has crossed the chasm. Numerous development organizations have already adopted agile practices or are in the process of doing so. The speed of adoption depends on the customers’ environment. In this article, I discuss how to practically adopt agile in an enterprise Application Lifecycle Management (ALM) environment.
Application lifecycle management (ALM) covers all practices or disciplines of software development, including requirements, specification, code, test, defect, and release management. Traditionally, organizations used ALM in following a more structured or plan-driven methodology for developing software. This includes waterfall, iterative, and the V-model. With the proven success of agile projects in organizations, the question now is how does ALM fit in the agile world? To address this question, I’ll describe some practical examples of how ALM fits with agile development methodologies and how organizations can adopt these changes.
Let’s first look at ALM in more detail. Each domain in ALM has a well-defined purpose. For example, in the requirements domain, high-level business requirements, such as features being requested by end customers, are captured. This is typically authored by a business analyst or product managers depending on the organizations. These requirements are then translated to use case diagrams or specifications by the engineering teams to illustrate, from a technical perspective, how the business requirements will be satisfied. Next, development assigns tasks so developers can write software code. In the testing phase, test cases are written to validate the specification and, hence, the tasks. If a defect is found, it is logged and assigned to a developer. This process continues until development and testing is complete and the product is ready for release. The main issue with following this approach with an iterative or plan-driven development methodology is that development starts months after the requirements are written. Comparing this to Agile, there are similarities except that Agile promotes shorter release cycles while involving business analysts and product managers throughout the process.
Agile adoption is developer driven in today’s organizations, Many development teams enjoy working in an agile environment because it promotes team collaboration, constant communication, and self-empowerment. In larger organizations, CTOs are now aware of agile practices and their potential benefits, but there are informational gaps between senior management and the development team. For example, senior management wants to know at a high level the project‘s timeline, budget, and risks. Development teams measure time via burndown charts, budget through resource allocation, and managing risks by means of impediments. To remove this informational gap, a metric translation layer needs to develop so CTOs and senior management can get status on agile projects similar to how they have in the past with waterfall projects. To achieve this, organizations must have tools and solutions in order to build these metrics and display them on management dashboards. This is especially important if senior management needs the status of projects using a variety of development processes, and, as in some organizations, projects that run the full gamut of traditional waterfall engineering to the most cutting-edge agile methods.
Regulatory compliance or standards mandate some enterprise customers to produce formal documentation of how they developed a certain product. In this case, requirements management is crucial and the main driver of “what” will be delivered. By far, Scrum is the most popular agile development methodology. Scrum is a simple framework. The figure below is a sample of Scrum’s architecture.
In Scrum, product owners manage their backlog of user stories (or something equivalent). Depending on the organization, user stories are then