<p>Unfortunately there is no one answer here. If you ask each member of your team, they will probably all have different answers. Instead of trying to a root cause analysis on something as generalized as "culture", try looking at return-on-investment instead. A fix to something near a bottleneck will usually have a better RoI than one further from the bottleneck, but if the further one will take 5 minutes and get you 90% of the benefit then who cares, do the needful.</p>

CC BY-SA 3.0
2017-03-02T04:14:03.680Z
I am not asking for what would happen if I ask people's opinions. I am asking for a practical way on how to find it. For example if I gather all the people in a room, what do I need to tell them or what I need to hit them with to get the right answer out?
Evgeny Zislis
CC BY-SA 3.0
2017-03-02T04:15:14.927Z
To get this great ROI you talk about, first we need to find the thing that gets the ROI. Then do the thing. Then get the ROI. Then we'll know ... that might work, but includes too much luck and seems kinda backwards.
Evgeny Zislis
CC BY-SA 3.0
2017-03-06T00:07:06.557Z
According to Theory of constraints, taking all the "different answers" your team has, and using Logical Thinking Processes can help you find the root cause or root conflict, when resolved, most of these problems are easy to remove with injections.
Evgeny Zislis
CC BY-SA 3.0
2017-03-06T00:40:40.597Z
If you think there is a a single (or small number of) root cause(s) that lead to software being difficult to develop and ship, there is a very good chance the bottleneck is you ;-) It's a bit like asking "why does a painting take so long?" or "when will you be done with that research project?"
coderanger
CC BY-SA 3.0
2017-03-06T01:39:57.317Z
I didn't say that. I wrote that according to Theory of Constrains Logical Thinking Processes, there is a method to find a root cause. Usually, there is just a single cause or conflict behind multiple problems within a single system.
Evgeny Zislis
CC BY-SA 3.0
2017-03-06T02:16:49.080Z
I agree that is what the theory says, but to apply it to a software development team you need to deal with the difference between creative and logical work. That is usually where all work on software estimation falls down.
coderanger
CC BY-SA 3.0
2017-03-02T02:15:41.880Z
2017-03-02T02:15:41.880Z
coderanger
<p>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.</p>

<p><a href="https://en.wikipedia.org/wiki/Theory_of_constraints" rel="noreferrer">Constraints</a> can be of three types:</p>

<ul>
<li>People: A particular skill or knowledge unique to an individual.</li>
<li>Policy: A written or unwritten policy or process, which limits the work either by increasing latency or reducing throughput.</li>
<li>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.</li>
</ul>

<p>In regards to software, the Software Delivery Process is often a constraint and thus <a href="https://en.wikipedia.org/wiki/Continuous_integration" rel="noreferrer">Continuous Integration</a> / <a href="https://en.wikipedia.org/wiki/Continuous_delivery" rel="noreferrer">Continuous Delivery</a> 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.</p>

<p>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.</p>

CC BY-SA 3.0
2017-03-02T04:17:06.120Z
So going around the place and finding people who do things manually, or depend on other people - then we'd know that pushing for self-service is elevating a constraint and it fits with what we need to do to improve? Any way to check if that is implemented, will it have an effect, before we actually go and throw money at the implementation?
Evgeny Zislis
CC BY-SA 3.0
2017-03-02T04:45:03.897Z
Those are all very valid questions and I would suggest to ask them separately and I will be glad to answer them all comprehensively for everyone on the site. "How do you elevate policy constraint?" "How do you estimate the cost/benefit of process automation?"
Jiri Klouda
CC BY-SA 3.0
2017-03-02T03:37:20.703Z
2017-03-02T04:08:45.523Z
2017-03-02T04:08:45.523Z
Jiri Klouda
<p>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.</p>

<p>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.</p>

<p>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?</p>

<p>A famous quote from Dr. Eliyahu M. Goldratt is</p>

<blockquote>
  <p>Any improvement not made at the constraint is an illusion</p>
</blockquote>

<p>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?</p>

CC BY-SA 3.0
2017-11-18T16:04:35.250Z
I vote for reopening as labour organization is very important for DevOps as well besides tooling. And we cannot optimize labour without understanding the tooling and the processes around them. Theory of constraints has been very important for industrial progress and so it will be for DevOps.
Ta Mu
CC BY-SA 3.0
2017-03-02T04:58:11.580Z
Please stop over-moderating. Those questions are important part of DevOps. We need culture and process related questions.
Jiri Klouda
CC BY-SA 3.0
2017-03-02T07:03:40.220Z
The problem is that for a Q&A site to work, we need questions that have a defined-enough answer to rank and vote on responses. This question is very close to "how do I culture?", which is really hard to answer without some specifics.
coderanger
CC BY-SA 3.0
2017-03-02T16:06:43.013Z
There are some meta methods that exist in finding out what kind of reality a company exists in. If you don't know these meta methods, fine, but do let others express their experience and knowledge about how to do these things - there are definite narrow answers based on literature and experience that fit well with this question.
Evgeny Zislis
CC BY-SA 4.0
2019-12-22T07:13:30.750Z
+1 on reopening, there is a very specific context on finding a constraint per Goldratt's TOC definition in a DevOps environment for a software development shop. I don't think that is unspecific.

