When the Agile Manifesto was signed, software mostly shipped in shrinkwrap. Deployment rarely needed to be solved – it usually involved a single machine with an approved maintenance window. In many cases, operational best practice mostly meant restarting misbehaving machines or processes, which often solved the problem.
Now we've reached a point where perpetual availability is a near necessity, and we take for granted that services will always be available. The practices that provide that reliability evolved with incredible pressure to deliver faster, at greater scale, with zero service disruption.
While delivering software has evolved, I constantly encounter efforts to perfect and enforce adoption of practices derived from a context that doesn’t necessarily exist – and maybe never did. The explanations sound more like superstition than science.
[ Why do so many organizations struggle with transformation? Andrew Clay Shafer will discuss how to avoid pitfalls during the upcoming virtual event, “Putting Digital Transformation into Practice.” Register here. ]
This appears especially true in enterprise organizations trying earnestly to evolve their digital capabilities, and most pernicious once there has been considerable investment in certificates of mastery in a prevailing doctrine.
Ironically, few things may be harder to improve than an enterprise convinced they are now “big A Agile.”
A simple solution to a complex problem is always a new complex problem. Often the organizational focus ends up lamenting the perfection of their process rather than their technology failures, despite evidence that process was a problem. This vicious cycle takes a toll on everyone involved, but especially the most aware and talented people who could potentially help the most. They give up hope (or hope to leave).
I have experienced five major categories of transformation failure: leadership, product, development, architecture, and operations. What started as a conversational explanation of these failure patterns has evolved into a framework to discuss organizational capabilities, risks and remediations.
Let's explore how failure happens in each of these competencies:
- Leadership: Failure happens when entrenched ways of working are at odds with good outcomes. There is no organizational environment to do the right thing.
- Product: Failure happens when there are no strategic requirements to build the right thing. Building software that doesn’t matter is a costly mistake.
- Development: Failure happens when development doesn’t adhere to the fidelity of the requirements, missing the relevant combination of technical and communication skills to deliver software that hits the mark.
- Architecture: Failure in architecture makes flexibility, reliability, scalability and security difficult, if not impossible. Even if you build the right software, with the right features, a bad architecture will always limit you.
- Operations: Failure in operations means you are not keeping the right things properly running in the face of internal and external change. This causes the socio-technical system to struggle with incidents that impact the organizational mission.
Each of these failures can be reframed as an opportunity to build a competence, but the real power comes when we start to look at how the elements interact to reinforce or undermine each other.
What appears to be an acute problem is really a web of interdependent strengths and weaknesses. Ongoing outages may seem like a failure of operations but development and architecture always contribute to the failure and limit the possibility of improvement. Failures delivering strategic features can be a product weakness, but can also be caused by weakness in the communication with development or even operational resistance due a lack of automated governance.
Every organization that delivers software possesses a level of these competencies. By outlining the elements and their connections, we get new insights about the causes of organizational struggle, the language to communicate factors contributing to the struggles, and suggestions for how to address each competency and the dependent connections.
These elements offer a starting point for taking an honest look at organizational capabilities hindering efforts to deliver technology outcomes. Just thinking about these five elements can help identify where to focus on removing constraints. Building the full model is beyond the scope of this article but putting some focus on finding and addressing failures affords a greater chance of avoiding them. My team is working on metrics for assessing organizational capabilities with Five Elements and designing actions to make progress.
If you are not getting good results, stop chasing Agile, DevOps, or SRE or whatever the next buzzword happens to be and start looking at your specific strengths and weaknesses.
[ Read also: Agile vs. DevOps: What’s the difference? ]
