Cost of DevOps Culture Transformation — Did DevOps Break Trade Off of QCD?
Did DevOps Broke Trade Off of QCD?
A paradigm shift happened in the Japanese software industry after Developer Summit 2020. “Quality and Speed” presented by t_wada changed the perspective of software development in Japan. This presentation claimed that the traditional QCD is no longer viable in the software industry. The presentation is mainly based on the DORA research, which was started in 2014 and has been updated annually since then. People get interested in DORA research which proof the elite performers, which full utilizes DevOps culture, release new features at a significantly faster rate while minimizing the failure. This finding contradicts the conventional assumption: prioritizing speed will lead to lower quality. Many DevOps practices are based on automation. This means that speed and quality can be achieved at the same time, while costs are reduced also. This implies DevOps breaks the traditional QCD trade-off.
In fact, I have come to believe that the QCD trade-off in software development is no longer valid. Based on the belief, I have been promoting the DevOps transformation on my projects for the past several years. However, I have learned along the way is that this is not that easy than I originally thought. Fostering DevOps culture was quite tough for me. In other words, fostering the DevOps culture itself is “the cost” of QCD, and the cost is pretty big.
Cost of DevOps Transformation
There are three main reasons why fostering a DevOps culture is so hard.
First, it is difficult to understand what DevOps is at a first place. I would recommend you to ask this question to your colleagues. “What is DevOps?” Most of them will either talk about superficial mechanisms such as CI/CD, or give you a very unclear answer. In fact, there is no universal definition of DevOps. So you can get a good idea of their level of understanding and their own perspective based on their answers. My answer is “DevOps is a set of practices and culture that integrate software development and operations in order to be able to release new features daily basis while minimizing failures and defects”. I still don’t know if this is the exact right answer, but that is my perspective.
Second, DevOps has the nature of poison. Professor Kusunoki, who is the author of Competitive Strategy as a Narrative Story, shows that good strategies have the nature of poison (expressed as “killer pass” in original Japanese book but I write different way as it has different implication). Some animals contain poison inside. It kills enemies but won’t hurt themselves. This protects the animal. Just like the poison, competitors cannot partially copy their strategy since the strategy is integrated with other element, and copying the strategy without the element can work even negatively. DevOps have the nature of “the poison”.
Let’s assume that you start frequent releases without well integrated CI/CD. The team will be swamped with release workload, and ends up with suffering from many bugs and frequent production failures. Next, let’s assume that the team does not understand the importance of unit testing and relies on third-party E2E/UI testing. If the team just promotes test automation while not rebalancing the test pyramid, even a small change ends up with frequent modifications of high maintenance Selenium test cases. It may even less efficient than manual testing.
Third, DevOps requires the understanding from the top to the bottom. Let’s assume that the head of IT management has an old-fashioned software development paradigm. They won’t understand you at all if you say “Let’s release every day so that we can reduce the risk of each release.” Once a critical failure occurs, they will reduce the frequency of releases, and build a heavy change management process with lots of checklists. This will leads opposite direction to DevOps culture. Let’s assume in case the top management is the supporter of DevOps transformation but the developers do not understand the importance of developer driven testing. The automated testing, one of the critical practice of DevOps, will not be improved. This would leads the enter DevOps transformation failed.
Enterprises which are Hard to Initiate DevOps Transformation
These challenges are especially difficult for enterprises that are driving digital transformation. Unlike digital native companies, these companies are so much getting used to buying IT systems from vendors instead of building by their own. And the vendor-based software development is the exact opposite of DevOps practices. They are pushing strict change managements, minimizing the number of major releases into every six months, and hiring a large number of test vendors to perform manual testing after the software development is complete. Making such a change in organizational culture will be epic challenge.
DevOps transformation is challenging as I described. It sounds great that we can achieve the quality and the speed at a same time. However, there is a huge cost to changing the culture behind it. And the cost of cultural transformation is not something that we can estimate by business cases, or achieved by the investment decision by top executives. The only way to change the culture is, consistent, tough demonstration by DevOps practitioners and advocates.
Many management science show that corporate culture is the most difficult competency to copy. Therefore, companies with the competency would have a strong advantage. I believe that the key to promoting DevOps is to recognize the cost of change, and keep paying that cost with persistence by DevOps practitioners and advocates.
