No one wants to rock the boat by introducing unwanted or unexpected changes in an organization. However, as consultants, we sometimes need to leverage our expertise to improve the process of driving change.
Recently, I identified, proposed, and executed a solution that significantly improved the efficiency of a client’s product build pipeline – allowing their teams to ship working software much faster. Using a process invented on the way, I was able to implement a change that reduced the application’s refresh speed from 5 minutes to under 10 seconds; a significant improvement for both the organization and their clients.
In this post, I’ll share that process along with the insights from my recent experience.
1. Measure
The first step is to show the organization that changes are needed, valuable and wanted by the team. The best way to do this is to measure and benchmark against industry standards. Better yet, compare reality to what your team wants. Ask them directly, “What do you want or need to do your job better?” Get their wish list of everything, even if they are “reaching for the stars”.
To drive improvement, you must first collect information about what you seek to improve. In our client’s case, there were parts of the UI that would take more than 5 minutes to show a single change in code. When I asked the client what they wanted out of UI refresh speed, they said they wanted to reduce it to “seconds”. So, it was important to measure the growth in code and time of commands.
2. Research
Once you have an area of measurement to work on, you need to determine how you will improve it by identifying the most severe inefficiencies and most-used parts of what you seek to improve.
Next, find the intersections of the two and address those areas first. Determine a set of tasks that will need to be completed.
In this stage, I had to take a deep look at what technologies the client was using and why. The client’s existing build pipeline used technologies called Gulp and Browserify. These technologies were appropriate when the project began. But as the project scaled, the build pipeline slowed.
During my research, I found a few ways to improve the slowest parts of the build pipeline temporarily. By delivering small, powerful changes I was able to provide immediate value to the team and gain the client’s trust to make larger changes.
My research led me to look into how other large scale projects handled the build process. I found two industry standards, Webpack and Parcel. I chose Webpack based on the following reasons:
- Our consulting team was experienced in Webpack.
- Webpack appeared capable of performing all the functions of the previous build process more efficiently.
- Parcel had the unfortunate circumstance of having a homonymic relation to the client’s internally loathed package.
- Parcel was newer and not as widely adopted.
3. Plan
The next step is to plan the execution of the desired changes. Planning such a project is less about breaking down tasks, but more about risk mitigation. Any failure in your project that leads to worse conditions could lead to a more permanent return to the status quo and increase resistance to subsequent attempts to improve.
For example, the Webpack migration could have caused a major regression preventing work for a week or more. In effect, the transition could be perceived as a bigger threat to productivity than the previous process. Therefore, the transitional build process needed to overlap with the previous build process.
This of course added another layer of complexity to what already promised to be a difficult project – keeping the previous build process working at the same time as the new.
I planned to introduce the Webpack build process to only the core parts of the application. This is where the developers would create the most value. At first, I would avoid edge cases and less touched parts of the code. This meant that the majority of the engineers would be able to use Webpack at development time. Features like partial rebuilds and hot reloads would bring the development cycle time to under 7 seconds.
The legacy build pipeline would still build the production application. This would introduce one added testing complexity. The development code would no longer be the same as the production code. Yet, this didn’t prove to be net loss during the transition. Different build pipelines didn’t introduce any major issues.
4. Transition
The next step is to introduce your solution, and deprecate the old process or build. This leaves the old process or build available in case of an emergency. If the switch is unsuccessful, the old process is still available. The team or management may still prefer the status quo over volatility and risk.
In our client’s case, this transitional period went unnoticed as intended. We changed our CI/CD process to use the new Webpack build by default. The Gulp/Browserify process was available via build flag, if necessary. A side effect of this switch was freeing up of CI/CD resources. This is because the new process took less than 10 minutes to build, rather than 50+ minutes. A huge reduction in code reduced most CPU-bound parts of the production build, to only a few minutes.
An important note for this stage is to remain available for issues. There will always be an unforeseen flaw in your transition. You need to plan for complete and partial rollbacks.
Luckily, I was able to fix the issue without any change in the process. In case of another problem, I was prepared to roll back the entire cutover with a single line of code. This had not been possible before, though I was able to refactor other processes to make it so. Allow yourself some sidetracks in your plan, but don’t scope creep the project into oblivion. You can’t fix everything at once.
5. Iterate
Once you have made the transition to the new process or build, your team must iterate to extract maximum value from it. During this stage, the old process will become less important as the risk diminishes. At some point, you may determine that it’s less effort to maintain the new version than it is to resurrect the old one. You’re then able to remove the deprecated version completely.
6. Demonstrate
While the end of the transition is a great time to show your results, start demonstrating as soon as you have added value. The optics of the change are as important as the change itself. This is especially true in an environment where you face resistance to change. This may not come naturally to some out of the fear of appearing self-serving. But, showing progress is a great way to gain confidence from your peers and in yourself.
This stage is the reason why collecting information and measuring at the beginning are so important. Management’s question of “So what?” is an extremely effective way of exposing unnecessary work, which your work may appear to be if not backed by hard facts and numbers.
Showing I could reduce the development cycle time by more than 85% is the reason why I got time to improve the process. The results speak for themselves, but the most important part of the demonstration is when your fellow developers speak. When your peers share comments about your work, it often exposes things they were unwilling to say before, such as:
- “This is what development should be like.”
- “I don’t know how I ever tolerated the old process.”
- “Tasks that used to take hours take minutes now.”
- “I thought about leaving (the company) just to get away from this process.”
7. Reflect
Looking back at this long transition, there were many sidetracks along the way. Change takes time. When being a driver for change, it is important to:
- Measure what you are hoping to change.
- Research the problem, and why it hasn’t been solved.
- Plan what you will do to fix the problem and share that plan publicly.
- Transition from the old process to the new, mitigating risks along the way.
- Iterate on the solution: the final state should be even better than the initial plan.
- Demonstrate what you have changed, why, and how much value was added.
- Reflect on what you have learned, and how to better approach problems in the future.
In the end, you will have a great success story, and more than a few more fans wherever you are. In this case, this proactive improvement left the team with an efficient, scalable build pipeline, greater confidence, and a more usable and valuable product.
You don’t have to be a manager, or even a senior to drive change if you do it the right way.
