Speed-To-Value

Achieving speed-to-value reaches far beyond the early Agile focus on development speed. In the early 1990’s I worked on a project at a large NYC bank. We managed to build a new application in 6 weeks (using 1 week iterations). The customer was ecstatic, operations not so much. After much negotiating, ops agreed to deploy our new application—one the client really wanted quickly—in 6 months.

Speed-to-value embodies two key concepts—speed and value. “Value” means that we are constantly evaluating—at a portfolio, project, capability (epic), feature and story level—the value we are delivering to customers. That means everything from calculating the ROI of projects to determining the relative (or monetary) value of features. Then on a release, milestone, and iteration level we constantly prioritizing and adjusting scope based on value and cost.

The Agile mantra has always been to deliver value early and often, but we have not always pushed that to the limits of actual deployment and customer solutions. The reasons are more organizational than technical (although there have been significant technical advancements).

The organizational issue are both product lifecycle and business customer oriented. Although delivery teams have become Agile, marketing, product management, or internal business departments have sometimes been reluctant to change their traditional modes of operation. I know of product organizations that have completely changed their perspective—from demanding commitment to features a year in advance, to accepting the flexibility that Agile development allows—and profiting from that responsiveness to customers.

Similarly, at the back end of the lifecycle, development and operations are working closely on smooth transitions from development complete to deployment complete. Value is only realized when features are deployed, not when they are ready for deployment. Speed-to-value should be measured across the entire lifecycle, from placment on a portfolio backlog to actual deployment.

However, an even more difficult change may be getting business departments to think through how they can use frequent deployments to their advantage—and then changing business processes to accommodate them. They will also need to decide how to articulate the benefits of these frequent deployments to their customers. For some business departments daily deployments of new features may have significant consequences whereas for others it may not. Finding the right schedule of deployments for different groups means business departments will need to become more Agile themselves.

These organizational Agile transformations are often much more difficult than implementing Agile practices and principles in the engineering department. However, the benefits can be extraordinary. As enterprises learn to be more adaptive, agile, flexible, or dexterous, the potential for competitive advantage multiplies rapidly.