DevOps lessons learned: What I wish I knew sooner

Source – enterprisersproject.com

The DevOps movement is nearing its 10^th anniversary. A lot has changed since 2009, the year of the first major DevOps conference led by Patrick Debois (now known as the Father of DevOps). Today, DevOps practitioners and enthusiasts are no longer the “lone wolves” at their organizations. DevOps skills are in increasingly high demand as organizations realize that digital transformation requires the speed, agility, and efficiency that come with DevOps.

Since DevOps Engineer ranked second in GlassDoor’s 10 Best Jobs in America for 2018, many IT people have taken notice and made moves to transition to a DevOps career. But there are some things you can’t learn in an online course or book. Some of the best DevOps lessons, in fact, are the result of hindsight.

We asked DevOps veterans to pay it forward to the next generation of DevOps talent. They each shared one thing they know now that they wish they would have known at the beginning of their DevOps journeys. If you are just getting started in DevOps, or trying to take your DevOps game to the next level, read on and take heed of the valuable, hard-earned lessons.

1. Beware of “them and us” mentality

Fin Goulding, international CIO, Aviva:  “Without a shadow of a doubt, I underestimated the cultural challenges of implementing DevOps. The fusion of two ‘tribes’ into one sounds easy on paper: But the reality is very different and it takes quite some time to remove the ‘them and us’ mentality in order to have developers and engineers working side by side delivering value. I wish I had spent more time coaching individuals rather than just implementing the model across all the technical teams at once. In fact, it would have been best to start in a small way with a ‘lighthouse’ implementation before going for full roll-out.”

2. C-suite alignment is not optional

Ben Grinnell, managing director, North Highland: “I would have liked to have understood the breadth of the changes needed to have a sustainable impact and the impact required across many of the typical C-suite functional areas. When we started out we were typically working with IT leaders (CIOs, CTOs or CDOs) trying to improve flow, feedback, and continuous improvement between development and operations functions. Often that solution wasn’t sustainable and didn’t deliver the benefits anticipated due to the problems elsewhere in the value stream, which gradually pulled the transformed Dev and Ops functions back to working in the old way.

The changes we applied were flashes of brilliance giving an illusion of progress. This type of change is easily attacked by the corporate antibodies that destroy anything foreign. In order to stop this effect, you need to change the DNA of the organization. 
I would have still started in the same way, as the need to start small, learn, and grow is still critical. But now, I invest more time in getting C-suite alignment, so we can expand the changes from Dev and Ops to the front line, procurement, budget setting, financial governance, security, audit etc.
 I’ve also learned the hard way that influencing and trying to maintain alignment across the impacted members of the C-suite is difficult and progress is about four times faster if you can get CEO sponsorship.”

3. When in doubt, have a mitigation plan

Eran Kinsbruner, director, author, lead software evangelist, Perfecto: “Looking back, I wish I knew the importance of planning the DevOps pipeline to accommodate for changes. Along each iteration, changes are constantly being introduced, whether it’s a change to requirements, a change in backlog features, or other interruptions around quality (escaped defects, customer reported issues, etc.). Having a mitigation plan ahead of the end of journey can make the difference between business success and failure. To have such mitigation plans, strategic decisions need to happen, proper tools need to be in place, and guidelines need to be followed throughout the development and testing. These pillars require management buy-in and support.

Consider this: When iOS11 on iPhone X was introduced in November, (some) enterprises failed to meet the launch days of the device and suffered from quality issues. Had they been on top of market changes, introducing the device in the CI as part of the daily regressions, they would have been able to better identify the issues and respond quickly.”

4. Outcomes define success

Mirco Hering, APAC DevOps and agile lead, Accenture: “I wish I’d have known from the beginning that technology is not the only solution; success is defined by the outcome, not the way to get there. I, like so many, was initially focused on ‘how to become DevOps’ rather than using the ever-increasing tool belt of DevOps practices and tools to achieve business outcomes. As technologists, we are sometimes too focused on the next shiny object. If I had learned this lesson earlier in my career I think I would have avoided some of the more spectacular failures of projects that implemented a technology but still did not achieve success.”