“We’re going to automate this process”.
Now, it doesn’t matter whether you are a worker-bee in a factory, or a Sys Admin in a data centre, but when you hear the Boss use this phrase, let’s be honest, you get worried. And, frankly, you should be worried – especially if you are the person who has become the bottleneck. However, let’s look at it from a slightly different perspective for a few seconds.
If, by automating a task, we are planning on doing exactly the same amount of work as before, then by definition, automation means redundancy. But, if the plan is to increase throughput and at the same time make the workplace less of a drudge, then automation is an opportunity.
We have had the occasion to talk to quite a few Ops people in the last few weeks, primarily because their employer’s currently outsourced Managed Service contract is coming up for renewal and we’re helping them write a new tender. What is interesting is that most Ops people reckon that 25% to 30% of their daily workload is taken up by repetitive tasks and reactive work arising from fixing errors that those repetitive tasks cause.
Here’s the thing, they want to see the back of those tasks, so that they can focus on the more interesting backlog work that keeps getting put off because they are so busy with the daily grind. Less alligator batting and more swamp drainage design and implementation so the alligators go away. Its an age old argument around activity and productivity. High performing DevOps teams spend 21% less time on rework and 44% on new work according to the 2018 DevOps Report.
Meanwhile, here’s what their boss has said.
‘We’ve analyzed all our workflows and have identified Type A and Type B tasks. Type A are higher order, require experience and judgment to perform or there is some inherent risk in the task. Type B are repetitive and of lower value. Many of the Type B tasks introduce human error and have associated rework costs or create further unplanned work downstream. We are looking to automate Type B tasks as much as possible and retrain and reallocate staff to Type A tasks where there is more value to the organization – and the work we’re asking people to do is more interesting. Any task that takes 90 seconds per day and is undertaken 3 times per day is a candidate for automation.’
All that said, it is going to take time and money, and a significant effort, to automate so the key is to pick those tasks that deliver the biggest wins early in the process. Ideally, the earliest automation should focus on where the organization gains the most increased throughput and at the same time, the staff lose the most pain. In an ideal world, you’re also going to simplify and make the end-to-end process leaner. So, let’s live in an ideal world for a few minutes.
Lean means removing hand offs, eliminating waste, automating as you go and continuously improving. DevOps means applying lean to IT processes and Release Automation(RA) is a critical element.
Agile delivers lean to the left of the committed line of code. Lean processes ensure you build only enough software to add a value to the business that is greater than the cost of writing the code. Workflow tools enable you to scale these processes, integrate remote teams, and make teams autonomous without sacrificing management visibility. Automated code integration and automated test improve developer productivity. But note its process first and then tooling and then automation. Not the other way around. Our DevOps Simulations makes this point in spades as waterfall gives way to agile and automations in a business game.
We all know smaller more frequent releases won’t work without automations. The workload per release is simply untenable. So, if we’re going to get more work done, do more interesting work, and help our business succeed, which protects all our jobs, what we really need to hear the Boss say is; “We’re going to automate this process”.
POSTED IN: DevOps Case study