Manual processes and authorization bottlenecks tend to become the proverbial nail in the coffin when automatization initiatives are adopted. The refusal to bypass these old-fashioned control gates can doom the project, so let’s review the reasons that can lead this effort to ruin.
The first items to be mechanized in software development tend to be those related to the deployment of the applications (the whole get-latest, compile and install pipeline). It also holds as a proof-of-concept of sorts: the team will rationalize that if they can make a script for this process, they can also program one for any other task. While this is mostly true, they are forgetting the human factor on the equation.
Once the deployment pipeline on the development pipeline is automated, new items will follow: packaging, unit testing, and maybe some end-to-end tests as well, or perhaps infrastructure provisioning. And then, your team will feel confident enough to tackle release management.
This is the moment where you, as a director, must involve yourself into adopting the new automation strategy. Your help is not only necessary to find the steps to be turned into code, but to convert those managers that hold tight to their reins into the new way of doing. Most people will feel like automating their tasks will reduce their visibility or what they are worth. This statement is especially true for those people whose only job is just giving a “yay” or “nay” for a deployment to sensitive environments like pre-production or production. And, feeling like they can be “let go”, will do their best against the automation of their area. You need to identify these risks, ease their fears and work together towards a common goal. Make these managers feel involved into the adoption process with new tools. A dashboard tool with the state of the package with a resume of the release’s state can become a useful way to monitor a deployment’s process.
An important part of any automation process is the re-engineering of processes. The strategy must change – will change – when decisions are made in the design phase of the project, as originally intended. You are not really losing dynamism, as at any given time you can push back the state of a release and go back to the blackboard and change staff. But the important part is that allowing the flow to proceed only in one direction actually makes you go back to the beginning and start anew. No bypasses reduce room for mistakes and forgetting important but tedious steps that the computer will be taking care of.