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?

closed as too broad by Woodland Hunter, Peter G, Alexandre, Gepser, coderanger Mar 2 '17 at 4:20

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    Please stop over-moderating. Those questions are important part of DevOps. We need culture and process related questions. – Jiri Klouda Mar 2 '17 at 4:58
  • 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 Mar 2 '17 at 7:03
  • 1
    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 Mar 2 '17 at 16:06
  • 2
    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. – Peter Nov 18 '17 at 16:04

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.

  • 2
    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 Mar 2 '17 at 4:17
  • 1
    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 Mar 2 '17 at 4:45

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.

  • 1
    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 Mar 2 '17 at 4:14
  • 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 Mar 2 '17 at 4:15
  • 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 Mar 6 '17 at 0:07
  • 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 Mar 6 '17 at 0:40
  • 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 Mar 6 '17 at 1:39

Not the answer you're looking for? Browse other questions tagged or ask your own question.