In this post I present a very basic process for incremental process improvement based upon TQM's "7-Step" process. The goal of this process is to identify a process change that is necessary to eliminate some problem in the development space. It provides a very simple, systematic approach to doing process improvement in an incremental fashion that minimizes developer effort when achieving some measurable improvement in the way the software is developed.
Typically this process is executed by a small team (3-8 people) conventionally known as a Quality Improvement Team (QIT). The QIT is formed to address a particular problem and then the QIT executes the 7-Step process. Not unexpectedly the process has seven steps:
(1) Identify the problem to be solved. The objective of this step is to make sure the QIT understands exactly what the problem is. If it turns out the problem is too large to be addressed in a single increment, then the QIT uses this step to try to prune the scope of the problem to something that is more manageable. If the problem looks like it will take more than about 16 hours of effort per team member to solve it, then it it is probably too large for a single QIT increment. A good rule of thumb is that developers should spend about 10% of their time on process improvement. Another rule of thumb is that at QIT should complete its work in 2-4 weeks.
(2) Collect and analyze data. In this step the QIT collects hard data on the problem. For example, suppose the problem is that there are two many escapes in the software after testing. Data is required to isolate the defects that are the best candidates for proactive defect prevention. That data might include defect frequency and repair cost to determine the defect type with the "biggest bang for the buck".
(3) Root cause analysis. To eliminate the problem one needs to clearly understand how and why the problem occurs. This step is designed to provide insight into what the real underlying cause of the problem is based upon the data from (2).
(4) Plan and implement a solution. In this step the QIT evaluates alternative solutions that might address the problem and selects the one that seems most practical. (The notion of practical includes both the effectiveness of the solution and the cost of solution; a sort of cost/benefit analysis.) The solution is then implemented on an experimental basis.
(5) Evaluate the the solution. The basic idea here is to be sure one doesn't introduce process changes that are not effective or that are otherwise impractical. That is, the QIT needs to ensure that the benefit outweighs the cost in practice as well as theory. If things don't work out as hoped, go back an appropriate previous step.
(6) Standardize the solution. Here the QIT rolls out the process change for integration into the production environment. Mostly this is about communicating the change to everyone it affects and ensuring that it becomes part of the normal development process. The specific things to be done are very dependent on the environment and the change. For example, communicating it to everyone can range from sending an eMail to providing a two-day training class. Another key goal here is to institutionalize the change so that it doesn't get lost. Typically that involves permanent documentation in some central process repository. Again the particular infrastructure will be tailored to the development environment. Basically the QIT determines the best way to roll out the change and then does so in this step.
(7) Reflect on the process. This is a self-correcting mechanism for the 7-Step itself. The QIT evaluates its own performance to determine things like how effective the data collection was and whether the tools employed at each step were effective. This provides insight to the QIT members that they carry forward to other QITs to make them more efficient. If the QIT uncovers something important (e.g., a new tool to use in a step), that can be directly communicated directly to the other developers in this step.
This is a very cursory description. Among other things, I didn't mention any of the tools that can be used at the various steps. For example, in Step (1) there are standard (but optional) tools for gaining consensus (e.g., K-J Diagrams) and organizing the problem view (e.g., Input/Output Diagrams and Flow Charts). For a more detailed description, I suggest reading, "A new American TQM" by Shiba, Graham, and Walden, Productivity Press, 1993, ISBN: 1-56327-023-3.
Though this process seems quite simple and logical, it is deceptively complex when one actually applies it. It also works best when the development processes are already well defined and systematic data collection is already practiced. [A rule of thumb for good metrics systems is that one collects data at one level finer granularity than the metrics require. That allows QITs triggered by metrics to look immediately at data that provides more detail rather than having to collect it.] If you run into trouble applying this process, try time-boxing each step to force progress until you gain more experience. (Incremental process improvement is about nibbling at problems rather than solving them all at once; so it is fair to provide imperfect solutions as a "first cut".) If that doesn't work, get help from a consultant who is a process engineer experienced in such techniques. There is something of a Catch-22 here. If you have difficulty executing QITs effectively, it probably means there are systemic process problems that need to be addressed.