DevOps and Theory of Constraints

How DevOps and Theory of constraints can work hand in hand to deliver better performing IT organizations.

DevOps has been amongst the main trends in IT organizations in the last few years. It brings a new organization of IT activities and allows quicker and safer updates of applications while making them more resilient. Since the publication of the book “The phoenix project” which is considered as a foundation to the DevOps movement, the link between DevOps and theory of constraints has been recognized.

What is DevOps?

Here is the first difficulty: there is no clear definition of DevOps accepted by all the stakeholders in the IT industry. It is often described as continuous integration and deployment that is handled by “the people in Ops” or in some cases something we haven’t managed to adopt yet. One thing that we all agree on is that it is a way of linking the steps for managing the life cycle of software or IT applications, including development, operation, quality assurance, testing. Many don’t fully understand that these things are not separate but overlapping concepts when implementing all aspects of the life cycle like software, hardware, security, etc.

The key concept that should be considered is the importance of developing a single view of the system. The willingness to acknowledge that all these actors cannot work efficiently in a silo, but need to be part of a set of processes, best practices and overlapping of responsibilities that have begun to define a new cultural way of thinking in an organization structure. These new ways of working will help an organization to assure faster time to market, reduced issues in the release cycle and improved resource efficiency across the enterprise.

Adoption And Successes of DevOps

As more and more organizations realize the need to better govern and automate processes they begin to buy into the idea of DevOps, the complexity of the task becomes more evident. It seems logical that incorporating new processes and tooling to assure faster build and deploy automation would be fairly straight forward. Nevertheless, adoption remains most of the time partial at best due to a number of potential challenges. Some of these challenges typically include:

• A lack of agreed upon definition of what DevOps is and how it fits in the organization;
• The challenging of processes and roles that have become the norm within the organization can cause some leadership or team members to feel like they are losing ownership;
• Changes to tooling can cause resources to need additional training or hiring of new resources may be necessary to achieve strategic goals;
• Shifting the structure of teams away from a siloed approach to development, testing and operations can also be difficult for some resources to understand or accept.

These challenges while potentially not a small issue in large organizations are overcome through proper planning, enterprise acceptance of a common strategic path and the benefits that are gained as a result of a successful adoption. DevOps, as mentioned earlier, is a cultural shift. Its ability to succeed and provide benefits such as increased observability into processes and resource efficiency, faster time to market, reduced down time and reduction in total cost of ownership related to maintenance and application delivery are achieved through defining the definition and building models to assure implementation. The culture shift brings changes that will

• Increase collaboration;
• Improve communication and transparency into application activities across the SDLC;
• Break down traditional silos, changing the “mine and yours” to an “ours” mentality;
• Resource efficiency shown throw appropriate performance metrics to help reduce bottlenecks and optimize ways of working;
• Reduction in time spent troubleshooting issues through automation and full end to end monitoring;
• Adoption of governance practices to manage long-term scale of tooling and processes to reduce downtime and plan for expansion.

Full implementation of a DevOps culture takes time and patience, especially within a well-established organization with long-standing processes. Acceptance and proper collaboration between the stakeholders across the enterprise will help to ease the adoption and of new processes and methodologies. Further accelerators, and practices, can be merged with DevOps to enhance the potential for building a comprehensive and optimized model through adoption of methodologies such as the Theory of Constraints (TOC).

What is the theory of constraints?

First don’t get fooled by the name: the theory of constraints is not a hypothetical methodology. This is a full framework of pragmatic rules and tools to predict the evolution of business in its context.

This pragmatic approach of management was first presented in the book by Dr. Eli Goldratt “the Goal” In 1984. This book is now studied in all major MBA programs worldwide and is still in the 100 highest sales on Amazon.

The main principle developed in TOC is that any system output is limited by one and only one constraint at a given time. The main objective of the toolbox of TOC is to manage these constraints in order to maximize the production and the profit of the system. For TOC, the output of the full system is driven by the limiting constraint and only by that constraint. Even the work in progress inside the system is defined by the constraints. The objective is then to increase the throughput of the system while minimizing the inventory of work in progress.

The toolbox of TOC contains several tools based on the principle of the methodology:

