Right around this time of the year, the gym starts to get a little less crowded. Throughout January, it’s packed to the gills with folks freshly motivated by their New Year’s resolutions to get in shape. But by mid-February, the commitment seems to have all but dissipated.
Why is it so hard to just commit?
During my last workout, it occurred to me that the set of vacant treadmills next to mine was eerily reminiscent of the state of enterprise DevOps. According to Forrester, . It seems commitment and follow-through are difficult in both personal and professional arenas. Admittedly, adopting and scaling DevOps is no easy feat. While reflecting on what does work, I found some parallels between the transformation process and DevOps itself.
What Success Looks Like
According to ,” organizations with the highest level of DevOps execution, as measured by throughput and stability, also achieved the highest level of business performance in terms of profitability, market share and customer satisfaction. In a true case of going fast without breaking things, elite performers realized impressive performance gains:
- 46 times more frequent deployments (throughput)
- 2,555 times shorter lead times (throughput)
- 7 times lower change failure rate (stability)
- 2,604 times shorter time to recovery (stability)
These metrics underlie a key tenet of DevOps transformation, which is breaking up large chunks of work into many small pieces.
Shrinking the Change
Smaller changes mean getting work out faster, with less risk. They take less time to plan, less effort to execute and are easier to troubleshoot. But, smaller code changes alone aren’t meaningful unless they are coupled with shorter release cycles. In essence, agile without CD doesn’t work.
Stockpiling a few months worth of agile code iterations into a single monolithic release reintroduces an enormous amount of risk and negates much of the work done to adopt agile software development in the first place. Big queued-up releases often mean someone is stuck working the weekend to iron out all of the things that inevitably go wrong and no one should be stuck with weekend release duty. , “The most important metric for continuous delivery is the number of person hours spent outside of business hours doing releases… and the goal for that is zero.”
In practice, CD is what brings agile development to fruition; it’s why Gartner finds that . CD is all about small pieces. In the same way agile enables smaller code changes, CD enables smaller releases.
Not Just Smaller, but Iterative
At GitLab we use the phrase, “” as a shorthand for continuous delivery and deployment. The idea is that when you have a completely automated CI/CD pipeline, all a developer needs to do is commit code to their branch, and everything else needed to get that code running live in a production-like environment—from containerization to security testing—is automated. Similarly, getting code to production is as easy as merging the feature branch back into trunk with the entire production deployment automated. The message to the developer is, “.” This is CD in a nutshell.
With this type of automation in place, the cost of making a change significantly decreases. This means the cost of getting started is very low, but so is the cost to keep going. Instead of spending a massive effort to map an entire path to your solution, you simply need to figure out your next step and keep iterating. According to GitLab’s “2018 Global Developer Report,” . By shrinking the change, business leaders will find it easier to set direction for the next step without having to map the entire path. This brings us back to digital transformation.
Commit to Digital Transformation
Just like a monolith being decomposed into microservices, the practice of breaking large chunks into small pieces applies to driving digital transformation as well. Like , “When eating an elephant, take one bite at a time.”
How can enterprises shrink the change?
For most organizations that achieve successful digital transformation, the initiative usually starts with a single team or innovation unit. This group proves the success for the rest of the organization. It develops that culture, tools and processes that other parts of the organization can then adopt. One example of this principle in practice is the . When Chris came on board, only three build engineers had the ability to release to production and it took four to six weeks to complete each release. Chris gradually scaled a CI/CD platform, step-by-step over two years, until every team across the organization was able to complete a release in less than 30 minutes. Today, the Jaguar Land Rover completes 50 to 70 deployments per day. This iterative pattern is seen over and over again with enterprise digital transformation. It’s encouraging because it means successful digital transformation can be driven by either or .
Keep the Fuel Burning
According to Argyle, “” This seems to align with Forrester’s metrics on half of the organizations that stall.
So, how can organizations keep going and avoid the stall out?
If I can make a confession, I am also one of those New Year’s resolution makers who just started working out in January. How it is that I’m still hitting the gym while others have dropped off? I have found that taking a “DevOps” approach is a key to my success. Instead of broad sweeping changes, I make small incremental improvements one day at a time.
It turns out the strategy for getting started—“just commit”—is the same strategy to keep going.
By starting small with a single project and gradually expanding scope in iterative steps, an organization can continue to improve over time at a rapid pace. Small, single-commit code changes coupled with CD increase throughput and stability. In the same way, small, incremental process improvements bring about the greatest success with digital transformation.
