Many DevOps transformations fail because organizations approach them with the wrong attitude—and because they don't understand what they should be trying to achieve.
Get rid of your DevOps delusions and adjust your expectations, and you'll 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 deploys 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 need to spend time double-checking their work. They make 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'll have people scurrying around more.
Some key benefits of a DevOps culture come from the lean movement. By building incrementally, you'll 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 says 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's 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 isn't just a matter of reviewing the process twice a year or every quarter. Continuous improvement is a cultural shift that says everyone 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 it is to hope for a miracle.
[ Also see: 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.
For more on avoiding common DevOps mistakes, come to my foundational course, "Foundations of DevOps—ICAgile Certification," at the STAREAST software testing conference, April 28–May 3 in Orlando, Florida. I will also be speaking on "Virtualization and Containers for Automating Web Testing." TechBeacon readers can save $200 on registration fees by using promo code SECM.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
