to complete, manage and store their work. Different teams manage code and changes in multiple, separate instances of repositories. Through release planning and tracking changes constantly, and the relevant data is housed in several different places.
In an Agile environment you need to have sound engineering practices and tooling because almost immediately, Agile exposes those areas that need greater attention. And how you deploy and structure your data will determine the accuracy and scale of your project. Because the process of shifting to Agile must have minimal negative impact on the organization’s ability to maintain its aggressive release schedules, trying to standardize and consolidate tools and repositories all at once in order to transition to Agile usually is not an option. It would be too disruptive. Yet, to succeed at a transformation and become a more effective organization, it is necessary to establish certain standards and identify ways to improve in some of the core areas of ALM.
The first step is to define standards for data descriptions – uniform definitions for different activities and assets across the organization. Use a single definition for goal stories, requirements, user stories, etc. This helps to make it easier for teams to understand each other’s work, and allow them to manage dependencies across teams. Next, use a standard management console for all of delivery projects. Stories, tasks, assets can be viewed and manipulated in it and all of the changes are reflected across the various tools. Hence, integration with existing systems becomes a much more important factor than replacement and consolidation of tools.
Planning in an Agile World
One fear that is common to organizations considering Agile is the perceived lack of planning in the approach. While the pace and fluidity of Agile may give the impression that the teams are driving forward with little regard for a long-term road map, the “flatness” of Agile teams – and the increased interaction between developers and business stakeholders/customers – actually makes it possible for teams to be more aware of business objectives and priorities than they might be in a traditional model.
To drive alignment between its Agile teams, marketing and product management organizations, and ensure that the work that is happening – sprint by sprint – enterprises need to link strategic goals directly to the ALM artifacts that are associated with them: requirements, user stories, tasks, and test cases. How does this work?
Marketing creates the overarching goal of a product release, defining and storing the high-level requirements in a requirements management system. Product management then breaks the requirements down into goal stories, and prioritizes these, along with any change requests, in a backlog. Teams then decompose the goal stories down into actionable pieces (user stories). The user stories are linked back to the goal stories and requirements. In planning their sprints, the teams estimate the size of the user stories and determine the content of a sprint based the team’s velocity (capacity) and the user stories priority (business value).
Then, as the teams complete user stories, the progress is being tracked and linked back to the high-level goal stories and requirements in requirements management system. At any time in the release, marketing or product management team has visibility into how the release is progressing in terms of which goal stories are completed, how much work is still outstanding, and how that work compares to remaining team velocity (capacity) for the release.
Agile managers must be able to quickly make informed decisions to keep planning on track. By gathering real-time status information from multiple sources – change requests, requirements, and test runs — management