Percent CA (%CA) is a great little tool that is a huge part of process mapping, and speaks directly to the quality of the work that your teams are doing.
What is %CA?
You are capturing two different aspects of the work: speed and quality.
For some context, process mapping is considered to be one of the best ways to approach lower-quality devops implementations and discover where the best places are to leverage your efforts. After you have drawn out your process map the next step is to start looking at cycle times and the quality of the work; which is where %CA comes into play.
Cycle times and %CA both have corollaries on Scrum teams. When working with the Scrum team, you are using velocity to predict speed, but then you also look at bug generation to determine the quality of the work that is done. You are capturing two different aspects of the work: speed and quality. When you are working with a process map you use cycle time (total process time + total wait time) to talk about speed and %CA to talk about quality.
Formally, the %CA number is titled, "Percentage Complete and Acceptable". This represents how much of the total work is not only completed by the current stage, but acceptable by the following stage. Obviously, work that is not completed or reject by downstream stages will impact this percentage.
The number is captured for each stage of work, and the numbers from each stage can be multiplied together into a single number (Total %CA, or T%CA) that represents the percentage of all work that can flow through your process without being rejected somewhere along the line. Since we are multiplying percentages this final number has some interesting characteristics:
- Low scores on any one stage have an outsized effect on the T%CA number. The first time I captured this with a team, we had one stage with a %CA of 25%! While that is obviously a problem all its own, this single stage depressed the T%CA down into single digits!
- T%CA resists changes in any single %CA. When you are dealing with averages, a single low number can depress the average, but simply improving that low number will lift the average just as strongly; not so here. Because we are multiplying a percentage of 100, we have to lift all of the stage numbers into the higher ranges to feel an equivalent impact in T%CA.
Because of the above, you will want to pay strong attention to your %CA and T%CA across the entire range of your process map; but realize that any single-stage number that is low will strongly impact the total number. Get them all as high as you can.
I created a model of a process map with inputs for Process Time (PT), Wait Times (WT) and %CA across five stages of work. For the purposes of this model I've made a few assumptions, but overall I am confident that the model hits the 80/20 sweet spot for accuracy without requiring that I get my phD before compiling it. As if that would ever happen.
I'll be going over the model in details in upcoming posts, but there are two big takeaways from it. Take a look at these graphs…
Results from the model state that changing either PT or WT by equal amounts has identical impacts on the total cycle time of the process. In other words, the two are functionally equivalent for our purposes. However, which stage gets its times altered does not have equal impacts on the results.
As the chart shows, altering speed at the earlier stages has a larger impact on overall delivery times than altering it at later stages. This makes sense because of the assumption that rejected work travels all the way back to the left; therefore those left-most stages would be traversed by more of the work than the right-most.
This makes sense in the context of a development team. Regardless of where the issue was found, it will usually require someone with coding skills to solve, and those skills tend to sit to the left of the workflow. Of course, there are exceptions, but I believe that this represents the functioning of most development processes.
Another variable that we can play with is the actual %CA numbers at each stage. Running through the same steps as above we get the below graph:
This is the opposite behavior than what we saw above, and this, too, is explainable. The further to the right in the process that we are, the further we have to travel if we're rejected. Remember that for the purposes of our model we hold that rejected work goes all the way back to origin. While this may not be specifically accurate for your scenario, I believe the learning holds true. This would mean that improvements at the quality level have a higher impact if they are performed later in the stages.
What Did We Learn?
Modelling this sort of behavior can be difficult, but if we are looking for guidance on where to start improving a work process, then this model has yielded the following four items:
- Time is Time. You can improve either process time or wait times and have an equal impact on overall times.
- But not all time is the same! Improving times earlier in the process is better than later.
- Quality represents invested time. Rejects caught later in the system cost you more than rejects caught earlier.
- Quality matters, wherever it is. In order to achieve a high T%CA you will have to have high quality work throughout the process.
Soon, I'll post an indepth examination of the model, for those of you interested! Please sound off below on how you think this knowledge can impact your work and that of your teams!