The remarkable thing about 2014 is how every CTO and CIO seem to have finally gotten the memo that agility in software development and operations is not a buzz or a fad, but a direct and immediate threat to the survival - their own and their company's. A report after report from various consulting and analyst firms places agility and reduced cycle times on new software releases somewhere between #1 and top-10 of CIO priorities for 2014. In 2013, it didn't make a top-100 list.
My favorite report comes from the National Retail Foundation dated February 2014 and opens with "CIOs can summarize both their priorities and their challenges in one word: agility.": https://nrf.com/news/online/cio-priorities
As I spend my days talking to people who are chartered with making their organizations more innovative and agile, it continues to dawn on me just how complex is their mission and how confusing is the modern landscape of concepts, technologies and jargons.
Those who speak of continuous delivery usually just got a basic CI infrastructure barely working. Those who own a "private cloud" still require an IT ticket and weeks of delays, approvals, negotiations, and new hardware acquisition to give the developer his requested test sandbox. Those who proudly claim to run agile development often continue to ship new features in the giant releases coming months apart.
I believe we stand on a relatively firm ground with respect to two points:
The desire to practice "continuous innovation", where the applications, features and content is being shaped and formed by the customer needs and wants, facilitated by a short development cycle measured in days and a direct feedback loop tracked by the analytics tools.
The ability to establish "continuous integration" practices which are by now relatively well understood at a single team level, leaving continuous cross-team integration out of scope.
Everything in between is a foggy mystery. I read somewhere once that there are problems and there are mysteries. We know how to solve a problem with sufficient time and resources. Mysteries cannot be solved until we understand them well enough to turn them into problems. I like this framework. Team-level continuous integration is a problem. Enterprise-wide continuous innovation is a mystery.
Somewhere in between is Continuous Delivery. Amazon, Google and Facebook are awesome innovators largely because of their speed and agility. Amazon is known to deploy 3,000 live production changes per day. Here is a pretty good thread that highlights some of Amazon's amazing capabilities: https://news.ycombinator.com/item?id=2971521.
While I know of many consumer-oriented companies that have been able to achieve twice-a-week release cadence, continuous micro-releases remain a distant dream for most enterprises.
To help turn a mystery into a problem, I offer this frame of reference:
While the quest ends with continuous innovation, the starting point of the journey has to be continuous integration, followed by continuous delivery. Each delivers tremendous value to the organization and provides a compelling ROI in its own right.
If a company can agree on a roadmap, it can focus its attention - in business terms, budget and priorities - on the right immediate targets and lift the fog sufficiently to start building a coherent set of capabilities aligned with specific incremental business returns.
Founder and CEO of Qubell. Founder and executive chair at Grid Dynamics. Working hard to turn good ideas into great products.