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.
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.
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