How to Make Process Improvement Effective

<a href="https://betterprogramming.pub/the-engineering-manager-tools-9bc0d738294d" rel="noopener ugc nofollow" target="_blank">Process improvement is one of the main tools for Engineering Managers</a> (EM) to manage their team. Delivering commercial software involves <a href="https://medium.com/better-programming/there-is-always-a-system-16868e1e1a3f" rel="noopener">overlapping multiple systems</a>, and acting on them effectively improves the team’s environment and results. However, processes can also easily hinder effectiveness. Too much focus on it can restrict the team and its members, and poorly applied techniques can also have negative results. There is no better way to understand that than looking at the current industry perception of the Agile movement. What was a change to focus on iteration and flexibility became a synonym for rigid and ineffective structures. That brings a dilemma to managers. If process improvement and standardization are tools that can benefit teams, how can they be applied without creating restrictive environments? To discuss that, let’s first look at the two sides of this coin. <h1>Process Improvement as a Tool</h1> Nothing is more challenging (and ineffective) than improving an unstable system. If there isn’t a repeated process to improve, trying to respond to problems becomes a game of whack-a-mole. That’s because the only way to act on a team without changing the system is by influencing the team members. For example, a team might experience a severe production incident. They go through a postmortem and identify that the code change that led to it didn’t have enough reviews. In an individual-centric environment, the manager would talk to the person who made that change to agree on an improvement plan. Then, the manager would observe to ensure their employee follows the guidance. If this sounds like micromanagement, it’s because it is. All this effort will only improve the changes delivered by one person. If the same situation occurs in a more stable environment, the EM has a better leverage point because the team has a structure that defines how they review changes. They could update the review guidelines to include better procedures, or if that is already done, they could discuss how the team is following the guidelines again. If they do it successfully, all the engineers will review changes better. By acting on the system, they can improve the whole team, not only a specific individual. In the second case, the problem is solved, and everyone is happy. But are they? <a href="https://betterprogramming.pub/avoiding-bureaucracy-d45fe319bc90">Visit Now</a>