Enterprise DevOps Strategy: Where to Start

You may have heard of DevOps. You may even be familiar with what it is. But the teams under you may not understand how to implement it successfully. This is normal, as DevOps is a set of newer ideas. Therefore, you must train your teams and transform them to execute a great DevOps strategy. However, it can seem daunting to get the ball rolling. No worries, because developing a strong DevOps strategy is feasible. In this post, I’ll be laying out a potential DevOps strategy that can give you a chance to transform your part of the organization.

The Roadmap

The way to implementing a DevOps strategy in your organization is similar to the way you may want to implement most new initiatives. The spin here is that DevOps comes loaded with built-in feedback mechanisms by its very nature. You can instantly recognize a DevOps team space from its myriad of monitoring and deployment dashboards, build monitors, and other such measuring tools. More on that later. Here’s the roadmap we’ll follow for our DevOps strategy:

1. Do your homework.
2. Find or become the executive sponsor.
3. Form or find a team to execute.
4. Prepare the team.
5. Form a leadership coalition.
6. Convert at least two other teams.
7. Send them out.

The intent of this roadmap is to thin-slice a prototype team, then replicate the efforts across a portfolio while learning from each team’s efforts. Trying to do a big bang initiative across the organization, though tempting for a large consultancy to pitch to you, will likely end up in failure. This is because your organization has unique traits and we need to try out some things at a small scale, learn from them, and make improvements as we move forward. A big bang initiative doesn’t give you this feedback loop.

While we cover this roadmap, I’ll also share a war story of how my employer helped one of our clients through a DevOps transformation.

1. Do Your Homework

Before embarking on this endeavor, you’ll face quite a few risks that exist if you have no basic knowledge of DevOps:

• Subordinates making political moves may try to set up inaccurate narratives.
• You may not know which DevOps metrics coming from your prototype team are useful and which aren’t. Or you may not understand what the metrics indicate.
•  If you hire outside help or consultation, you should be able to sniff out earnest effort and good work toward DevOps vs. a sales pitch that crumbles upon further inspection.
• You may need to remove some initial obstacles in your organization before you even spin up or convert your first team.

To mitigate these risks, ensure you have a basic understanding of DevOps concepts:

• Intent of DevOps
• Continuous delivery and deployment
• Automated testing, like the test pyramid
• Observability; how to gain insight into a running system
• Monitoring and logging
• Lean principles, such as WIP and lead time
• Value streams
• The low cost of cloud infrastructure
• Deployment strategies, such as Canary release
• The fallacies of distributed computing

Invest in learning these topics. You can get basic knowledge of many of these by spending a couple hours scouring blogs about each topic. You can also establish a pretty strong knowledge base by attending a course on them.

My firm set up our executive sponsor for success by running a workshop on how we would deliver their software. This helped the sponsor to know what to expect in advance and what to look out for. We also set up a cadence where we would continually inform them what we were trying to achieve and why.

2. Find or Become the Executive Sponsor

Now that you’ve done your homework, you’re in a place where you can support your DevOps strategy. Ensure that you have the capacity to commit to sponsoring this initiative. If you can’t, find someone you trust that’s interested in DevOps. Have them do their homework. Then have them sponsor the initiative. Lend them your full support.

The sponsor will be responsible for the following things:

• Removing organizational obstacles to the initial teams. You may have to bend or change organizational policies as these teams will be trying some new things. Support them in this. They’re doing the best they can.
• Reviewing team metrics, such as customer usage and uptime.
• Coaching your subordinate leaders, such as your middle managers, to be supportive leaders instead of command-givers.
• Making your intent clear to the teams and your subordinates. Explain why you feel this DevOps initiative is so important and what part they play in it. If you make this clear, they’ll own it more fully.
• Ensuring the initial teams have capacity carved out to invest in this initiative. If you say “let’s do DevOps, but I still have this pile of business features that have to get done” then you won’t get a DevOps team. Since this initiative is new, their feature delivery will be slower at first. This is an investment. You’re taking capacity out of short-term feature gain in order to invest in long-term customer satisfaction and operational excellence.
• Having a consistent cadence with your subordinate leaders to understand the team’s metrics and support the above items.

When we began to implement the DevOps transformation for our client, our executive consultant sought out and formed relationships with the executive leadership of the team. We knew they were interested in this transformation; they even commissioned some space to be renovated for it but did not fully know how to execute it. When made the above expectations clear to the main executive stakeholder, they embraced these as a mission.

3. Form or Find a Team to Execute

