Imagine that you work as an IT manager, agile coach, senior developer, architect or other position where you need to demonstrate leadership skills and coordinate objectives with cross-functional teams in a large company. When I say big company, I mean a global enterprise with these characteristics:

  • More than 160,000 employees over the world
  • $32 Billion average revenue per quarter
  • Ranked #14 in Fortune 500 list
  • 150 offices around the world

A challenging new role

So, imagine that one day you are at your office working with your mates on some technical project. Suddenly, your boss asks you to talk privately, the kind of 1:1 session that scares us sometimes when we are not used to it. Your boss and you are in her office, a big room with black curtains, shadows everywhere and looking like Emperor Palatine’s command center room (ok I am overreacting, It must be an effect of the Star Wars movie). The boss asks if you like agile, and if you can see yourself involved in some team initiatives about it. She knows that you have experience and training in agile development. Because of this, she and the other bosses decided that you are a good fit to be new DevOps champion for the company.

You feel happy, because it sounds like a promotion or something good, but ask her what that means exactly. She says that now you are in charge of leading a transformation to DevOps ways of working in the entire company. Afterwards, your feel terrified, and with an uncomfortable silence from your end and a smile from her end, your boss says “Good, see you in the upcoming Town Hall meeting to learn the results”.

Despite your agile and DevOps knowledge, this challenge is remarkable due all the variables. Imagine how difficult it is to change the work practices of a team of five people. Now you need to be a change agent for the entire organization.

A recipe to help you get started

Not to worry, my IT friend. This article shares some lessons learned and good practices, or what we like to call “Ingredients”, to help you build adoption of DevOps ways of working in an enterprise. The best part is that those ingredients are already tested and executed in a huge organization with very good results. I can say that the good results were the consequence of a human-centric focus that was tool-agnostic. Note that the ingredients do not need to be applied in a specific order. And, you do not need to apply all of them. Instead, you have to analyze how you want to implement them depending on your business environment.


You will only get people engaged if they understand the purpose for what you are doing. This must be clear for you and everybody concerned, so you can work together in the same direction. The “why” needs to cover all aspects of the DevOps adoption, not only business goals, but also how DevOps practices will improve ways of working. The key goal with start with why is team alignment which is the best first step you can do for any ways of working adoption because it will enable and enforce the next steps of your strategy.

Ingredient #2: Where we are currently?

To achieve your goals, you need to know your initial status. Metrics, OKRs, process status, actual outcomes, quality, technical debt, automation percentage in different fields are some examples of how to get a baseline. Make these measurements transparent. Then, define how you are going to improve on the original status quo. For example, at the beginning, consider doing a DevOps maturity assessment (please remember that it is a good starting point and not absolute fact), so you can identify those pains that are affecting your team work and business.

However, you do the analysis, share this information with to all employees in the global organization. This helps create team awareness and a sense of urgency, so teams can decide next steps. For example, you need to know how you are doing in terms of the flow of your software development life cycle, from when work starts on a new feature to when it is released in production.  Fast feedback and continuous improvement are key success factors.

Ingredient #3: What are our priorities?

From the huge list of things to improve, you and your team of change agents need to work with your teams participating in the DevOps adoption and the strategic stakeholders (VPs, CEOs and so for, here it is important to align your priorities to company OKRs) to prioritize and decide your first goals and focus. There are several techniques for prioritization that you can use, like the “Buy a Feature” game. Make sure you involve the correct people for this exercise. You can also use techniques like story and impact mapping for this purpose.

Ingredient #4: Enabling DevOps ways of working based on your context

Here are some examples. Agile and DevOps ways of working adoption demand you cross functions efforts to support the different team needs. I mean, some teams will need more support about Agile mindset, others about CI, CD or Continuous Testing. Clearly, all this is not work for one super hero, especially if you are in an enterprise.

You need a team to focus on fostering adoption of DevOps ways of working. You will need help no matter if your company has 30 employees or more than 100,000. Like DevOps itself, adoption is a team sport. My main recommendation is creating a “DevOps Driving team” (DDT) whose members share your same goals and who already have a strong expertise in one or more DevOps pillars (CI, CD, etc.). This group of champions will lead the rest of the company, starting with our highest priority group, learn DevOps practices, establish a common operational efficiency objectives and strategy, and make it easy, simple and fun for the teams. They will also         keep pressure away from your teams and act as a kind of global Scrum master and coach.

Dojos, demos, Centers of Excellence, Academies, Community of Practices, Innovation events (like an Innovation day for the entire company or Innovative Feedback Day, if you like those ideas please let us know and we can share other article about those) are potential approaches those champions can use. 

We’ve had excellent results using gamification to get people engaged and improve their chances for successful change. The best example of this is designing tournaments to foster testing automation. I describe my these in Game of Testing approach in my previous post here. Fostering innovation must be a key part of your strategy.

Some final lessons learned

  • Start with only a few teams and involve them in the transition to DevOps
  • Start by introducing continuous integration and continuous testing
  • Measure before investing
  • Foster innovation
  • Less is more
  • Adopting DevOps ways of working is a team sport!

Our outcomes

After applying this strategy, here is what we achieved:

  • Initially only 50% of issues were being traced, that is, data was being gathered and tracked to see frequency of bugs and help with root cause analysis. We ended with the ability to trace 100%
  • Our time to market was reduced by 70%. We started with deploying to production every two weeks, and ended by doing daily production deployments

Gene Kim sums this approach up well: “Improving daily work is even more important than doing daily work”. No matter what hardware or software you have, whether you want a digital, agile or DevOps transformation — keep it simple and focus in daily work. These ingredients focus on changing “from the trenches.”