Control and Trust

I’ve been thinking a lot about control and trust lately. Specifically, how control can be comforting, especially in large, politically charged environments. A lot of the changes made during an Agile transformation, and even more so when adopting DevOps, involve a loss of perceived control. And naturally, anyone thinking they are losing their control point is going to resist. I get asked a lot about how to navigate Agile transformations, and I always say that changing behavior patterns, and developing trust, is ultimately the part of transformations that take the longest and is a lot harder than process changing, tooling, or deciding what time your daily standups are going to be.

Henrik Knieberg, a former Agile coach with Spotify, used an analogy so good I wish I could claim it as my own.

A typical lighted intersection is a testament to a highly controlled, and trusted arrangement. The rules are well understood, traffic is stopped logically in one direction and allowed to pass in another. But when compared to a roundabout, it is revealed that a lighted intersection presents only the appearance of control. A typical lighted intersection contains 32 points of conflict for traffic, instances where one vehicle’s path crosses another. By contrast, while a roundabout lacks a clear command and control structure, it has only 8 points of conflict. And just like Agile, the roundabout results in faster throughput, with fewer incidents.

Undeniably a more elegant solution, roundabouts are still regularly protested when proposed. A couple of years ago, the city announced plans to install a roundabout near our neighborhood. These things were starting to pop up in the suburbs and exurbs nearby, so my wife and I didn’t think much of it. However, it turns out that some of our neighbors were so upset that the city ended up cancelling the project. Their concerns were borne out of a lack of trust in the solution. The city had done almost no outreach or education regarding the advantages. They hadn’t helped build trust, so the community resisted the loss of perceived control.

A lot of the controls in place in traditional enterprise IT shops are stop lights. ARBs, CRB, UAT, and other acronyms, can present unnecessary roadblocks to realizing the true value of Agile and DevOps. These traditional processes are too often implemented as chances to say “stop”, instead of accelerating. I’m not suggesting you shouldn’t manage the enterprise architecture, changes, or conduct user testing. However, too often each of these activities presents itself as a big red light that can cause weeks of delays in a project. A project running at two or even three week sprints simply can’t afford that kind of delay. To those that would dispute this, I would argue that they have to expand their trust in their technical teams. To them a highly mature Agile team may look out of control, but it’s not that mature Agile teams are any more out of control than a roundabout, it’s just that it’s unfamiliar…the trust isn’t there.

The challenge is to build a system of controls that can be trusted. The best way to build that trust is for leaders to see these processes in action. My advice to anyone starting this kind of transformation is to start small; choose a low risk project and find a sponsor willing to extend trust to your team. I have never seen Agile or DevOps initiatives abandoned if there is at least a small demonstration of its effectiveness or efficiency. Demonstrating elegant control in your Agile transformation will assist in building lasting trust within your organization.

John Longo

About John Longo