The public attention for DevOps is having a very positive effect on many areas of IT with regard to improving their ability to deliver for the business. Yet, I see little attention being paid to an integral part of this desire to change, which is to assess and baseline the current approach and then strategically select those areas where attention needs to be paid. Alternatively stated, many DevOps efforts are focused on improving current approaches without even determining if the current approach is appropriate for the business.
In their book, “The Lean Mindset: Ask the Right Questions,” the authors question the focus on productivity as an aspect of implementing lean or agile methods. This comes up quite often in discussion with customers regarding DevOps adoption. There’s a misconception that becoming more productive is the way to fulfill demand from the business. But productivity is not the right question or answer. Regardless how you approach the problem domain lack of infinite resources—money, time and people—the demand will typically exceed the ability to fulfill.
The way for IT to help the business achieve agility is to deliver the right set of features at the right time, which means the first step has to be looking at what you’re doing today and being willing to stop spending time and effort where there is minimal value or gain. The authors of “The Lean Mindset” have some interesting anecdotes around the realities surrounding this in enterprise settings.
- Politics – one company decided to financially incent development management to deliver agreed upon features on a behind schedule project even though it meant that testing would suffer and the final product would be unreliable. When later asked if they could have reduced the feature set and delivered fewer high-quality features, the team stated that it could have been done as less than 50% of the features were being used in the final deliverable anyway. The politics of delivering what was agreed upon was more important than delivering fewer high-quality features.
- Can’t Say No! – many IT executives find it difficult to push back on the business and, hence, end up attempting to deliver all that is already on their plate plus new requests that arise during the year. In many cases, much of what is already on their plate is no longer needed or provides minimal value to the business. Without a system of measurement around cost to deliver versus value delivered, IT cannot justify to the business the need to shift resources elsewhere to ensure optimal value.
For these reasons, among others, any attempt at DevOps needs to start with an understanding for where resources are being applied today and where they should be applied in the future. Doing useless stuff faster doesn’t help IT and it doesn’t help the business. It’s also why IT/Business alignment is a critical part of any DevOps adoption strategy. IT needs to work with the business in an open manner to select the most important features, capabilities, systems, etc. that will deliver value for the business. This also means IT is responsible for instituting the necessary systems to measure resource consumption and provide the business with the necessary data for them to make intelligent choices about where they want to spend their IT capital.
There’s a great Peter Drucker quote in the book, “There is nothing quite so useless as doing with great efficiency something that should not be done at all.” So, if your IT Operations team spends six weeks automating deployment for a system that really should have been sunset, that’s six weeks lost that could have been better spent on a more business critical function. Of note, this is not the IT Operations’ fault. If that system is not going to be sunset and has been the bane of their existence consuming time due to outages, then they have driven improvement. The failure is on IT management and the business having not taken the necessary steps to allow these resources to be focused on more important initiatives once again illustrating the importance of executive sponsorship for DevOps initiatives prior to tooling, automation, process improvement or organizational shifts.
