What it means to build quality software has taken a beating over the years. We’re no longer content to strive for defect-free code. We must also make sure the software meets both its functional and nonfunctional requirements. Only now with the rise of more Agile ways of thinking, we’ve placed the notion of a software requirement under the microscope, as building flexible, resilient software often trumps checking off items on our requirements list.
As a result, the tried and true Project Management Iron Triangle has taken its lumps. We’ve been trying to bend or rework the Iron Triangle for years, with limited success. Today, thanks to DevOps and Agile Architecture, we finally can.
Adding Corners to the Iron Triangle
You remember the Iron Triangle: vertices at scope, cost, and time. Any project might fix two, but the third must be allowed to vary. Inadvertently fix all three? Then quality suffers – an unacceptable result.
The Iron Triangle
We’ve tried adding quality to the triangle over the years to let us fix the other three constraints, turning it into the Project Diamond, but that move was a rather academic exercise. After all, you can’t go to your boss and say “we delivered on all the requirements on time and on budget, but sorry, it just doesn’t work!” People insisted on taking quality as a given, and lived with the triangle as-is.
Other additions to the triangle: The Project Management Body of Knowledge (PMBOK) added risk to the triangle – helping to expand it to a six-pointed star. Risk, however, is more than a project constraint, as there are many types of risk. In addition to the risk of violating any individual constraint, there are also systemic risks like opening a security hole or violating a regulation. Adding risk, therefore, muddies the purpose of the triangle.
The Agile world also contributed a variation of the triangle with Jim Highsmith’s Agile Triangle. Highsmith collapsed all the constraints into a single vertex, and differentiated value from quality to populate the other two corners. Quality, according to Highsmith, represents the current quality of the project while value represents “future quality – ‘can the product continue to deliver value in the future?’,” according to Highsmith. He explains: “responding to the unanticipated future requires adaptability, and the key to adaptability is keeping technical debt low.” In other words, software value depends upon its adaptability, and adaptability depends upon lowering technical debt.
Highsmith makes some important points, but by collapsing the traditional Iron Triangle constraints, he doesn’t provide a clear explanation for how to balance quality, value, scope, cost, and time – and now with added implicit constraints of adaptability and technical debt, the resulting model isn’t all that useful. There is also widespread confusion about the challenges of both inherent flexibility and “good” technical debt (be sure to read my discussion of technical debt, if you haven’t already).
Remember that Hightower ties inherent flexibility to value – a critical connection for any Agilist to remember. However, he inadequately addresses the connection between adaptability and technical debt, jumping to the conclusion that keeping technical debt low is always a good thing. In fact, careful and temporary acquisition of technical debt, just like the careful borrowing of money that generated the metaphor – is in reality an essential part of Agile development.
In my 2013 book The Agile Architecture Revolution, I took a different, but similar approach to extending the Iron Triangle by adding agility to the mix as an explicit constraint, turning the triangle into the Agile Architecture (AA) Quality Star below.
The Agile Architecture Quality Star
In the figure above, the traditional Iron Triangle continues to represent the scope/cost/time tradeoff, while an additional triangle – the agility/quality/time Best Effort Triangle – represents a separate tradeoff: the more time you devote to quality, the less agile you become. The point to the AA Quality Star is to elevate agility to the status of a metarequirement and thus a constraint to the project, which in turn requires us to rethink how we deal with quality when agility is a priority.
Beyond The Agile Architecture Quality Star
While Highsmith’s value constraint and my agility constraint both recognize that the ability for software to be inherently flexible – that is, the ability to respond to future requirements as well as current ones – is an important added constraint to any software that claims to be Agile, neither of us fully explored the fact that inherent flexibility and resilience are actually two separate constraints. Inherent flexibility supports an organization’s desire to be more innovative and responsive, which are two of the three elements of business agility. The third element is resilience: the ability to recover from adverse events.
In the past, we typically took a brute force approach to building resilience into our software by hammering on it until it passed its performance tests and then hoping it wouldn’t break in production. Today, however, we have a deeper understanding of resilience, as cloud computing has forced us to rethink how we deal with failure. It’s no longer adequate to build software with the goal of preventing failure. Rather, we must build software that automatically recovers from failure. Expecting and planning for failure, including the graceful degradation of functionality should faults develop – what we might call Chaos Monkey Engineering – is an essential part of building software that supports the business agility driver.
Introducing the DevOps Drumbeat
The move to DevOps also introduces additional constraints to our burgeoning Iron Polygon, as individual projects become less distinct. In an environment focused on continuous automated testing as well as continuous integration and deployment, individual iterations become the project unit as organizations establish regular cadences of repeated iterations instead of the discrete, monolithic project releases that characterize traditional waterfall-oriented development.
Rethinking the Iron Triangle in terms of DevOps cadences instead of software projects changes everything, as it brings the entire discussion up a level, as shown in the diagram below. In fact, each neighboring pair of constraints on the AA Quality Star leads to a new constraint.
Applying the DevOps Context to the AA Quality Star
Scope and agility connect to drive inherent flexibility. Agility and quality lead to resilience. Quality and cost factor into continuous testing. Cost and time drive continuous integration and deployment. And finally, time and scope connect to form the fifth new constraint, technical debt – not the bad kind where time constraints lead to sloppy code, but the good kind where the team intentionally introduces shortcuts or missing functionality into the current iteration as part of the overall cadence.
Essentially, DevOps doesn’t allow us to formally discard the Iron Triangle, but it does let us do an end run around it. Remember, the Iron Triangle says that for a particular project, scope, cost, and time must balance. In contrast, the DevOps way of thinking says don’t think about particular projects any more. Instead, think about the cadence. If we can shift elements of scope, cost, and time forward or backward in our cadence – a concept that doesn’t make sense in Iron Triangle terms – we can build better, more flexible software overall.
Let us therefore put away the Iron Triangle as well as the AA Quality Star, and introduce the DevOps Drumbeat, shown in the figure below.
The DevOps Drumbeat
Every cadence consists of drumbeats that set the overall pace of the effort within the context of the constraints in the diagram above. For each drumbeat – possibly an individual sprint or other iteration, or perhaps a finer-grained measure – the DevOps team must balance the five constraints.
The Intellyx Take: Connecting the Drumbeat to Agile Architecture
This article may be introducing the phrase DevOps Drumbeat, but obviously many of the ideas included in the figure above aren’t new. What is new is calling out the five DevOps constraints as such and putting them in a set that is analogous to the Iron Triangle. We’re also taking the novel step of representing the drumbeat as a circle, rather than a polygon. After all, DevOps should have no corners!
Furthermore, as DevOps practices mature, teams are likely to want to maintain resilience, continuous testing, and continuous integration and delivery. As a result, for each drumbeat, the tradeoff will be between inherent flexibility and good technical debt. This tradeoff is at the heart of Agile software architecture, as the Agile architect (or team members contributing to the Agile architecture role) must decide how much technical debt to take on in order to build inherent flexibility into their software. Placing this decision into the context of the organization’s agility-driven digital transformation priorities is a fundamental challenge that Bloomberg Agile Architecture™ addresses. Want to know more? Drop me a line.
