Pareto in Software - A Powerful Tool
I often present at conferences on a variety of topics. A habit I've developed is polling the audience for informal surveys. One topic of interest for me is the Pareto Principle or the 80:20 Rule. What often surprises me is the number of software folks who've never heard of the principle, let alone use it as a tool within their project work.
Let's look at the principle outside of software first as a way of defining it. If you had a Toyota Prius warehouse that contained all of the cars parts, you would notice that 20% of the parts take up 80% of the space in the warehouse. You would also notice that 20% of the parts make up 80% of the overall vehicle cost.
That is the essence of the Pareto Principle or 80:20 Rule—that 20% of something has an 80% overall impact. Now let's bring that principle back into software projects.
Defect Clustering
There are a couple of ways to leverage Pareto in your software projects. The most obvious one involves defects. The principle clearly comes into play in defect clustering or the natural tendency for 20% of the components (or features or architectural layers) of any product to produce 80% of the defects. If you can clearly identify these fault prone components up-front, then you can focus your project efforts towards cleaning them up—thus reducing project risk and improving overall product quality.
From a pure testing perspective, you should focus a majority of your testing efforts on these areas. Initial testing should focus on partitioning defects and identifying the initial Pareto state for the application. Once you've determined your initial risk state—testing should be earlier, more frequent, and more thorough in these areas. You also need to monitor the Pareto distribution over time, as it will typically change as the application evolves.
From a process perspective, you can also influence more unit testing and inspections as a way to improve the overall quality in these areas from a development perspective. The point is though – focus your energies where they have the most overall impact to the product.
Code Construction
Pareto takes another turn in simple construction. It implies that 20% of the product will take 80% of the time as well. This then should affect your composition strategy and project planning for development. You'll probably want to front-load those 20% components early in the development schedule and clearly identify those tasks—throughout the team.
You might also want to assign some of your best software developers to work on those components.
Team Capabilities
Another area where Pareto rears its head, and it's probably the most controversial, is within your team capabilities themselves. If you truly buy into it, then 20% of your staff is performing 80% of the work. Plus or minus J I think we all realize that high impact developers are much more productive than others, but applying the 80:20 Rule to it really amplifies the importance.
Nonetheless, I'm convinced the rule works here as well. And teams need to become comfortable with this relationship and leverage it to their advantage. In this case, critical work assignments, both in Pareto area, overall scope and complexity, should be skewed toward the best resources.
So how do you implement Pareto analysis?
The challenge with Pareto in all of the above cases is early identification of "the 20%" and how to do that. Arguably the easiest application is defects. However, even there you need to identify the right number of Pareto categories, then correctly assign incoming defects into the categories before you can apply the technique. Only then do you gain insight into the distribution of defects over relevant component areas so that you can take action. It also takes additional time and effort to setup for analysis. I would argue its worth it, but it does take more time.
It gets much more hairy when you try and apply Pareto to your teams. Some of the challenges include:
- How do you identify your high impact performers?
- And identify the specific technology areas where they are the strongest?
- Then map them back to tasks on the project at-hand?
- While not demoralizing the remainder of your team?
- And assign them challenging work as well?
- That together drives the project towards optimum completion, while properly using your teams capabilities?
Applying Pareto within teams for work assignments requires a much more subtle hand and strong leadership experience. Again though, the payback can be tremendous as you effectively focus the skill evels of your team uniquely towards specific project challenges.
As it turns out, 6th Sense Analytics can help you explore Pareto in all of the above cases. You can view individual and team data as it applies to all of your projects. Active Time and Flow Time metrics will illustrate team capabilities towards contributed and produced project artifacts--including defects, construction and team performance. We amplify insight at 6th Sense and that insight can help you in Pareto Analysis as you make much more powerful adjustments within your teams. And as you're analyzing the data for Pareto, please keep in mind our EDA model as a framework for that analysis.
Previous Post:
PROBE or PROxy Based Estimation Using Active Time
Next Post:
Innovation happens with 6th Sense
