BUILDING BRIDGES – Using kaizen, a team at Theodo was able to reduce the time necessary to install a project on a new developer’s computer from three weeks to twelve minutes.

Words: Clément Hannicq, Architect Developer, Theodo

Photo by Kevin Ku on Unsplash

When developers join a project, the onboarding begins by installing the project on their computer so they can start working. This is very much akin to the change of dies we see on the production floor.

A few months ago, I joined an ongoing project here at Theodo and I was shocked to see it took me two days to install it. To me this was not acceptable, especially considering that in our company we install projects very often (160 times in 2018). In my mind, this task shouldn’t take more than 30 minutes, so I chose this timeframe – half an hour – as a standard and decided to start a kaizen.

LEVERAGING AUTOMATION TO WEED OUT HUMAN ERRORS

I started by mapping all the steps in the installation process to onboard a new developer, each of them taking from 1 to 4 human actions – as described in this graph:

Then, I sorted through the steps and removed those I found to be unnecessary. For example, I discovered that the “Setting up credentials on the virtual machine” was unnecessary, because creating the virtual machine automatically generates credentials. This meant we did not have to set up new ones – a good example of digital 5S.

I then decided to automate the process, because I was making lots of mistakes following it. Hence, I wrote a script to execute all the remaining steps and managed to get the installation time under the 30 minutes threshold. (The first step, “Install Global Dependencies” was the only one that depended on the computer the developer uses. This made it the most complicated to automate, so I left it as is.)

POKA YOKE TO THE RESCUE

Soon after that, I switched projects again and, one more time, I encountered a very complex installation process. It entailed about 40 pages of instructions, and it took me three weeks to install the project locally.

In response, I applied the standard I have designed in order to simplify the installation process. When the next developer joined the team, it took him less than 15 minutes to install.

However, when a couple months later a new developer joined the project, it took him 50 minutes. He got stuck five times because he made mistakes during the global dependencies installation.

This story prompted me to add a new standard: there must be an automatic check that every global dependency is installed and functional. Thus, I added a script that would check the installation of every tool needed by the project. I had it display on a single line in the missing or broken dependency when it failed.

Following those improvements, I removed a couple hundred manual actions. The next installations took the new developers a maximum of 12 minutes.

THE AFTERMATH

Over time, I kept doing kaizen on dozens of projects. To date, I have come up with the following standards:

• All external dependencies are listed and the developer has a way to know how to solve them.

• To ensure the global dependencies are correctly installed, there is an automatic check. There is at least one known set of global dependencies that is known to work.

• Installation is automated (once the global dependencies are installed).

• Installation always works on the first try. Which means, for example, that there cannot be a troubleshooting section in the documentation.

I am now starting to realize that my initial goal of installing in less than 30 minutes should not be a developer’s first concern, as they should focus on making it work right first time.

If I reflect on my experience from a lean perspective, I see my journey being very similar to the SMED methodology.

The gist of SMED is to start by mapping out the process and identifying which steps require production to stop, those are called internal. Then convert as many internal steps into external steps, meaning that they no longer require production to stop. And finally ensuring all external steps are reliable.

Much like on a production floor when a machine goes through a changeover, the developer needed to stop the production of features and focus on the installation instead. The installation steps were already defined but required the full attention of the developer – they were internal.

By automating the installation, I simplified a process of dozens of internal tasks and replaced it with a number of external tasks, since the developer no longer has to handle the sequence of commands himself.

The last step is to streamline the steps that still required the attention of the developer – handling errors and global dependencies.

_{THE AUTHOR}