Building the DevOps Flywheel

The flywheel in engineering

What is a flywheel? It's essentially a weighted disc that rotates on a shaft. It is used in most car engines and in regenerative braking systems. The purpose of a flywheel boils down to 2 main functions:

• energy storage. A flywheel acts like a reservoir of rotational energy, absorbing excess energy during periods of high power and releasing it during periods of low power. This helps smooth out the flow of power in a system, preventing jerky or uneven operation. The stored energy can also be used to provide a quick burst of power when needed, delivering energy at a higher rate than the source.
• gyroscopic effect. A rapidly spinning flywheel provides remarkable stability and becomes resistant to change in its orientation in space. This is why it is used in navigation systems and other applications where maintaining orientation is crucial.

The flywheel in business

The flywheel effect in business has previously been described brilliantly by Jim Collins in his bestseller "Good to Great". However, he treats the flywheel as a black box. In this article we will take a look inside the black box by zooming in on the technical properties of a flywheel to use these properties as a detailed metaphor.

In business, the flywheel effect refers to the effort it takes to bring about a change. Every effort, every initiative contributes a little bit to getting the wheel going but, especially in the beginning, it seems like impossible work. Yet every effort is stored in the form of rotational momentum. And the wheel starts to turn. And continues to accelerate.

At some point, the wheel spins so fast that it can provide momentum for a power boost to weather unexpected challenges. To enable the business to bounce back from setbacks more easily. And very little energy is needed to keep the wheel going.

In addition, the gyroscopic effect occurs. The faster the flywheel spins, the more resistant it is to changes in its orientation. Even in difficult times, with fixed beliefs blocking the way, it enables an organisation to stay on course.

The flywheel in DevOps

When introducing DevOps in an organisation the flywheel effect is essential. Sometimes stakeholders (in the broadest sense) push hard, sometimes less hard, sometimes not at all, and sometimes they need the flywheel to get themselves going again. There are also forces at play that will try to slow down the wheel or reverse the change. That will work at first, but once the flywheel reaches a certain speed, it is almost impossible.

To increase the amount of kinetic energy in the wheel you need to know which components determine a flywheel's energy (E): wheel shape (k), mass (m), radius (r) and angular speed (??).

For a DevOps initiative the energy and its components translate as follows:

• E = kinetic energy. In DevOps it is the reservoir of motivation, skills, loyalty, advocacy and positive perception that propels IT and the business forward across different areas like multi-level communication, enterprise-wide collaboration and relentless improvement to enable - in random order - breaking down silo's, streamlined processes, faster deployment cycles, improved software quality, increased infrastructure efficiency, faster decision making, increased innovation and improved customer satisfaction.
• k = inertial constant. Depends on the shape of the flywheel. The wheel with the highest constant is loaded at rim like a bicycle wheel where lead is applied to the rim. In DevOps it is the extent to which value streams are correctly identified and the extent to which the organisation is implemented around these value streams.
• m = mass of the flywheel. In DevOps it is the number of training sessions and workshops. The number of participants who attended these sessions and the extent to which they are convinced that the DevOps path is faster, better and - eventually - cheaper than the existing path. And also the courage to structurally deviate from the existing path or depart from an entrenched position. This involves both employees and management.
• r = radius. In DevOps it is c-level support and corporate services support. DevOps transformation success is directly proportional to the level of support in an organisation. The further a DevOps transformation is advanced the more silos, departments and divisions are touched, the higher support is needed to establish collaboration and prevent relapse.
• ?? = Angular speed (omega). In DevOps it is team and team member commitment, management buy in and realised quick wins. Reduced organisational debt also belongs here as it can be seen as decrease in friction.

Both r (radius) and ?? (angular speed) count squared in the formula and need extra attention.

Translation of field experiences

The above translation is based on my experiences at a large number of organisations (business and government). In each organisation, I challenged participants in my DASA DevOps trainings and workshops to fill the three columns below with sticky notes. The left-hand column is for activities they can control themselves. The middle column is for prerequisites, the things that need to be taken care of first before they can start working on certain items from the backlog. And the right-hand column is for impediments, the blocks of concrete that are already in view and are unlikely to move, or will move with great difficulty.

Displaying the energy level

The effects of the total kinetic energy can be visualised by glancing at the position and movement of 4 key gauges as published by DORA :

• Change lead time - This metric measures the time it takes for a code commit or change to be successfully deployed to production. It reflects the efficiency of your delivery pipeline.
• Deployment frequency - This metric measures how often application changes are deployed to production. Higher deployment frequency indicates a more agile and responsive delivery process.
• Change fail percentage - This metric measures the percentage of deployments that cause failures in production, requiring hotfixes or rollbacks. A lower change failure rate indicates a more reliable delivery process.
• Failed deployment recovery time - This metric measures the time it takes to recover from a failed deployment. A lower recovery time indicates a more resilient and responsive system.

Feel free to scrutinise this article, pair the DevOps Flywheel formula components with your own experience and suggest improvements or additions.