The road to DevOps failure is often paved with good intentions in the form of well-meaning advice that just doesn’t work. It’s the advice that sounds good in theory; in fact, it may even be advice that is hard to argue, like “silos are bad” and “automation is good.” But when put into practice, it simply falls short on delivering the outcomes DevOps teams want.
Unintentionally bad advice could shoulder part of the blame in organizations that are struggling to scale their DevOps practices. The 2018 State of DevOps report noted that many teams that have been at DevOps for eight or nine years still feel like they are at the beginning of their journey.
[ Some people get confused about Agile vs. DevOps. We break it down: Read Agile vs. DevOps: What’s the difference? ]
Let’s turn some common DevOps wisdom on its head – per the advice of DevOps practitioners and experts. It might just be the catalyst your team needs to get to the next phase of your DevOps journey.
1. Don’t break down silos – bridge them
Dominica DeGrandis, director, digital transformation, Tasktop: “The DevOps community consistently barks about breaking down silos. There are good reasons to believe silos are problematic. Stories abound of development and operations teams who are in direct conflict with each other. Often the problems begin when teams are unaware of mutually critical information and unable to consider the perspectives and needs of other groups.
“Silos occur naturally and evolve over time based on human need. Small cohesive groups of aligned people trust each other and move fast. There will always be silos. Attempting to break them down or remove them doesn’t appear to be the solution.
“Instead, we need to bridge silos. Recognize that team A’s priority is different than team B’s. Focus on communication debt from conflicting priorities and unknown dependencies. Help people on other teams anticipate what’s headed their way and provide visibility on risk from a high-level perspective.”
2. Worry less about tools, more about people and process
Eran Kinsbruner, global technical evangelist, Perfecto: “Many people think that choosing (or adopting) the right tools can help mature their DevOps implementations. However, it’s not nearly enough; it takes far more than having the right technologies in place to take DevOps from zero to 100. Teams are often overlooking two other major components – the people they’re working with and the processes they currently have in place. All three – the tools, people, and processes – are likely to be in a different stage of maturity throughout the DevOps journey. The only way to succeed is to ensure they are working together, in an automated fashion, with proper fit to team members’ skills.”
3. Lead time is not the most important DevOps metric
Dr. Mik Kersten, CEO and founder, Tasktop: “The most problematic common wisdom of DevOps that I continue to come across is the assumption that lead time can be tracked by measuring cycle time. Both concepts arise from lean manufacturing. Lead time is the end-to-end time from customer order to delivery – for example, how long it takes you to get your new car. Cycle time is the measurement of each key step along the way of you getting that car – for example, one particular part of the assembly line process. All of the cycle times add up to make the lead time.
“Many DevOps thought leaders have rightly pointed out the importance of measuring lead time for your transformation. In car production, lead time has been attributed with being the No.1 metric corresponding to car company performance. However, no car manufacturer would ever mistake measuring the cycle time for one step of the manufacturing process as sufficient for understanding delivery. Yet that is the exact mistake that everyone who measures ‘code commit to code deploy’ and calls that lead time is making. When you do that, you have no idea if you are optimizing the right part of the value stream, as you are only looking at one small segment of it.
“I first encountered an antidote to this problem in Dominica DeGrandis’ book, ‘Making Work Visible: Exposing Time Theft to Optimize Work & Flow.’ It is so significant that DeGrandis suggested a new metric called flow time, which has become the most important metric described in my book, ‘Project to Product.’ While a balanced set of metrics is needed, in my view, understanding the difference between lead time, flow time, and cycle time a critical first step in tracking your DevOps transformation.”
[ Read our related article: DevOps metrics: Are you measuring what matters? ]
4. You don’t have to automate all testing
Jonathan Fries, VP engineering and digital transformation, Exadel: “While automated testing is certainly the wave of the future and QA skills will focus on automation, great manual testers can still add significant value – especially those that understand the details of how an application works (which is typically developed by testing and working with an application over time). Expect that some blend of skills will be key to success – like the ability to test and understand an application, to automate some testing processes, to work with technical tools like Postman, and to provide a full picture of an application’s health.
“There are also many legacy applications for which test automation may be challenging or impractical. Finding ways to leverage the capabilities of your existing QA staff, teaching them to understand QA automation, and using platforms that enable them to leverage their expertise is something that we see as a significant counter-trend in 2019.”