As an example, Clarke Ching's proposes a solution in his FOCCUS process in his book "The Bottleneck rules". Very specific general solution for exactly this general problem, while obviously the details of the solution would vary depending on the specifics.
Bruno Guardia
<terminology><culture><workflow>
How to find the constraint in a software development shop?
Evgeny Zislis
# How to find the constraint in a software development shop?

(Asked by: username_0 on 2017-03-02)

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?

**Tags:** terminology, culture, workflow

> **Comments:**
> **username_2**: Please stop over-moderating. Those questions are important part of DevOps. We need culture and process related questions.  
> **username_3**: The problem is that for a Q&A site to work, we need questions that have a defined-enough answer to rank and vote on responses. This question is very close to "how do I culture?", which is really hard to answer without some specifics.  
> **username_0**: There are some meta methods that exist in finding out what kind of reality a company exists in. If you don't know these meta methods, fine, but do let others express their experience and knowledge about how to do these things - there are definite narrow answers based on literature and experience that fit well with this question.  
> **username_1**: I vote for reopening as labour organization is very important for DevOps as well besides tooling. And we cannot optimize labour without understanding the tooling and the processes around them. Theory of constraints has been very important for industrial progress and so it will be for DevOps.  
> **username_4**: +1 on reopening, there is a very specific context on finding a constraint per Goldratt's TOC definition in a DevOps environment for a software development shop. I don't think that is unspecific.  As an example, Clarke Ching's proposes a solution in his FOCCUS process in his book "The Bottleneck rules". Very specific general solution for exactly this general problem, while obviously the details of the solution would vary depending on the specifics.  

---

## 2 answers

### Answer by username_2 on 2017-03-02. Score: 6 | Accepted answer

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](https://en.wikipedia.org/wiki/Theory_of_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](https://en.wikipedia.org/wiki/Continuous_integration) / [Continuous Delivery](https://en.wikipedia.org/wiki/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.

> **Comments:**
> **username_0**: So going around the place and finding people who do things manually, or depend on other people - then we'd know that pushing for self-service is elevating a constraint and it fits with what we need to do to improve? Any way to check if that is implemented, will it have an effect, before we actually go and throw money at the implementation?  
> **username_2**: Those are all very valid questions and I would suggest to ask them separately and I will be glad to answer them all comprehensively for everyone on the site. "How do you elevate policy constraint?" "How do you estimate the cost/benefit of process automation?"  

---

### Answer by username_3 on 2017-03-02. Score: -1

Unfortunately there is no one answer here. If you ask each member of your team, they will probably all have different answers. Instead of trying to a root cause analysis on something as generalized as "culture", try looking at return-on-investment instead. A fix to something near a bottleneck will usually have a better RoI than one further from the bottleneck, but if the further one will take 5 minutes and get you 90% of the benefit then who cares, do the needful.

> **Comments:**
> **username_0**: I am not asking for what would happen if I ask people's opinions. I am asking for a practical way on how to find it. For example if I gather all the people in a room, what do I need to tell them or what I need to hit them with to get the right answer out?  
> **username_0**: To get this great ROI you talk about, first we need to find the thing that gets the ROI. Then do the thing. Then get the ROI. Then we'll know ... that might work, but includes too much luck and seems kinda backwards.  
> **username_0**: According to Theory of constraints, taking all the "different answers" your team has, and using Logical Thinking Processes can help you find the root cause or root conflict, when resolved, most of these problems are easy to remove with injections.  
> **username_3**: If you think there is a a single (or small number of) root cause(s) that lead to software being difficult to develop and ship, there is a very good chance the bottleneck is you ;-) It's a bit like asking "why does a painting take so long?" or "when will you be done with that research project?"  
> **username_0**: I didn't say that. I wrote that according to Theory of Constrains Logical Thinking Processes, there is a method to find a root cause. Usually, there is just a single cause or conflict behind multiple problems within a single system.  
> **username_3**: I agree that is what the theory says, but to apply it to a software development team you need to deal with the difference between creative and logical work. That is usually where all work on software estimation falls down.  

---

