When DevOps is Inflicted on Business
Photo by Pacheco
Most organizations I visit have accrued technical debt and genuinely want to improve their technologies to better serve their business and their customers. The challenge is: how? Architectural and infrastructure improvements may be needed, new practices and skills may be required, and it’s hard to see where to fit in these efforts with business requests. Oftentimes IT projects and technical stories manifest. In many cases, transparency of development efforts decreases when this happens and leads to greater conflict with business stakeholders. Teams can feel caught in the middle as managers try to provide “air cover.” The use of a war-related metaphor here feels not-so-great.
Transparency is one of the early benefits of an agile approach; it is evident in the Focusing Value zone of the Agile Fluency model and enables organizations to better collaborate and save costs as they focus on business results. When IT chooses to invest more heavily in improving technology and the way they work to reduce defects and increase productivity, it can look like a slowdown. Teams may spend time on things that business folks don’t fully understand; their effort increases as they introduce new tooling, make architectural improvements, and adopt new practices. The development costs of new features can skyrocket. Good IT managers help insulate their teams from undue pressures to deliver and meet timelines—pressures that can cause teams to abandon improvement efforts. Great managers recognize the additional challenges being placed on product management and partner with business to keep focusing on value and learn to ship more frequently to customers.
Scrum describes the Product Owner as responsible for “optimizing the value of the work the Development Team performs.” When the effort of a feature is significantly increased by technical improvements, the Product Owner’s job becomes harder. And their role was already difficult! I’ve seen tensions shift and conflict become more productive when organizations learn to look at the product more. Looking at the product more means looking at status reports or release plans less—graphs and words miss the full truth and make it harder for us to find alternative ways to deliver value sooner. Inspecting the product (or the Increment, for Scrum aficionados) generates conversations about customer benefits and value; teams learn more about what customer problems may need to be solved and can think of new ways of doing so. A stronger understanding of value can be the key to a team figuring out how to deploy multiple times a week—or even a day! System resiliency can increase as a team learns more about potential risks. Plans to release to production are adapted as real conversations about the current state of the product unfold.
Investing in adopting DevOps or making technical improvements doesn’t have to be at odds with focusing on business results. Inspect the product, not the status reports or release charts. Build on the transparency and collaboration of agile methods.
