The top 3 models to optimize your IT business

Understanding flow

Many businesses have a process flow, which results in throughput. In simple terms, this can be represented as cars running from left to right. 

For them all to arrive efficiently and consistently at end of the road, they must go at the same speed. If one cannot go as fast as the others, it creates a traffic jam. No matter how good or efficient the cars are behind it, this one slow car has disrupted the entire flow and produced a non-optimal result.

This analogy can be applied to product development. Of course, for most businesses, the process is somewhat more complex, but in essence, the idea holds. The real question is: how do you continually improve your process to ensure there are no slow cars holding things back?

As Isaac Newton famously said, “if I've seen further than others, it is by standing upon the shoulders of giants". Fortunately, there are three giants who have given us highly effective models that enable IT businesses to identify inefficiencies, and remedy them.

“There are three giants who have given us highly effective models that enable IT businesses to identify inefficiencies, and remedy them.”

1. The Kaizen model

The first of these giants is a man named W. Edward Deming, the so-called ‘father of quality control’. Deming developed the Kaizen model for continuous improvement, which is basically a scientific approach to production.

The Kaizen model is based on a system for developing critical thinking that follows a Plan-Do-Check-Act approach:

• Plan – the first step is where you establish objectives and processes required to deliver the desired result
• Do – you carry out the objectives from the planning step 
• Check – this is where you measure the new processes and look for anomalies 
• Act – you evaluate the data and results gathered from the Do phase, before improving and adjusting the process
  
  

In practical terms, this can be used by businesses as a continuous improvement cycle. First, you get employees involved and gather a list of problems. You then choose a solution, test it, and regularly measure and assess the results. If this is successful, you adopt the solution, and repeat. 

This method of critical analysis can be particularly useful for IT businesses. If you are testing a new algorithm, for example, the Kaizen model helps you to know that it is actually faster, or more reliable (or whatever the objective was) than the old one. If not, then a different solution needs to be found. 

2. The Just-in-Time model and the Five Whys

Our second giant is a Japanese man named Taiichi Ohno, who also gave us ways to focus on continuous improvement. His Just-in-Time model introduces the notion of a Kanban, which is fundamentally a sticker that is put onto goods that are moved around a factory. The sticker shows key information that people need to know at each step of the manufacturing process, which enables the flow of work to be carefully controlled and signals when something essential is missing. 

Ohno developed the system while working at Toyota, a company that has used it with great success for many years (known internally as the ‘Toyota Production System’). As part of this, Toyota uses the ‘Andon cord’, which is an emergency rope that anyone on the production line can pull if there is a problem, causing the entire process to stop. The reason being, as demonstrated in our car analogy earlier on, if one part of the ‘flow’ stops, everything behind it will pile up, causing more chaos. After the Andon cord is pulled, everyone swarms in to resolve the problem and learn as much as possible about what went wrong and why.

This can be applied to IT in many ways, for example the design and implementation of CI/CD release. Kanban is a ticket in Jira, which can control workflow. The Andon cord can be used when a pipeline fails to stop backlogs and also act as a pull system. 

Another method Toyota uses with great success is the ‘Five Whys’. The idea here is that if you ask why a problem has occurred five times, you will unearth its fundamental cause (“why did this fail? Why did that fail? And why did that fail?” and so on) and potentially solve other issues along the way. This method of analysis can be applied to any business and can help agile teams to get better at identifying and solving root problems. 

3. The Theory of Constraints

Eliyahu Goldratt, the creator of the Theory of Constraints, is our last giant to mention. Goldratt created the Theory of Constraints, which is a model that shows how a system can be limited in achieving its potential, due to inevitable ‘constraints’ along the way. 

The theory shows how there is always a constraint, and the model uses a process to identify it and restructure the rest of the organization around it. This exemplifies the idiom "a chain is no stronger than its weakest link", highlighting how processes are at risk of a single weak person or part that can adversely affect the entire outcome.

This is, as Goldratt calls it, a focusing mechanism or, in other words, a way of pinpointing where you need to put your effort to improve the outcome. However, it is important to realize that this does not simply mean ‘just improve where you can’ (as people will only focus on where an improvement is easiest to achieve), but instead ‘improve where it matters’. 

For a typical IT company, the constraint starts at infrastructure, which needs to be solved first. As this is done through technologies such as cloud computing, the constraint usually moves to operations and deploying software, which can be resolved by continuous deployment (this is, incidentally, where DevOps began). 

When these constraints are no longer a problem, the focus moves to testing and security, where automation and Continuous Delivery can play a valuable role. From here, the constraint usually moves to development, where continuous integration and, for example, the ability to scale, peer programming, and knowledge sharing can help to rectify the issue.

Dealing with constraints 

All businesses should be asking themselves: “what’s my constraint”? It could potentially be that you may have one architect for 300 people who are all held up waiting for him or her to deliver. It can also be a department that delivers things to other departments, which is holding up the process because it cannot move fast enough. Your constraint can be many different things, but essentially it is that slow car that we talked about earlier. 

Eliyahu Goldratt had a way of dealing with constraints, called ‘drum, buffer, rope’. Firstly, you think of your constraints as a drum that sets the pace of the production line. Everything following this needs to go at the same pace; you are just wasting time and effort if they go any faster. 

Once done, you must set up a buffer in front of the constraint, because if the constraint runs out of work, you are wasting the entire value stream's time. The others might be able to catch up if they get empty, but the constraint will not as it is the weakest link. 

The rope then symbolizes a pull mechanism. You watch the process and hold workstations back from producing anything until you see the buffer of the constraint is at a certain level. When the buffer is full, you simply stop working. When it is close to empty, it acts as a pull system. If you look at the size of your backlog, it will show you how well you are doing this.

Applying this to IT

In IT, we could have a product owner and they are extremely good at creating issues. So, a backlog of 16 units is piling up. Then we have development that can only handle four and therefore becomes the constraint. 

We always start by setting the constraint as a drum. Then, when things are under control, we start looking for ways to scale. In this example, we could either set the ‘drum’ lower to resolve the backlog, or better still add further development teams in parallel, which enables greater output to operations (CD and Cloud). 

Even though operations can potentially handle 50, the final result is 12, rather than the four that the constraint would have limited us to. Further optimization would be to parallelize more development teams, but not until we have things under control first.

The Theory of Constraints can help in the most diverse circumstances, such as:

1. To set a maximum size for backlogs and avoid swamping downstream workstations. It is important to use pull between teams, not push.
2. If planning a migration, for example, you can use the theory to predict where the constraint will most likely be and solve it before it becomes an issue. 
3. Circumvent low bus factors by not allowing people to be a constraint, and advocating knowledge sharing.
4. To get the most out of your DevOps investments, which of course makes for a strong business case.

Process optimization in IT requires managers to take a big picture view to make sure no parts are holding up the overall flow. When there is a constraint, the temptation is always to try and fix the entire process, or to focus on the easy parts, rather than taking a logical approach to optimizing the weak link in the chain.

In essence, TOC can help you to find the weak link before it becomes a problem, to avoid further chaos if a problem does occur, and to organize workstations in a way that allows the most possible throughput at the end of the day. Only when things are under control, can you look for further ways to streamline and improve. 

Sounds interesting?

As we have seen, there are some excellent models at your disposal. If this sounds interesting and you would like to explore how you can use these methods to optimize your IT business, we can help.

You can either download our guide to understanding the big picture of DevOps, or better still get in touch with our experts who are ready to help take your business to the next level.