When DevOps is Inflicted on Business

Photo by Pacheco

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.

Allison Pollard

I help people discover their agile instincts and develop their coaching abilities. As an agile coach with Improving in Dallas, I enjoy mentoring others to become great Scrum Masters, coaching managers to grow teams that deliver amazing results, and fostering communities that provide sustainability for agile transformations. In my experience, applying agile methods improves delivery, strengthens relationships, and builds trust between business and IT. A big believer in the power of community-based learning, I grew the DFW Scrum user group significantly over the five years I served as an organizer. I am also a Certified Professional Co-Active Coach, a foodie, and proud glasses wearer.