The strong impact and attention that DevOps is having in IT organizations around the world, reminds me of other times when a similar movement or framework impacted the IT industry in a similar way.

For example, with ITIL (particularly V2), many organizations adopted it—many are still implementing it (now version 3)—and while many did actually achieve the expected benefits, for others, however, it has been a failed attempt. They have trained their staff, created a lot of documentation, implemented technological tools, perhaps even invested in consulting; but in the end, for a large number of companies the cost and effort has been higher than the benefits obtained, to the extent that even some CIOs say: “I don’t believe in frameworks”.  However, it’s not the framework per se what failed!—it is the way it was implemented.

The introduction of new guidance, such as DevOps, often gives IT executives hope of finally getting over struggles or pain points that have been affecting the organization for a long time, or at least achieving an improved state; but also brings uncertainty on whether that really is the needed solution or not. It is often hard to give credibility to “documented knowledge” that is relatively new and that there’s little context to demonstrate its effectiveness (different to the case of ITIL V3, which included revisions to V2 and added many best practices from organizations that implemented V2—hence its relative success). The approach the IT organization takes to that “new knowledge” is rather what makes the difference between success and failure. If the correct approach is not taken, the stakeholders’ commitment will start to decrease as they don’t see results, and the initiative will slowly die. A framework is not a magic wand or a secret formula that will make all the pains go away—there’s work that needs to be done, and done in the correct way.

Below are suggested guidelines that organizations can follow in order to have the correct approach to implementing DevOps, and increase the chances of the initiative’s success.

Get a realistic justification and set clear expectations for your DevOps program.

As discussed in the previous post, assessing and forecasting the ROI— including economic benefits, but also strategic benefits— will set the correct expectations in all the stakeholders, and will help getting people to commit with the initiative. Remember it’s not a matter of stakeholders being involved, but rather being committed.

Have a common organization-wide understanding of what DevOps is (and what it is not).

Everybody needs to be clear on what DevOps is, and how it is relevant to their role. The stakeholders who are not totally aware of the role they play with DevOps are the ones who will resist change. Train your team, get your people informed so that the next item is easier to achieve.

Get all relevant stakeholders’ buy-in and commitment to the initiative. 

DevOps is all about people, and it is enabled by people. If a person is not committed, that person will do little to support the DevOps initiative. Train your staff, and even consider certifying them! People will naturally react positively to something they own, because they will believe in it.

Have a plan for measuring progress.

Build a plan for achieving the expected value; define KPIs, SLAs, metrics and measurement methods and policies. Follow up on regular reviews and keep track of the benefits’ realization and performance of the initiative as a whole and from individual teams perspective.

Do not be discouraged – rather focus on continual improvement.

Change will not happen in one instant, not even in a matter of days. DevOps is about changing culture, which may take long periods of time. However, you can make this change more straightforward and less painful. Remember you are working with people, not with machines. Study the emotional cycle of change, and pay special attention to people’s emotions and reactions; that will be an indicator of the performance of your DevOps implementation. Build on small improvements and motivate people by demonstrating the benefits as they occur.

Walk the talk. 

Culture is set at the top of the organization and inside out. Do not expect that people below you (or above you) will make the change; start by changing yourself. Collaborate; communicate openly; be committed. Do not delegate the initiative to another team; own DevOps; enable it yourself.

Embed the new culture into your Corporate IT Governance practices.

Even it is not often presented as such, DevOps is all about discipline. Culture is defined by practices; as your practices evolve and become repetitive, your organizational culture starts to change. After doing something repetitively, then the result becomes consistent—that’s how best practices are born. Continue the efforts; have discipline; and then embed the new practices into your Governance framework so that everybody in the organization is naturally “infected” by the good behavior.

Are you and your IT staff prepared for a successful DevOps Implementation?