As humans, we tend to avoid situations where we experience pain or discomfort. Consequently, many organizations tend to decrease the frequency at which ‘hard’ things are done. And rather than fixing the root causes of the pain and discomfort, often there’s a desire to increase the amount of formalized process around the action that needs to be accomplished.
A typical case is the deployment of software. As it’s a pain to test all new functionality in the latest version of the software and to regression test all the functionality that’s supposed to be still working, we tend to decrease the release frequency to reduce the amount of release overhead. The argument I often hear is that customers are asking us to decrease software releases because it also causes them a lot of overhead to deploy the new versions. This argument is happily accepted by the company and used as an excuse.
Of course, it’s orthogonal to the goal of digitalization, which is concerned with the continuous deployment of new functionality. Consequently, one of the tenets of Agile practices is that if it hurts, you should do it often. The idea is that if you often experience pain in a particular situation and aren’t allowed to avoid it, you’ll be inclined to start fixing the things that are causing the pain in the first place.
One of the key factors in people experiencing situations as painful is repetition and manual drudgery. As humans, we’re terrible at conducting actions over and over again and even though a lot of manufacturing traditionally was about asking humans to conduct the same operation for entire work shifts, also in that part of industry, we’ve moved to teams jointly assembling entire systems from beginning to end.
The main answer to repetitive tasks is, obviously, automation. Computers are world class at conducting the same action over and over again without complaints, loss in quality or variance in output. So, it’s evident that when it comes to digitalization and continuous deployment of new software, automation has to play a major role. The three typical application areas focus on test, deployment and configuration.
In earlier posts, we discussed the importance of continuous integration and test. The idea is that every time an engineer checks in new code, immediately a new version of the software is built and tested. For most systems, the check-in frequency is much higher than the build and test cycle and multiple check-ins are combined, but the basic principle is to ensure that the software is always at production quality and that any defects are detected as soon as possible.
The second application area of automation is deployment. Especially in SaaS companies, it’s custom to push every release of software that successfully passes the testing stage immediately into production. The idea is that if we build new features that are valuable to users, there’s no point in delaying user access to them. For embedded-systems companies, this is much more difficult to accomplish as the systems receiving the software are out in the field. Traditionally, however, updating software in the field often was an elaborate process requiring a knowledgeable technician. Automation of the deployment process is to achieve a state where software can be updated without any human involvement and, preferably, without causing any downtime for the system being updated.
A third automation area is configuration. Different from SaaS, most software on systems deployed in the field has been configured and optimized by users to achieve optimal outcomes in their specific context. One reason why customers resist upgrading software is that it often requires them to repeat the configuration process. So, when preparing for continuous deployment, existing configurations need to be automatically incorporated by subsequent deployments. However, we can go one step further and have systems configure themselves without human involvement. This can range from rule-based configuration to reinforcement learning approaches where the system experiments with its own behavior to optimize performance.
There are at least three areas to consider when working on automation: finding the pains, modularizing processes and orchestrating. When humans are exposed to something for a long time, no matter whether it makes sense or not, we tend to start to believe that this is just how it is. Like gravity, there’s no way to overcome it. The first step is to recognize that something that has been “just how it is” is actually fixable. The target of this activity is to identify activities conducted by humans that are repeatable in nature as these should be the focus of any automation effort.
The second area to consider is the modularization of processes. There’s a ‘dirty little secret’ concerning automation: it tends to stifle change. The sunk cost of the process that has been automated is often significant and so is the cost of making changes. As a consequence, there’s significant resistance against change in the broadest sense. This may easily result in suboptimal outcomes as processes aren’t aligned with the current needs, but rather based on tradition and outdated beliefs. So, the focus of modularization is to break processes into relatively independent blocks that can be freely composed to decrease the cost of changing processes.
The third focus area is process orchestration. As processes are, where feasible, organized in these independent blocks, we need to compose the blocks within processes and the interdependencies between processes through orchestration. This includes both the triggering of process steps and the transfer of data involved in the processes. In recent years, quite a few new approaches and associated tooling around robotic process automation (RPA) have come to the market and these can be quite helpful.
Humans naturally tend to do difficult and painful things as infrequently as possible, which is counterproductive in a digital transformation. The Agile mindset provides a helpful tool in the notion of “if it hurts, do it often.” That will cause organizations to streamline and automate processes and get humans out of the loop of repetitive actions. To achieve this, we need to identify the pains, modularize processes to decrease the cost of change in the future and orchestrate processes. As Jon Gordon said: love the process and you’ll love what the process produces.
Like what you read? Sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch), Medium or Twitter (@JanBosch).
