5 mistakes that doom a DevOps transformation from the start

Many DevOps transformations fail because organizations approach them with the wrong attitude—and because they don’t understand what they should thrive to achieve.

Once you get rid of your DevOps delusions and adjust your expectations, you will have a much smoother experience. You’ll deliver value more readily, and you’ll make everyone in the organization happy that you went through the pain of transformation.

These five key mistakes will doom DevOps initiatives from the start. Are you making any of them?

1. Focusing too much on the tools and the automation

Automation is an essential part of DevOps, and it’s the part that most people want to focus on first. New tools, such as Docker and Chef, are fun to play with. Everything starts going faster once you add automated deployments or containers. It is easy to see improvements right away. Cool things happen.

But keep in mind that the tools are just enablers. Automation and tools are important to DevOps because they free people to focus on the things that computers can’t easily evaluate.

Tools provide feedback so people can make informed decisions. They help processes occur repeatedly and reliably so that people don’t have to spend time double-checking their work. They make the management and maintenance of software more flexible.

The value of the tools lies in what they allow people to achieve. Deploying software into the cloud on Docker containers doesn’t have any inherent value on its own. The value comes from the results of using Docker—what it allows you to do instead of manually deploying the software.

Takeaway: Don’t focus on implementing the tools. Focus on how the tools help you achieve your goals.

[Special Coverage: STAREAST Conference 2019]

2. Trying to go faster to deliver more value

“DevOps will make our business faster—won’t it?” Probably, but not because you will have people scurrying around more.

Some key benefits of a DevOps culture come from a lean movement. By building incrementally, you will have products delivered more frequently. By eliminating waste from your delivery process, you’ll spend less time on steps that add no value to the product.

Those are good—really good. But they aren’t the best part.

Lean means that you should break up your work into manageable chunks. Those can be delivered piecemeal so that something is always moving through the process. Best case, you can deliver your work to the next step just in time for someone else to pick it up. No one is waiting for work to arrive, and no work is sitting around waiting to be picked up. That is just-in-time delivery.

When you deliver the product at the end of the process, you have a minimum of wasted time. On top of that, if you need to re-prioritize or change the process, you can do so immediately with nothing half-done or in-flight. That allows you to deliver at an optimum speed and still maintain business agility.

Takeaway: Delivering more frequently is more about agility than speed.

3. Not continuously improving

The delivery pipeline in DevOps consists of feedback loops that allow you to inspect, reflect, and decide if you are still doing the right things in the right way. As you get better and smarter and learn more, you’ll see ways to improve, to optimize, to cut out steps that are not providing value. Often those improvements require some investment and extra effort to implement.

If you don’t take the time to fix the pipeline when you see the ways to improve, you are just investing in a wasteful process. You are doing the process for the sake of the process, not to add the maximum value to what you are delivering. The sooner you improve, the sooner you reap the benefits of that improvement.

It’s not just a matter of reviewing the process twice a year or every quarter. Continuous improvement is a cultural shift that requires everyone to should get better all the time. Every time you go through the process, you get a little better and learn a little more.

As you make the easy improvements and clear that waste away, you start seeing new opportunities to improve—things that weren’t obvious behind the old inefficiencies, or new steps you can try now that you aren’t wasting time by doing things the hard way.

Takeaway: If your team is saying, “We’ll do better next time; now we just need to hurry,” you know they’re not continuously improving.

[Related: 7 steps to choosing the right DevOps tools]

4. Not being honest about your progress

Day 1: “I’m about 50% done.” Day 2: “I’m at like 90%.” Day 3: “99%. So close.” Day 4: “I just ran into one last problem. Just about done.” Day 5: “I almost have it. One more day should do it.”

And so on, and so on, until finally: “I know that took up almost all our time, but as long as everything goes perfectly from here on out, we should make up for lost time and catch right back up.”

Longer schedules usually compound this scenario, because longer estimates are more likely to be more wrong. You have more opportunities to be unreasonably optimistic. All of that leads to disappointment and loss of trust that your team can deliver what and when it said it would.

Whether you are talking about building features or changing processes, be realistic. Again, break the work into small enough pieces that you can be confident about your estimates. If something comes up and the team is delayed, don’t expect that a lucky streak will help you catch up, especially when history suggests that it won’t.

Takeaway: Being honest about progress helps everyone set their expectations and plan accordingly. If the schedule starts slipping, it is easier to make adjustments earlier than to hope for a miracle.

[See also: Fast estimation: A better approach to agile estimation]

5. Assuming that change is easy

Working differently is hard. Thinking differently is even harder. People are comfortable falling into familiar patterns, especially when things get tough. It just feels easier.

But you can’t improve without changing. Things won’t get better if you keep doing things the same way. Even when you make wrong choices, you are learning and growing.

And eventually, the newer, better ways of working will become the familiar pattern that you fall back on. Your successes will lead to more willingness to change, but there will always be some inertia you must overcome.

Takeaway: Don’t expect everything to be an immediate success, and don’t expect everyone to change right away. Change takes time and effort, but it pays off.

Reset your expectations

DevOps isn’t a panacea for a broken organization. It’s not about a new set of tools and procedures that magically make development and operations smoother. You can’t buy a DevOps solution off the shelf.

And it’s not easy. You are changing the way you build software. But set your expectations realistically, and you will see the value in adopting DevOps.

Planning to formulate a DevOps transformation for your company product? FABA is glad to help. You can leave us a message and get your free consultation here.