Teams create processes to maintain repeatable results. Process is necessary. But when the process needs adjustment, teams often take the quick route and just add more and more to their process to address their new problems. The result is often process bloat, frustration, and project inefficiency. Then the team is back where it started.
Processes are typically built to get work done consistently and to increase efficiency and reliability. Improving a process however, can be time consuming and is more often avoided. So teams take short cuts. Here is an example that might sound familiar for a team that uses a process to checkin code. 1. Create unit tests to validate your code 2. Rebuild code with latest source code 3. Validate local build with unit test suite 4. Checkin new code and new tests.

The team discovers that some new code does not align with the design patterns that have been established so they add a rule to review all new code with the design leader. The team gets behind on updating older release versions with new code changes so they add another rule that requires that they follow the same rules for all the older release lines. Sooner than later the process to checkin code becomes so cumbersome that developers avoid it until the last possible moment.

Many of the best planned processes suffer this fate. But how do you avoid it? And what do you do if you see it coming? Agile has roots in kaizen, from the Japanese word for continuous improvement. In Mathew May’s book The Elegant Solution (167), he suggests that you should create a standard, follow it, and determine how to make it better. And then repeat that process. The standard provides the starting place but it should be adjusted to work better and to meet the changing needs of the demands. So having a process is good. Adjusting the process is good. Continuously improving the process is even better. But continuously adding steps to the process…? Not so good.

Here is one idea that I’ve found helpful: When you create a process, define measurable goals for the success of the process. For example, “We need a consistent process to checkin new code that takes no more than 10 minutes and enables 95% build success per iteration." If the team needs to add a code review to the process, then how can they manage it as part of the checkin process? Well, one team I know of faced this very situation and decided that they would spend 30 minutes every day at a particular time to do team code reviews. No matter what stage the code was in, the developers could get their code reviewed. While it still required time to do the reviews, that step was removed from their checkin process.

The key idea is to include a measurable goal for your process when you define it. Then stick with that goal when you change the process. Including a metric that defines process success requires that you look for ways to incorporate new requirements and continue to meet the metric goal. It may involve a little more work but it will ensure that the process continues to solve the problem without becoming the problem.

If you have any ideas on how to avoid process bloat please respond to this blog post and share your ideas!