Your or the sponsor’s next step is to find or form the first software delivery team. You only need one to start. Again, you’re thin-slicing your way through this transformation. Here are some characteristics of a good prototype team:

• It should have as much end-to-end ownership of a software capability as possible, from the database to screen.
• You want hungry, curious people. Willingness to grow and learn will be better than pure experience.
• Ideally, you want a team that will be implementing a new capability, as opposed to an existing team entrenched in tradition. It’s harder to unlearn than it is to learn.

Working with our executive sponsor, our team found a small loan-paying app that they wanted to revamp. They loaned us a couple of devs from their side, and we brought in some experienced developers, a technical lead, and a product manager to ensure success. The client dropped them into a small conference room.

4. Prepare the Team

Once you find or create your team, you must equip them so that you can give them the autonomy to carry out the initiative. If you give them too much freedom but don’t train them, you’ll get chaos and may give up. If you train them but don’t give them freedom, you’ll get a frustrated team with low retention and almost no results.

The same principles for doing the homework also apply here. Pay for them to attend a course. Have them seek out some blogs or some books. You can even hire consultants in the field. Since you did your homework, you’ll have a chance at knowing whether or not the consultants are worth your time. Consultants are expensive, but give a high chance of success if you hire the right ones.

Once my firm landed in their new team space, we brought in people experienced with testing, metrics, and continuous delivery. We smothered the walls with platitudes and tips on healthy DevOps practices. Also, we provisioned some big monitors to be brought in so that it would be clear what we were doing and measuring. We ensured leadership carved out 20% of their time to invest in operational focus, delivery pipelines, and eliminating technical debt.

5. Form a Leadership Coalition

Now, we need to ensure that the team has a smooth path forward. Set up a regular cadence to meet with your subordinate leadership chain from the team on up. Ensure they’re being supportive and not dictatorial. Track blockers and find ways to remove them. Get that team what they need! This will pay dividends.

This was a key step my firm performed to ensure transformative success. We had leadership from multiple levels meet, including the executive sponsor, every few weeks. We validated that the vision was clear to everyone and discussed what blocks existed for them to remove. The team’s ongoing success built trust with the leadership continuing to support them and remove obstacles.

6. Convert at Least Two Other Teams

Once things are running smoothly, after about two months or so, you can think about how to replicate the process. Share in your coalition what worked well for the team and what can be improved. The former members will now be a basis for starting two or more teams. Try to ensure at least half of the new teams have members from the original team and work in new members. Rinse and repeat: prepare them, monitor them, then split again. The closer the teams are in their portfolios, the better. For example, if you have a blogging team, perhaps target a marketing software team next.

My firm’s team was able to put something into production within six weeks. We quickly set up deployment pipelines with automated tests. The team could show on their monitors their service usage, giving a nice feedback loop. We even exposed a problem with the portfolio’s test data that was holding the team back. With this in place and the renovations done, we were able to move into a larger space. We spun up two more teams to handle the portfolio’s billing and payment capabilities. We brought in more experts from the firm to replicate the process from the first team. And the new teams had less red tape to cut through because of what we learned.

7. Send Them Out

Eventually, you’ll have a critical mass of teams working with a DevOps mindset. You’ll be able to see this by walking into their space and seeing the various operational metrics on large monitors. They’ll be able to tell you their uptime and service usage without blinking. Deployments will be commonplace. The teams should be vibrant.

At this point, you want to pool some members together to start roadshowing. Run presentations, lunch and learns, or other teaching events. Show other portfolios what you’ve done. They’ll have impressive metrics you can show off and will likely blow the minds of many of your peers. This is your final investment that’ll pay off as you get other leaders excited to implement their own DevOps strategy.

Once my firm had about four teams going with DevOps, we broadened our horizons across different portfolios with the client. Our executive sponsor warmly introduced us to new potential sponsors. We would bring them by to tour the team space or show them the metrics these teams had produced. One time we had the CIO come down and showed them a physical button they could press to deploy the system into production.

Walk the Road

The DevOps strategy of thin-slicing your organization gives you a higher than normal chance for success. Hit hard with strong-executing teams. Back them up with the executive leadership on a regular cadence. Train them, invest in them, and these teams will pay dividends. Unlike many softer initiatives, investing your teams in DevOps gives easy ways to get feedback. Your teams will spin up for your feedback loops of operational and business metrics as part of their journey. This will give you insight into their progress and success, pushing forward and pulling out as needed. All that’s left is for you to go out and make it happen.