Do DevOps and the Theory of Constraints still relate?
The Theory of Constraints still holds weight in the IT industry decades later, but the adoption of DevOps slims down some of its relevancy. Here's how.
It's impossible to have worked in IT on projects that have not been bogged down by people, management, budget or technology constraints. The Theory of Constraints promotes the old saying that a system or organization is only as strong as its weakest link.
Talk of the weakest link suggests that organizations should invest their efforts and budget into fixing those weak spots. However, if you only build up the weak spots, you inherently create new ones.
Eliyahu M. Goldratt developed the Theory of Constraints (TOC) in his 1984 publication, The Goal: A Process of Ongoing Improvement. The theory advises organizations to focus on what's holding back a project and improve that element to achieve profitability and hit its goals.
The theory takes a measured and systematic approach to resolve constraints. Startups and more agile environments with a "build, break and fix fast" culture might disagree with the five steps to fix constraints.
There's something to be said for such an approach in the public sector and in compliance-heavy vertical markets that are cautious by nature of technology and business changes. As written, the TOC comes off as a single-track waterfall: The path to resolution could become resource- and time-intensive, thus hampering project delivery.
DevOps adoption meets constraints
DevOps adoption is a walking, talking case study about constraints with the processes and cultural changes enterprises must endure.
People factors, such as customer and user experience, were seldom a factor in IT decisions during the '80s, leaving end users feeling like they worked for IT -- not that IT worked for them. The same could be said for security and compliance teams, as well as other business stakeholders often left in a lurch during long development timelines that made responsiveness prohibitive.
TOC out of the box might not cure DevOps adoption constraints. There's no one-size-fits-all option to cut through DevOps cultural challenges. Consider the validity of change management in some enterprises -- some critics say change management is not attuned to the business reality.
Similar complaints apply to the Theory of Constraints in DevOps, because businesses work differently than they did in 1984. However, the first two TOC steps are timeless and great conversation starters for organizations facing DevOps adoption challenges.
Beyond development, operations teams traditionally become the 'Department of No' as they try to maintain pristine operating conditions.
It can be challenging to accommodate constraints that affect DevOps adoption, such as corporate politics, and management and employee pushback to change, but implementing the TOC can help. While it can't solve those constraints outright, it can set you up to tell an organized story to detractors who might fear DevOps adoption.
DevOps and the Theory of Constraints
Once past the challenges of DevOps adoption, there is still the continuous improvement of a DevOps methodology ahead. Waterfall development and other legacy development models make it challenging to deliver an improved experience and tools to customers. Beyond development, operations teams traditionally become the "Department of No" as they try to maintain pristine operating conditions.
Is the TOC showing signs of age in a DevOps world?
Today, practitioners still look to the Theory of Constraints as an example of a structured approach. But the latter parts of the TOC must give way to DevOps automation, strategies and agility to enable the remediation of technology, security and budget constraints while balancing delivery against constraints.
Some IT professionals write that the TOC and DevOps are directly compatible. They aren't necessarily wrong, but where TOC conflicts with DevOps is in steps 3 and 4. Continuous integration and automated testing eliminate the need to subordinate everything else to elevate the constraint. DevOps removes much of the weight that systems development lifecycles put on development teams in the past. Teams can tackle multiple constraints if they take them on strategically across releases in terms of days and weeks -- not months, as in 1984.
The DevOps Theory of Constraints should read more like the following:
Identify the constraint.
Fix the constraint.
Iterate.
Iterate.
Iterate.
Development teams live in a time of unprecedented opportunities to identify and remediate constraints and issues before they reach production. Opportunities such as automated software containers, container scanning, DevSecOps, and the large volumes of data that cloud platforms and DevOps tools generate using AI and analytics were things Goldratt could never have envisioned in 1984.
Ultimately, the TOC is a relic of a bygone era of IT, but leaves a legacy of structured thinking that enterprise DevOps teams can use today. It helps teams determine the best resolutions for constraints using the current generation of DevOps practices, tools and data over incremental releases that don't significantly delay delivery.
