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.
Figure 1
In Scrum, product owners manage their backlog of user stories (or something equivalent). Depending on the organization, user stories are then put into a release backlog or directly into a sprint backlog. Once in the sprint, the teams break the user stories into tasks during their sprint planning meeting and start working on them. A sprint (or iteration) is typically one to four weeks in duration. There are daily stand-up meetings during which team members can bring up any impediments to progress.
Yet Scrum fails to scale in an enterprise environment primarily because it doesn’t explicitly address formal requirements and test management. This is crucial in companies developing products in heavily-regulated industries such as the medical device, automotive, and aerospace industries. This is where ALM fits in as it coordinates all activities of the lifecycle as well as providing visibility. Achieving regulatory compliance in software development is only possible if the organizations link the various domains and have visibility into them. Figure 2 below shows one way of how organizations can link requirements and tests to their agile development framework. By tracing and/or decomposing requirements into user stories in the backlog, both stakeholders (internal or external) and agile teams get the traceability and visibility into which requirements are satisfying what features.
Figure 2
Similarly, by linking test cases to user stories, QA managers and testers can write formal test cases that can be repeated from one sprint or release to another. Following Scrum principles, the goal of a sprint is to deliver working software. Thus, QA analysts and testers can write functional test cases at the sprint level and unit test cases at the user story level. Integration and system tests can be written and linked at the release level for organizations with multiple teams working on a given release. Figure 3 depicts this analogy.
Figure 3
Now that we have seen examples of pragmatic agile ALM in the enterprise, the question becomes how can organizations adopt this or something similar to fit their needs. The first approach is to re-interpret the current development environment in agile methods. Implementing a new development methodology in a large enterprise will not happen overnight because the implementation increases risk and disrupts development. Also, change is not necessary if a well-defined framework, such as the V-Model, is already in place It is simpler to incorporate agile practices and values within the existing framework of the organization. Risk management and quality are two things that cannot be compromised in any environment. Special care needs to be taken when incorporating agile into these areas. Boehm and Turner published a book called Balancing Agility and Discipline, A Guide for the Perplexed, in which they illustrate the differences and similarities between agile and plan-driven methods. They also explain that the best development strategies combine both attributes.
Adapting agile to the existing development environment is the second approach. Most engineering and development standards in the industry don’t explicitly state which software development methodology should be used. Rather, they identify the process and activities such a model must incorporate. You should make use of the CMMI-dev process model to identify where additional rigor or a hybrid mix of traditional and agile practices can fully address development standards. The article entitled, “CMMI or Agile: Why Not Embrace Both!” Hillel Glazer, J. Dalton, D. Anderson, M. Konrad & S. Shrum, SEI Technical Note CMU/SEI-2008-TN-003, found on the Software Engineering Institute website provides an excellent description of adapting Agile to CMMI. It is essential to use an ALM tool that provides traceability and reviews capability across the development environment in order to ensure consistent processes and practices as well as to automate traceability and documentation generation.
In conclusion, Agile has often been accused of not being scalable to large development teams and environments and that it does not provide visibility into development and project management. It also does not rely as heavily on documentation making it difficult to demonstrate compliance to regulations and standards. However, engineering and development companies are applying agile more frequently than before, even in heavily regulated industries in which organizations must meet stringent development and engineering standards. Applying ALM concepts and tools enables organizations to take the best practices of Agile and incorporate artifacts and documents to create a hybrid approach so they can still achieve regulatory and standard compliance and ensure efficient communication and collaboration across their development environment.
About the Author
Harsh Sabikhi is a Customer Solutions Engineer at MKS Inc. where he works in helping enterprise companies solve their most critical business issues. He is involved during the entire sales cycle, from discovery to deployment, thereby being the main technical point of contact for the customer enabling him to improve sales effectiveness and customer engagement efficiencies. Harsh also provides product management input for product strategy and roadmaps. He is a certified ScrumMaster and a leading expert of the MKS Agile solution, which helps organizations manage their software development using the Scrum framework. Since this solution is based on the core Integrity platform, Harsh knows how to relate upfront business requirements downstream to agile artifacts and to test management.