• The five focusing steps allow to increase the output of a system while decreasing the work in progress and the money tied up inside such a system. This process identifies the constraints, decides how to manage it and then how to increase its capacity. Then the circle starts again by determining whether the constraints have changed as a result of our actions;
• The buy-in process that explains how to overcome the natural resistance of people to change by using logic analysis of the issues and logic description of the solution;
• The logical thinking process is a set of several cause effect logic trees allowing to analyze a situation or predict the result of a solution. The strategy and tactics tree, current reality tree, future reality tree, evaporating cloud, prerequisite tree and transition tree are the different types of representations of the logical thinking process. Each one of them has a specific role in the process of continuous improvement of operations;
• Critical chain project management. This methodology of project management is aimed at protecting the delivery date of a project from expected risks and behavior of the teammates.

Adoption And Successes of TOC

There is no lack of examples of successful implementation of TOC In the literature. TOC was applied by large companies (like Boeing, Tata Steel, US Air Force) and by “dad & mom” businesses (some local pastries by example). All these implementations were showing quick and significant positive impacts on their operations.

A study performed by Victoria University in Wellington (NZ) detailed the results obtained by 100 Companies of different sizes. The results registered within the first 12 months of the implementation of TOC are shown in the following diagram.

Despite the fact that TOC doesn’t share the same awareness as several other performance improvement methodologies like Lean or six sigma, it is widely used in all kinds of industries or activities. TOC was used by the UK National Health System to improve the waiting time for several departments. The UK NHS officially registered TOC as one standard tool for improvement of performance. Tata Steel is another example of success of implementation of TOC. Tata Steel adopted TOC as their main methodology of problem solving and continuous improvement for several years. Another large corporation that adopted TOC is Microsoft which implemented the methodology of TOC to manage bottlenecks within its own IT department.

How TOC and DevOps work together

Without an enterprise DevOps set of processes, each department, or silo, was forced to attempt to optimize its activity independently from each other. As these silos groups work to find their own set of optimal processes and tools, often there is no thought to the implications of the enterprise IT impact of their decisions. The processes and performance of other teams in a different silo are not considered as long as they reach a perceived optimal practice within their silo. Due to lack of collaboration between silos, they often don’t have any insight into the potential for inefficiencies across the larger IT landscape in the enterprise. Even if this optimum doesn’t bring any improvement on the global operations of the whole IT life cycle, and even without caring whether their optimization could damage the operations of another department. They have no way of knowing if this is the case.

The integration of the activities involved in the life cycle of IT applications into a single process is a first approach that DevOps and TOC have in common. Both approaches allow us to stop relying on local optimums, and focus on a global optimum.

Organizations implementing DevOps often start from departments organized in separated silos. To obtain a smooth adoption of DevOps and no fight back from the teams involved in this change, it is often needed to convince the members of the teams of the necessity of this change.

In many organizations, DevOps cultural ways of working can take people out of their comfort zone, as some will lose control of their small share of work when the need to hand-over between departments is removed and replaced with collaboration throughout the whole lifecycle. Using a strategy and tactics tree, the management can give clarity and transparency to the decision and show how this change embeds into the vision of the organization for the next four to five years. This tree shall also show how the adoption of DevOps relates to other changes adopted by the organization to reach its goal. This clarity is requested by the first of the seven layers of resistance described by TOC. The manager in charge of DevOps implementation could beneficially use the other layers to get ready to supersede them when encountered. The buy-in process from TOC is a great help to anticipate reservations from the people who will have to adapt to new ways of working when shifting to a DevOps culture within the organization.

Adoption of a unified global process makes the IT life cycle look like an industrial process. This claim was often contested by IT practitioners, arguing that IT was a different world, a specific and special world. Adopting DevOps is equivalent to acknowledging that IT is the result of a “quasi-industrial” process and that it can be managed exactly as an industrial process can be managed. This also means that it can be improved exactly as an industrial process can be improved.

The difference is mainly that the work in progress is invisible. There is no stack of parts to be counted, but there are projects stuck in the pipeline. Detecting where the projects are stuck can help identify the constraint, as we can detect it by looking at parts piling in front of a machine in a workshop. Having a single process that involves the complete life cycle of the IT application, allows for the application of the five focusing steps of continuous improvement — a flagship methodology from theory of constraints — that can improve the global operation.

