The Problem of Out-of-Sync Processes
What a team actually does never matches the adopted process. Teams improvise and invent more effective ways of doing things; they find they need to work out solutions to problems nobody thought of when the process was selected, and they never keep the process descriptions up to date.
Often, there are complaints when a team seems not to be following the defined process. However, these complaints miss the point. The point of software development is to develop good software, not to slavishly follow a predefined process.
If you have ever been involved in a process assessment, you know that what the team does rarely matches the official process. This is true of all processes. People use a mixture of ideas and practices from various sources, and although they might claim to be advocates of specific processes, few of them are actually following them to the letter.
This gap between the process as described and the process as applied is what we call the "project-process" gap. This gap causes problems for projects, teams, and organizations:
- When a team is successful, it becomes difficult to spread that success to other teams. If another team takes the successful team's process and applies it, the new team won't get the same results because the process description doesn't describe what the successful team has really been doing.
- It makes it difficult to plan, estimate, monitor, and control projects. The project-process gap often causes a noticeable project-plan gap to appear. It also becomes far more difficult to improve the process, compare projects, or automatically capture measurements.
- Process and quality assurance becomes less effective and more expensive. The assurors spend lots of time looking at the process rather than at what the people actually do. The gap can even lead teams to waste a lot of time trying to achieve the illusion of process conformance—especially when they realize that they are about to be assessed.
- Teams often find that they have to spend large amounts of time filling the gap by writing lots of additional process documentation; for example, creating local requirements management plans and configuration management plans. This local process documentation is presented separately from the process, and often contradicts or overrides large amounts of it. The end result is that no one really knows what process the team is applying.
- It becomes far more difficult to improve or retool the project environment as it is unclear how the team is actually working. Tools are often imposed on the team that support the process description but not what the team does or needs to do. This results in either the tool never being used or a lot of time being spent learning how to configure and change the tool to do something it wasn't designed for. In some organizations, using the tool starts to become more important than doing the job; this is when you know that things have really gone wrong.
The process should be a description of what the team actually does, rather than a fictional description of what people think the team ought to be doing.
