How to find the constraint in a software development shop?

Let us define a constraint as anything that prevents the system from achieving its goal and then look at the goal of DevOps in an organization.

A good definition is "DevOps enables a fast flow of features from development to IT operations to the customers." Improving DevOps can be achieved by removing impediments to flow.

First, we must find these constraints in the flow. And maybe there are multiple obstacles, how can we decide on which one to remove first?

A famous quote from Dr. Eliyahu M. Goldratt is


Any improvement not made at the constraint is an illusion

This constraint, once found, is an important focusing mechanism for management of the system. So, how can you identify the constraint in an IT organization? And what to change about it to get the benefit of better flow?

To identify a constraint in any process is a relatively simple task. Work moves from a person to person throughout the organization and it will simply pile up in front of a constraint. You can look for people or teams with the highest number of blocking unresolved issues for example. It depends on how you track the flow of work, but if you do track it, then identifying constraint is usually not too difficult. It helps to know the value chains for your organization and simply follow along them.

Constraints can be of three types:

• People: A particular skill or knowledge unique to an individual.

• Policy: A written or unwritten policy or process, which limits the work either by increasing latency or reducing throughput.

• Equipment: Particular computer system can limit the speed at which you can pass work through it or the number of people that can use it at the same time.

In regards to software, the Software Delivery Process is often a constraint and thus Continuous Integration / Continuous Delivery is such a powerful way to elevate this constraint and subordinating the organization to this constraint is often needed to increase the throughput of work. By automation in Software Delivery you remove slow people and often costly policy obstacles and approvals. Equipment in form of Computer System upgrades is a relatively small cost comparatively to the other two.

QA is another example of possible constraint in the process. Manual quality controls are work intensive and even automated testing can be constraint by equipment, in case the software is to run on expensive hardware. But the most common constraint in QA is policy, which tends to snowball with ever problem. The latency of the QA process and the small throughput can lead to larger units of work being put through, which can push back the cost into code integration.

StackExchange DevOps Q#196, answer score: 6