The main point that I did not see mentioned in this piece is that Deming should only be applied to MANUFACTURING environments, because things like engineering are too chaotic to identify processes or trends in the engineering itself, and trying to control those engineering processes with SPC doesn't really improve the quality of the engineering, it just adds stress, makes things take longer, and probably lowers the quality of the thing that is being engineered.
Obviously, if a quality issue is detected in manufacturing, there may be some steps that engineering could take to improve the manufacturing process and make things stable enough to obtain meaningful statistics. This is part of the Deming feedback process, and part of the System Engineering Life Cycle.
I think you're confusing Deming with statistical process control.
It is true that SPC works best for the non-chaotic parts of product development and manufacturing alike. There are parts of product development that are non-chaotic, and SPC works just fine there, too.
In addition to SPC, Deming had strong opinions on how organisations ought to work and these are relevant also for product development. These are things like
- Understand the underlying customer need.
- The leaders shape the output of the organisation by shaping its processes.
- It is cheaper and faster to build quality and security into the product from the start instead of trying to put it in at the end.
- Close collaboration with suppliers can benefit both parties.
- Have leaders skilled in whatever their direct reports are doing. Use them as coaches normally and as spare workers in times of high demand.
- Collaborate across parts of the organisation instead of throwing things over walls.
- Don't just tell people to do better. Show them how they can do better. Give them the knowledge, tools, and authority they need to do better.
These are just as relevant for product development as for manufacturing. If anything, even more so, thanks to the chaotic nature of product development.
| - Have leaders skilled in whatever their direct reports are doing. Use them as coaches normally and as spare workers in times of high demand.
I think this is the biggest hurdle for US style management produced from the MBA cookie factories. Their only skill sets are MBA speak, assigning blame, taking credit and granting themselves the largest bonuses possible while telling all the actual workers generating value that "due to current financial conditions, your raise is limited to 2%"
It doesn't help at all the US union rules make switching from line work to supervisor work a bad thing. If someone with a union job switches to management they have to start from zero - the company cannot count all those years of experience and so you start at the bottom of the ladder again despite your experience, and your former friends now do mean things to you because you "went to the dark side". It isn't just unions that do the above, but it is the worst there.
> There are parts of product development that are non-chaotic, and SPC works just fine there, too.
Not to detract from your main point, but being non-chaotic is still not enough for SPC to work. Almost all of development tasks have thick-tailed time distributions, even if one is perfectly capable of analyzing them, they are not controllable.
> trying to control those engineering processes with SPC doesn't really improve the quality of the engineering, it just adds stress, makes things take longer, and probably lowers the quality of the thing that is being engineered
Totally depends on the scale. For pizza-sized times with a neighbourhood pizza shop sized impact, sure. Large scale projects without controls & feedback loops in place will fall apart; see: Scaling teams: https://archive.is/FQKJH
If you'd follow some medium to large scale projects (like Go / Chromium), the value of processes & quality control, even if it may seem at the expense of velocity, becomes clear.
The great insight of Deming's methods is that you can (mostly) identify the difference between common and special causes mathematically, and that you should not attempt to fix common causes directly - it's a waste of time, because all real-life processes have random variation.
Instead, what you want to do is identify your mean and standard deviation, plot the distribution, and try to clean it up. Rather than poking around at the weird edges of the distribution, can we adjust the mean left or right to get more output closer to what we want? Can we reduce the overall standard deviation - not any one outlier - by changing something fundamental about the process?
As part of that, you might find out that your process is actually not in control at all, and most of your problems are "special" causes. This means you're overdriving your process. For example, software developers working super long hours to meet a deadline might produce bursts of high producitivity followed by indeterminate periods of collapse (or they quit and the whole thing shuts down, or whatever). Running them at a reasonable rate might give worse short-term results, but more predictable results over time, and predictable results are where quality comes from.
Reinertsen has borrowed more from queueing theory than from Deming. This is not unexpected -- Deming worked mainly with thin-tailed statistics, whereas Reinertsen applied his knowledge to the power laws that show up more in design and development work.
(The two approaches meet in the middle. Deming inspired lean manufacturing which also applies queueing theory. The latter has convenient results both for thin and thick tailed processes.)
The chief problem I have with Reinertsen (and it's not his fault, at all) is how difficult it is to get people to buy in to the idea that cost of delay exists, let alone buy in to measuring it.
Deming's observations and suggestions can be widely implemented.
- Process improvement can be applied all over the place. In how you merge PRs, how you run tests, how you manage sprints, how you deploy safely, etc
- SPC is just used to identify defects. It does not inherently create stress; how you use it matters
- You can identify quality issues in any engineering discipline. High-level method: identify a quality measure ("time to merge PRs", "website is up", "tests are not flaky"), observe it, record the observation, plot it on a chart. Chart trends down? Quality issue. Process improvement cycle to attempt a fix. Chart trends up? Quality issue abated. Must add intelligent study/reasoning though, not just chase metrics.
- Training workers improves output by ensuring there is uniform and correct knowledge of tasks required. Software engineering is particularly guilty of hiring workers without ever giving them specific training, and it results in frequent mistakes from simply not understanding the technology they're using (most devs today will probably never read an entire technical manual).
- Look at the rest of his advice. Drive out fear (improving trust in changes allows shipping more changes faster), improve leadership (help staff improve, don't just make sure they're writing code), break down barriers (improving cross-team collaboration makes changes easier and better), eliminate numerical quotas (focus on quality over quantity makes a better product), remove barriers to pride of workmanship (a dev that makes good code is a happy dev), institute education and self-improvement (brings in new techniques that improve output), take action for transformation (make everyone responsible for improving the org), improve constantly (look for ways to improve, don't coast), etc. All these apply to SWE.
But, it tends to be difficult to find any metric that's meaningful.
For example, increased test flakiness can be a positive sign. I know that seems unlikely, but if you see some spike in flakey tests, it's often a side effect of people adding end to end tests, because some issue made it to production.
At my current job they monitor how long PRs are open, and it appears to mostly be a measure of repository age. Old repositories have more PRs sitting around.
What you really want to measure is "how good is the product?", or "are we delivering quickly relative to the difficulty of what's asked?" and those turns out to be extremely expensive to measure, so people use metrics that don't work well instead.
The core issue with the article is that author mixes up bad management and "fog of management" with the fact that financial results have a disproportionate amount of influence in how things are organised. Every team and employee should do their part to contribute to the financial targets every quarter and within the fiscal year. Which clashes with Deming's points 11b and 12b [1].
The problem is that "every team and employee doing their part to contribute to financial targets", as-stated, is liable to produce suboptimization.
A person on the assembly line can "contribute to financial targets" taking a shortcut, reducing their local spend, but which emerges as a much more expensive problem down the road.
So it's true that every employee should do their part to contribute to financial targets, but defining "their part" is the hard part, something only management can do, and that MBO obscures and tries to make as simple as waterfalling the goal from above.
> Every team and employee should do their part to contribute to the financial targets every quarter and within the fiscal year
The inevitable result of this is however the devaluation of the future. Eg if the statement was true, it'd be the R&D workers responsibility to hand in their resignation ( or their managers layoffs) if their product won't get paying customers within the same fiscal year... And the same applies to any other long term expenditure/investment that company might be considering. E g building a new fab/production line etc pp
So no, that statement of yours is not actually true. It should not be entirely ignored, but it should not become a leading cause unless you want to run the company in the ground.
The statement holds true for a broad set of companies and management styles. I speak from personal experience: the wrong incentives are always there, and they run counter to many things listed by Deming. The obsession with "financial impact" is there with varying degrees, even in functions where it is hard to quantify said impact.
It might not apply to R&D-heavy companies, but we do see engineering companies pivoting into more finance-oriented management. Boeing is one such case and look at the damage.
Having worked on software that runs manufacturing plants your comment echos the idea that too many engineers have that they are "better" than manufacturing and lessons don't apply to them.
Go back to your desk and work on a PR that is going to go through a 20 step process that is constantly changing before a hopefully semi-regular release goes out to customers and tell me how you ignoring all of knowledge on how to do this well is good for your career.
For a long time I assumed folks like you were simply uneducated, but know I see it for what it is, elitism.
Obviously, if a quality issue is detected in manufacturing, there may be some steps that engineering could take to improve the manufacturing process and make things stable enough to obtain meaningful statistics. This is part of the Deming feedback process, and part of the System Engineering Life Cycle.