conclusion that product releases, like new cars or new widgets for the holiday season, must be coordinated and integrated on a fixed, inviolate schedule - a release train - where dates are fixed, themes are fixed, and quality is fixed.
If all the above are fixed,functionality must then be variable but the software train must leave the station on time. Mastering the skill can be a challenge for the enterprise, but once in place, the enterprise can leverage the ability of teams to create to create smaller and more frequent releases with an ability to coordinate those releases to create substantive market or customer impact.
4. Tooling the agile enterprise . Smaller component teams that require little coordination with other teams may require little tooling. Larger teams require relatively more tooling and at the enterprise level, a more systematic approach is required. Enterprise-level tooling must support the 7x24 multi-site communication and integration challenges present in larger and distributed organizations. This challenging communication environment needs shared, program-wide visibility into priorities, real-time status and signaling, dependencies and "blocks" for tight coordination across geographies and time zones. Teams must have access to networks and Internet-based tools that enable shared repositories for agile project management, shared requirements, source code management, common integrated build environment, change management and automated testing.
5. Changing the Organization. Agile methods drive substantial change in the organization. In addition to the challenge of rolling out agile methods across hundreds and thousands of developers, the team's constant search for improvements will readily identify organizational roadblocks, bottlenecks and impediments that limit productivity. These may include impediments such as insufficient resources for testing automation and system-level testing, slow and cumbersome interfaces to product management and/or customers that prevent rapid feedback on iterations and progress, and more. Sponsoring executives must be willing to provide the training and support necessary as well as be ready to foster the necessary changes at the organization level.
6. Impact on customers and distribution . While it is easy to say "smaller and more frequent releases," it is not so easy to do. And, even when the local teams accomplish this feat, the enterprise's job is not yet complete. The availability of more code-more quickly will affect the end user community and those who interface to it. This may require more intense coordination and closer communication as to the actual progress towards the release train objectives. For example, for those enterprises who sell software to others, sales and marketing teams are key stakeholders of the delivery process. Those teams will also have opinions about the delivery challenges and incorporating their input and assuring their involvement in more rapid delivery is essential to achieving optimal results.
7. Measuring business performance . At the team level, agile project measurements are relatively straightforward. Thankfully, the existence of actual working code on a more frequent basi s is the primary measure of productivity and all other measures are secondary. And yet with most enterprises, this fact alone will not necessarily meet the need for additional, company-wide performance measurements. In that case, performance measures must also be built to help the executives understand where they are in their goal of continuing improvement and where additional improvements need to be made.
Fortunately, agile is very measurable and measurements such as "% stories completed per iteration" and "feature or customer value points delivered" are easy to capture at the team level. Aggregating these measures across teams, departments and business units and combining them with other revenue, cost or productivity measures can give the enterprise the tools it needs to assess and improve its overall business performance