Thirteen years ago, I was shocked by an article describing the impossible: a startup called IMVU was releasing new versions of its software fifty times a day. The IMVU team didn't rely on manual checks or hours of unit tests, but tight monitoring of business metrics, with automatic rollback to the previous version if sales or logins dipped. It was as shocking to us as hearing about warp drive and routine day trips to Saturn would have been for Neil Armstrong.
You can bet I paid attention, and like many others, tried out these methods myself. And this style of hyper-rapid, risk-friendly, highly experimental engineering (part of Eric Ries's "lean startup" method) spread widely, and is in use in various forms today by many of my clients. For instance, a highly-regulated biotech firm with safety-critical software moved from six-monthly releases to two-weekly deployments, a move just as radical in their industry as IMVU's 50-a-day release cycle was in the world of SaaS in 2009.
So the mystery is, why aren't most teams running this fast, and what are they missing out on? For starters, a super-fast cycle time lets you:
Join me and others in my executive community to discuss the barriers, both real and imagined, to adopting hyper-fast cycle times—and learn how to inject speed and daring into your tech team to learn from customers faster than you thought possible.