In most companies there are a very small number of resources (men, material, or machines) that dictate the output of the entire system. These things are called "the constraints." The company needs a trusted system to manage the flow of work to the constraints. The constraints are constantly being wasted which means that the constraint is likely being dramatically underutilized.
That is an extremely strong paragraph and you should re-read it and think about your workplace. Odds are your shop has a few go-to people who, if they quit or were run over by a bus, would be next-to-impossible to replace. These people are always busy solving problems and consulting with others. These people are the constraints. These people waste most of their important time dealing with tasks that do nothing to better the business or relieve the constraint. Think again about those go-to people at your workplace. Do you see them being assigned menial tasks? Are they constantly being hounded to get to meetings on time? To do their timesheet on time? These people are not working to maximum capacity even though they are the busiest people at your shop. That is why they are actually under-utilized.
What to do with constraints
Follow these steps to alleviate constraints. Use DevOps concepts I've already outlined in other post to help you.
Step 1: Identify the Constraint. Surprisingly most managers and scrum masters do not know where the most egregious constraints are on their team. They'll point to those people that are complaining the most that they are overworked. Sometimes it isn't them. The constraint will be the person(s) where the work piles up. Kanban boards can help to show you this. Once identified, protect the constraint. Do not allow the constraint to be sidetracked by time-wasting activities. The constraint is likely the bottleneck because it is being mal-utilitized. Make sure the constraint is never wasted.
Step 2: Throttle release of work to the constraint. Your constraint likely works on numerous projects or wears many hats. Reduce the number of work centers where the constraint is required. Note that this flies directly in the face of those DevOps proponents who claim that DevOps is merging your teams together. That will make things worse! Is your constraint really needed on all of those projects? Generate documentation or automate the constraint to relieve the burden. Or train.
Even if you hire or get more units of the "constraint" you will never be able to actually increase throughput. This is what Fred Brooks tried to teach us 40 years ago in the Mythical Man Month. If it takes one painter an hour to paint a room then it doesn't follow that 20 painters can paint the room in one hour.
Just as important as throttling the release of work is managing the handoffs. This is waittime that must be eliminated. Example: you've fast-tracked a bug fix through development but now you have to wait for a QA resource to free up. You should be looking ahead to determine what work is coming soon.
Step 3: Subordinate the Constraint. At this point the constraint should be less constraining on your system. You need to keep it that way. Remember that forcing more work through the system will not increase throughput, it will merely cause the constraint to start bottlenecking again. Instead, build buffers or slack into the system to ensure that the unforeseen spikes in work will not cause bottlenecks.
Do whatever it takes to ensure that maintenance occurs to increase availability of the constraint. Improving daily work is more important that doing daily work. The whole goal of this step is to make the constraint less constraining.
Step 4: Automation/Elimination of the Constraint. After Step 3 the constraint can still be a constraint under poor circumstances. We don't want that. One way to eliminate the constraint is via automation. If your constraint is certain team members that are overworked/poorly-utilized then you can eliminate by cross-training. For Ops people the best approach is always automation. Automate as much as you can and then those constraints should only need to be responsible for maintaining and enhancing the automated system.
Step 5: Rinse and Repeat. By now you've done as much with that given constraint as you can. It's best now to observe your improvements and spot the next constraint and begin again with Step 1.
Constraint Theory works well with DevOps. Understanding which resource is mal-utilized is the first step in improving your IT organization. You need to protect any constrained resource to ensure it isn't performing any work that another, unconstrained resource could handle. After that you need to other resources that can assume some of the work of the constraint. Lastly, automation is an excellent way to finally eliminate the constraint.