By determining the bottleneck and deciding how to exploit it, the organization ensures that the maximum use of its resources is made. It maximizes the output of its DevOps organization. The most difficult step to apply is the subordination of all the organization to the decision of how to exploit the bottleneck. This often involves modification in separate departments which are under the supervision of several managers. Some conflicts can surface at that moment, and a win-win solution shall be found. Using the different trees of the logical thinking process may make this research of solution easier. This analysis allows to focus the attention of management on what actually limits the rate of production of projects and impacts the profit of the organization. By definition, the constraint limits the throughput of the whole system. Therefore, focusing on the workload or productivity of all actors of the process is of no use, only the workload and productivity of the constraint is of interest. By applying the five focusing steps, the organization often reaches a DBR (Drum-Buffer-rope) like application (DBR is a methodology from TOC allowing to maximize the throughput of a process while minimizing the work in progress). This also allows the organization to implement a first synchronization of their portfolio of projects, by using the bottleneck as the drum of the system.

At that stage, the organization may elect to adopt even more performing methodologies. One of those is the critical chain project management. This methodology enables the organization to compensate for the management-induced behaviors of project teams’ members. These behaviors are called survival behaviors as they are referring to the way the team members cope with the pressure put on them.

These behaviors include multitasking (which is often considered as the standard of this profession and its damageable consequence are rarely acknowledged), task padding, sandbagging, polishing work (according to Parkinson law) or student syndrome. Those behaviors have the same root cause: a management pressure to protect each task delivery date, while the focus should be on protecting the project delivery date. Critical Chain Project Management (CCPM) enables that switch of focus and to increase the due-date performance of projects. Even if it is often considered that an IT project being late and over budget is a given, this is not an actual fate. CCPM brings solutions to these symptoms. This methodology included some years ago in the panel of methodologies acknowledged by the Project Management Institute, brings a beneficial change in the behavior of teammates and an improved reliability of the project planning and portfolio planning.

Once the DevOps organization is operational, the work is not finished. The organization recognizes the IT activity as a full process, and as with all processes, this one has a bottleneck that limits its output. The organization then finds itself in the situation described in the “Phoenix Project” and can develop the same strategy of bottleneck management using the five focusing steps of continuous improvement of TOC. This allows the organization to both manage existing bottlenecks and avoid the accumulation of stalled projects in the portfolio, while initiating a culture of continuous improvement as the foundation of its renewed resilience.

Resilience is becoming a major focus of companies, clients, regulation authorities and investors. Some ISO standards have been released in the last year to better define what should be understood by organizational resilience. The combination of TOC and DevOps ticks all the boxes of a resilient organization and at the same time ensure the highest possible level of performance of operations.

What are the next steps?

The context of business post COVID 19 requires that companies move much quicker than ever before. It also requires that companies be able to adapt to brutal evolution or changes that shall happen without any prior notice. Both DevOps and TOC are designed to build this resilience and the necessary speed into the company. Furthermore, the combined application of TOC with DevOps initiates a virtuous circle of continuous improvement of the whole system.

DevOps and TOC work perfectly hand in hand to provide to the organization implementing them together a top-of-the-line performance of IT operations. This is no surprise as the book “the Phoenix project”, often considered as the Bible of DevOps, makes numerous references to the theory of constraints.

Marrying these approaches brings a perfect fit for facing the challenges in this new context by bringing together the necessary tools and methodologies to ensure high performance and resilience of the organization.

“Tell me how you will measure me and I will tell you how I will behave” Eli Goldratt.

Didier Varlot

Senior consultant in Business Continuity and Theory of Constraints, Owner and CEO of SNTC.

Didier, based in Romania, has practiced the Theory of Constraints for the last 25 years in several industries from railway industry to healthcare services, from chemical industries to green energy supply. His Medium blog is accessible from here. Twitter @dvarlot

Eric Tice

Director & Open Source SME Lead, Open Source Consulting Practice, Wipro.

Eric, based Nashville TN, provides open source focused technical consulting services for Wipro’s key customers. Throughout Eric’s career, he has worked extensively in DevOps, and open source. linkedin.com/erictice, Twitter @EricTice4

Gilles Gravier

Director, Open Source Consulting Practice, Wipro.

Gilles, based in Switzerland, provides open source and blockchain strategy consulting and advisory services to Wipro’s key customers worldwide. Throughout his career, Gilles has been involved in both security and open source. His Medium blog is accessible from here.