Saw this on twitter...I actually think SPC can apply to Software Development in that the concept of normal variation, and being able to understand and measure the range, can be pretty useful. More detailed comment here if interested...
Came across this on twitter. Here's why I think SPC is related to Software Development (and Agile concepts, particular the burndown charts) more generally:
To be clear, they are related but not the same use case. IMO, both Agile and SPC leverage the same insight: variation is inevitable: what matters is not that it exists, but how you deal with it.
With SPC, you are establishing a normal variation so that you can identify abnormal activity that is warrants further investigation.
With Agile you're not really looking for outliers per se, it's more that you want to get to a place where your "normal" variation is a much smaller range. Because a smaller range leads to better quality and more output:
Variation in the software dev context is the difference between your estimates and the actual work required to deliver a feature, etc. High variation means you're constantly in a rush, need to cut corners, need to cut scope, etc.
This has a lot of downstream impacts in terms of quality but also in the actual scope of what you can deliver. In short, you need to spend more time fixing bigger problems.
Less variation means smaller problems and less time spent fixing --> more time is allocated to new feature development.
(and separate topic, but variation in Software dev has a special property where it only accrues in the "takes longer" side vs. the "take less time" direction. You never "make up time" because something is quicker than your estimate. see note below.
So the burndown chart is less about enabling you to see outliers, more providing visibility to the variation so that you can work towards making it smaller. If you're constantly loading work in the end of the sprint, you have a problem with the scoping process.
How does that track back to Agile?
One the key elements of Agile process is breaking work down into smaller batches --> and Breaking things down into smaller batches is* they key mechanism to reducing variability.
NOTE:
*Software pretty much only takes longer than expected because there is high visibility into the fastest something can be done, but very little visibility into the unexpected things that can add scope to the project. So it's extremely rare for something to happen that make it take less effort than your estimates, but very common for things to add scope.
It's similar to estimating how long it will take to drive somewhere: you can get a pretty accurate sense of the fastest it will take based on distance and speed. But the things that extend the duration of the trip, like a car accident or unexpected road work, are just much more unpredictable. So if you were to plot that variation on a chart, you only see it move in one direction.
https://news.ycombinator.com/item?id=39651368