For a CEO the bottom line is always whether any new initiative will positively affect the business – increasing revenue or lowering costs. From that perspective there is frustration that agile has not delivered the promised benefits to the business.

Now IT teams are coming back to the business and telling them what they really need is DevOps – which for the CEO is just a way to spend even more to solve the same roadblocks they were promised agile would remove.

For many CEOs IT is perceived as slowing the business down rather than accelerating business agility. C-suite executives feel swindled by IT executives Agile/Scrum initiatives. Money was spent, markers and software were purchased, pigs and chickens as new job titles were coined – all to no avail.

All Agile achieved was to accelerate development and to move the bottlenecks of delivery to operations. Recent disruptive changes in the operations arena, e.g. configuration management, release automation, software as a service, virtualization and containers similarly burdened the balance sheet without delivering anticipated agility.

As a result we observe a spectrum of companies: on one extreme a typical enterprise that releases a new version once every several years (for legacy companies) or at best 2-3 times a year. On the other extreme Facebook delivers more than one release a day, Etsy delivers over 10 per day and GitHub delivers over a 100 releases a day.

Though everybody focuses on the tools, DevOps is really more about the process. Processes can be categorized through a maturity model which can be both descriptive and prescriptive. Maturity models are used to assess organizational capabilities and prescribe improvement steps – i.e. how to move up the maturity hierarchy.

Our maturity model defines a maturity hierarchy for Dev, a maturity hierarchy for Ops and joint layers where IT is subordinated to business priorities.

Only the synthesis of the silos can shift activities left, communicate business priorities to technical staff (beyond exposure to the product owner) and shrink the time from Aha to Ka-ching.

DevOps is a journey defined by a delivery maturity model used to assess an organization’s current delivery maturity and a high level roadmap. A maturity model  provides organizations with a way to assess their current delivery capabilities and a path from aha to ka-ching.

Here is our version of such a maturity model:

Screen Shot 2015-09-17 at 5.05.00 PM

Just Do It Level 1 (Dev: Sporadic delivery – Ops: Heroics): Deployment staff works around the clock to insure successful deployment. Myopically, each release is treated as a onetime sporadic effort. There are no specific application delivery objectives. Success depends on the competence and heroics of the people doing the delivery and not on the use of proven processes.

Doing by Design Level 2 (Dev: Continuous Integration – Ops: Planned) Ops design deployment processes based on lessons from level 1 that are standardized, often by spreadsheet (this is doing-by-design). Deployment status is managed and tracked. There may be partial automation through scripting or provisioning tools – using project management techniques.

Design by Doing Level 3 (Dev: Agile – Ops: Continuous Delivery): Ops automate best practice release processes based on proven release procedures (this is design-by-doing). They also establish appropriate reporting and tracking of release processes and artifacts. Automation exists at the release level, which is used for orchestrating and leveraging automation capabilities of level 2.

Value by Design Level 4 (DevOps: Integrated Continuous Deployment): Ops become an integral part of development methodologies (e.g. Agile development). End-to-end agile delivery processes integrate and orchestrate automation and lifecycle tools enabling Ops to deliver maximum value from product features. This enables continuous product delivery from development to production leveraging the automation of level 3.

Design by Value Level 5: (Continuous Value Delivery): Rigorous value understanding prescribes feature prioritization and version release. Release cycles are driven exclusively by business rationale, unconstrained by technical considerations. Product lifecycle is optimized by combining delivery insights provided by the agile delivery processes of level 4 together with strategic market data.