Transformational change in organizations requires a razor focus on a future state that must draw leaders and employees out of their current world to embrace a different focus. Creating this pull to change involves fundamentally shifting how individuals understand their value and purpose, and in practice, this can be incredibly disorienting and look high-risk. However, the highest risk comes from continuing the same pattern and entrenching dysfunction.

An Agile transformation is intended to build new business capabilities- to get things done faster, to improve product quality, to reduce risk, to improve predictability, and to improve productivity. Yet, many Agile transformations lack any plan for measuring success. Executives supporting Agile transformation programs often become frustrated with this lack of meaningful metrics. Meanwhile, practitioners debate the relevancy of metrics, often from a silo rather than an end-to-end perspective. Months into the transformation, executives wonder whether the program even merits continued funding. They struggle to pull together data after-the-fact. Because they didn’t have baseline measurements from the start of the transformation, it is hard to demonstrate progress. Often, any data that is freely available becomes the metric of focus.

Principia - meaning “collection of Principles” was first used by Isaac Newton in 1687 (one of the great heroes of the Enlightenment) as the title for his treatise on fundamental mathematics and physics¹

Principia - meaning “collection of principles” was first used by Sir Isaac Newton in 1687 (one of the great heroes of the Enlightenment) as the title for his treatise on fundamental mathematics and physics.

Before we Start – a Quick Preamble

This blog may be viewed as a little controversial by some within the Agile community. However, my intent is simply to challenge some of the established norms, and maybe in doing so, rattle the proverbial cage a little. At the end of the day, and in the spirit of experimentation, this piece is meant to be a playful exploration of alternatives to the status quo. Hopefully, this will lead to a fresh perspective and stimulate some new dialogue on a somewhat stale subject - Process.

Millennials. The generation of lazy, narcissistic, self-righteous, participation trophy-toters. As one of those very Millennials, I can attest to the bad rep that we have. Gen X co-workers don’t know how to work with us, and our Baby Boomer bosses struggle to understand how to connect with us. We realize there’s often a disconnect between the generations in the workplace, so I’d like to help shed some light on what we need in order to thrive.

Let’s say you’re a consultant. You just started a new project working for a fantastic client, and you love your role. Even though your employment situation is ideal, you still need some help. It’s late on a Friday night, and you have a problem. You think about calling your recruiter, but it’s outside of business hours. You’re tired, stressed, and unsure where to turn. Sometimes things go wrong, and that’s where our Consultant Advocate Program comes in.

 Companies looking to get the benefits of a DevOps mindset often get stuck in the trap of focusing on buying the "best" tool and implementing "best" practices.¹ Tools are chosen with very little, if any, collaboration with developers, testers, or operations staff. "Best" practices are determined by committees, again based on scant practical organization experience. While there are benefits to standardization, premature standardization, or standardization with no room for experimentation leads to stagnation and poor overall performance. And what works today will be unlikely to work as well in the future. The pace of change and innovation in DevOps means new opportunities for improvement are arising regularly.

As Bob Fischer points out in a recent blog post, Technical Debt is a Business Problem, “technical debt is rarely understood by non-technical business people.” So the question is: How do you go about having a productive conversation that enables non-technical people to appreciate the need to actively and continually keep technical debt low?

My solution is simple: keep it visual.

It is common for companies to stall or slow in their quest to improve speed, quality, reliability, or security through a DevOps approach.  It is not technology that slows them down, but their culture.  They have practices and beliefs that make some aspects of DevOps seem impossible:

“Sure, developers at small start-up XYZ can put their own code into production, but we're in a regulated industry, and it would never work.”

“We need separation of duties. What you’re suggesting is impossible.”

“Audit or compliance would never allow a developer to test code.”

In this blog post, we’ve focused on separation of duties.  Separation of duties is an important concept and to some, it might seem to be incompatible with a DevOps approach, but it isn’t. In fact, in many cases the separation of duties in the context of DevOps offers more assurance of quality, security, and audit-ability than traditional approaches.

As an organization goes through an Agile Transformation, one of the roles that is most impacted by the transition is middle management. One day you are managing a team or large department, and the next you find yourself without anyone to “manage”. Instead, your department’s members are now members of Agile teams who self-organize and whose work is no longer under your direct control. This can be a very unnerving experience for middle managers and leave many wondering what their role is now in this brave new world.

It must be bought into. But just what are organizations buying into?¹

For me, the goal is to be able to answer “yes” to this question:

Can we confidently and reliably deploy and operate software at any time to meet the needs of the business?

A mentor of mine from twenty years ago recently asked: "Can Agile commit to long term commitments needed by executives to run their business?"  I answered with conviction that it certainly can, but when I went on to explain, I realized the answer is fairly complex. To simplify, if you prefer managing with data, you will love agile.

DevOps is often misunderstood as simply tools and process, and that's part of the story but misses the mark. DevOps is really about building greater cross-organizational teamwork. Teamwork that ultimately enables speedier time-to-market, higher quality, and more rapid learning. Traditionally, this isn't how people work. It wasn't how I worked when I was a functional manager. I was focused on my individual part of the puzzle being great, not on what really mattered to our customers or the organization. A big production outage provided a great catalyst for me to rethink how I worked. It wasn’t pretty, but it was very instructive.

The familiar expression ‘the whole enchilada’ implies that one should look at the whole situation, the whole picture rather than just focusing on the individual components of the metaphorical enchilada. Whether it is Mexican food or life, the whole is ideally greater than the sum of its parts.  

Technical debt, one of the key drivers of slow delivery, is rarely understood by non-technical business people. Even rarer are companies who have a strategy for investing in its reduction, which has been jointly agreed to by both business and technology groups. Debt is viewed as a problem for technology to address, not a systemic issue. Unfortunately, this leads to longer cycle times, higher costs, and lengthy time-to-market. The DevOps focus on continuous improvement is displaced by behavior that leads to continuous worsening. For companies to improve, the reduction of technical debt must be understood and addressed as a systemic issue.