This content is syndicated from Jim Highsmith by Jim Highsmith. To view the original post in full, click here.

Flickr deploys software changes multiple times per day—and advertises this on their web site. A medical software company deploys versions of their application software over 75 times per year. Salesforce.com has gained competitive advantage with their highly automated continuous integration, testing and deployment of new software features. All of these companies, and a rapidly growing cadre of others, are reaping the benefits of speeding value to their customers. 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.

Leave a Reply

What is 1 + 10 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”