Blog Feed Post

The broken Devops production line

Let's say a raw material has to go through 4 sequential steps in a production line to become a finished product. All the steps use different equipments and have different processing capacity. Simple math will tell us that the step with the lowest processing capacity (volume / time) will determine the processing capacity of the entire line. Any attempt to increase the capacity of a step other than the weakest one will not result in any positive outcome for the line.

How do we increase the processing capacity of the weakest step? We can either reduce the complexity of the task or increase the capability of the equipment or re-engineer the process step to become more productive.  

Fundamentally, there is no other way.
As we strengthen the weakest step, the constraint will move to the next weakest one.

This means that in any process flow, where the processing capacity of individual steps is different, all the steps have to be in sync with the weakest step. If not, either there would be idle time or in-process inventory.

A theoretical solution to this is just to have one step and one highly capable equipment which can carry out all the process steps in one go. This will ensure that the equipment is fully utilized (no idle time) and there is no inventory.

Of course, we have to bear in mind that there are physical and logical limits to complexity of tasks which single equipment can handle.

Let's see if things change if we replace equipment with people.

Again, the person with the least processing capacity will determine the speed of the line. Please keep in mind that he might not be the least skilled person. Processing capacity is a function of both task complexity and skill - so it might be that this person is handling the most complex task.

People with more processing capacity (more skill or easier tasks) will have to be in sync with the one with the least capacity. If they are not, they will either be idle or producing more in-process inventory / WIPs.

So far, there is actually no difference between equipment and people.

However, there is an obvious one.

Instead of being idle or producing more inventory, people in the chain with higher processing capacity can COLLABORATE to speed up the person which is moving the slowest. Unlike equipments which cannot go beyond their defined scope, people can. They can, if they want to, team up to strengthen the weakest link and by doing so strengthen the entire chain.

You don't always need the same skill to help a person. This means that you don’t have to be a developer to help a developer or a tester to help a tester. A developer, or for that matter a BA, an architect, a systems administrator, a release manager or anybody else, can for instance speed up the work of a tester by sharing critical and timely information or by helping in some other coordination activities which do not require deep testing skills.

The important thing is that if the team in the chain is (1) aware of the weakest link and (2) is incentivized to strengthen the overall chain instead of their own individual links, the output would be far more than the sum total of their individual contributions.

In a waterfall world, people worked like equipments - each focused on their given task, just taking inputs and churning outputs and not really aware or bothered about the larger production line.

This is the very reason Scrum works. By getting cross functional people together and aligning their efforts towards a common 'production line' you're encouraging them to collaborate. Focus is on making the entire production line move and not on maximizing the efficiency of individual process steps.

As organizations now move towards a 'Devops' world, it is very critical that this extended production line is formalized and made visible. Agile, to a large extent, made the production line from Requirements to Testing visible. Now, the onus is on Devops to integrate Release, Support, Operations and Infrastructure teams to the same line.

My personal observation based on interactions with multiple customers trying to start off with 'Devops' is that there is too much attention on automation and too less on the broken 'production line' between Dev and Ops. Dev and Ops need to be incentivized to man a common production line and not separate ones. Their goals need to be aligned. The processing capacity of the different steps needs to be synced up so that there is continuous flow, instead of excessive idle time or in-process inventory. Only when their goals are aligned, they will collectively team up to strengthen the 'weakest' step.

The automation discussion should happen post this. With no production line visible and with no awareness about the relative processing capacity of the different steps in this line, automation investments can be shots in the dark - the blast will be heard and the flash of light will be seen - but there is no knowing whether the target was hit !

Read the original blog entry...

More Stories By Sujoy Sen

Sujoy is a TOGAF Certified Enterprise Architect, a Certified Six Sigma Black Belt and Manager of Organizational Excellence from American Society for Quality, a PMP, a CISA, an Agile Coach, a Devops Evangelist and lately, a Digital enthusiast. With over 20 years of professional experience now, he has led multiple consulting engagements with Fortune 500 customers across the globe. He has a Masters Degree in Quality Management and a Bachelors in Electrical Engineering. He is based out of New Jersey.