W. Edwards Deming did not write for Scrum teams or continuous deployment pipelines. He wrote for managers who wanted to build systems where quality and learning could thrive. Yet when you look past the jargon of modern product development, the bones of agile leadership mirror Deming’s thinking. If your standups feel like status theater, if velocity charts drift higher while outcomes stall, if quality debt keeps resurfacing no matter how many sprints you pour into it, Deming’s 14 points offer a sharper compass than six sigma cost savings another framework diagram.
I have watched teams revive delivery predictability in less than a quarter by returning to Deming’s basics. I have also watched organizations layer on new rituals and dashboards while ignoring the harder cultural work behind them. The difference shows up in lead time charts, customer retention, and the tenor of hallway conversations. When people stop quietly gaming metrics and start improving the work itself, you know you are walking Deming’s path.
Below, I translate Deming’s 14 points for modern agile organizations, with examples from software and product operations. Not every point maps cleanly, and some bite. The value lies in the tension.
Constancy of purpose in a backlog-driven world
Deming’s first point is constancy of purpose toward improvement of product and service. In agile shops, constancy often loses to churn. The roadmap shifts after each executive meeting. Backlogs balloon. Teams work on different definitions of “done,” then rush to rework.
The fix is not rigidity. It is a disciplined throughline from mission to outcomes to work. I once coached a payments platform that set a three-year purpose around “trusted, invisible transactions.” That purpose anchored quarterly outcome targets like “less than 5 basis points payment failure rate” and “sub-200 ms median authorization time for 95 percent of traffic.” Teams were free to test approaches, but they could not wander off into shiny tools or pet features. Their backlogs got thinner. Their release notes got shorter and more meaningful. Within two quarters, failure rates dropped by half and complaints about inconsistent APIs fell sharply.
Constancy does not mean the same roadmap for 18 months. It means the same north star and a willingness to stop anything that does not serve it.
Adopt the new philosophy: quality as the job, not a phase
Deming asked management to adopt a new philosophy that rejects acceptable levels of defects and delays. Many agile teams still treat quality as a gate someone else maintains. The language betrays it: “handoff to QA,” “QA sign-off,” “we’ll fix it in hardening.” Those phrases preserve a waterfall culture with agile trappings.
The new philosophy in a product context means developers write tests as they code, product managers sit with support to hear pain first-hand, and operations pairs with engineering on failure modes before launch. A mid-size SaaS company I worked with removed their “integration test team,” folded those engineers into product squads, and invested in fast, reliable test environments. Their test runtime dropped from 90 minutes to 14. Escapes to production fell by about 60 percent within three months because the people who built the code also owned its safety nets.
Adopting this philosophy has a trade-off: initial throughput slows while systems and habits change. Leaders have to protect that space or teams will slide back to old norms at the first slipped milestone.
Cease dependence on inspection to achieve quality
Pulling bug counts down by adding more end-of-line inspection looks tempting. It is measurable and gives the sense of control. Deming warned that inspection never adds value, it only sorts the good from the bad after cost is baked in.
Agile teams have better options. Design for testability is one. Contract testing across services is another. Feature flags that decouple deploy from release are a third. In a marketplace platform with dozens of microservices, we reduced post-hoc manual testing by consolidating on consumer-driven contracts and golden datasets. False positives in integration tests dropped, and release managers stopped holding late-night test parties. The regression rate did not creep back up because the contracts lived with each service and evolved with its API.
Beware the trap of replacing manual inspection with brittle automation. If your pipeline fails randomly 10 percent of the time, engineers will click “re-run” until green and tune out the signal. Reliability of tests matters more than quantity.
End the practice of awarding business on price tag alone
Translating Deming’s fourth point to product development means ending the habit of choosing tools, vendors, or even offshore partners on day-one price. I have seen organizations standardize on the cheapest CI provider, then spend hundreds of engineer-hours fighting build queues and timeouts. The real price was hidden in cycle time and morale.
When teams evaluate external services or even internal platforms, include run cost, learning curve, integration friction, and change agility. A team that picked a slightly pricier database option with first-class observability and online schema changes saved weeks of planned downtime and midnight cutovers. Total cost looked higher on paper, total value looked higher in customers sleeping through maintenance windows instead of complaining the next day.
Procurement policies sometimes force price-only choices. If you cannot change the policy, quantify the delay cost. Convert wait times into lost revenue, not irritation. Executives listen when you translate tech friction into dollars per week.
Improve constantly and forever the system of production and service
Continuous improvement is a buzzword until it shows up on calendars and in code. The best teams I know reserve time every sprint for small kaizen improvements and set aside periodic deeper investments that require cross-team coordination. They treat the delivery system as a product of its own.
One global team built an experiment pipeline to cut unsafe ad hoc testing. They reduced mean time to restore from 90 minutes to under 20 by practicing game days monthly. Another team retired a third of their flaky tests by spending a week profiling and stabilizing suites. It looked like a detour. It paid for itself in the next release train by removing dead time.
The trade-off is visible feature delay. If product leadership does not message why systems work matters, teams will hide it under vague backlog items and underfund it, creating the worst of both worlds: less feature progress and no meaningful improvement.
Institute training on the job
Deming’s sixth point is not a slide deck. It is guided practice. Pairing, shadowing, and micro-apprenticeships turn tacit knowledge into shared capability. In one API team, every new engineer spent their first two weeks pairing on bug fixes and production support. They learned the domain faster than any onboarding course could teach. They learned where logs lived, which dashboards mattered, and which quirks the SDK glossed over.
Formal training has its place, especially in security and compliance. The mistake is thinking you can mandate competence via coursework. Real training looks like a senior SRE coaching a developer through a runbook during a live incident, then debriefing what signals mattered and why. It takes time. It repays time by reducing the call tree when something breaks.
Budget cycles often cut training first. Fight that. If travel is tight, rotate internal brown bags and coding dojos. Track outcomes such as defect containment and on-call escalation rates, not attendance.
Institute leadership, not supervision
Managers in agile organizations sometimes become back-office schedulers and report consolidators. Deming insisted leadership exists to help people and systems perform, not to enforce compliance. The difference is practical. A supervising manager asks for burn-down charts by end of day. A leader asks what is blocking flow and stays until the constraint moves.
I worked with a leader who spent an afternoon each week sitting with a different team, no agenda. She asked engineers to walk her through their pipeline and their pain. She cut through a three-month wait for a staging cluster by calling a peer in infrastructure and offering her team’s engineers for the migration work. It was not a status meeting. It was leadership as obstacle removal.
When managers chase metrics without understanding the work, teams learn to stage numbers. When managers coach and protect space for improvement, teams bring up risks early. You get what you reinforce.
Drive out fear
Fear corrodes agile faster than any tooling gap. It makes retrospectives polite and useless. It hides incidents until they explode. It creates busywork to look productive and safe. Deming’s call to drive out fear is literal.
Two moves change the atmosphere. First, treat near misses as gold. A mobile team at a health-tech company nearly shipped a broken privacy setting. They caught it in staging by chance. In a fear culture, that story would sink. Instead, the director asked the team to present the near miss at the next engineering forum. They walked through the hole and the fix. Other teams found similar risks and patched them within a week. No one was shamed. Everyone got safer.
Second, make it unremarkable to say “I don’t know.” During an incident, the best incident commanders I know ask each role to state what they see and where they are unsure. Certainty theater wastes minutes. In one outage, a database engineer said, “I don’t know why replication is lagging, but I see CPU steal going up.” That honest uncertainty led the team to a noisy-neighbor issue on the host in two minutes. A culture that punishes not knowing would have gotten a bold but wrong answer and a longer outage.
Break down barriers between departments
Agile frameworks talk about cross-functional teams, then layer reorgs that split responsibilities across distant groups. Product writes PRDs, design hands off Figma, engineering commits code, security arrives at the end. Defects and resentment grow at the seams.
A better pattern is to form teams around outcomes and give them the right shapes of talent to deliver those outcomes. On a search relevance team, data scientists sat with backend engineers and product managers. They shared dashboards and lived in the same on-call rotation. When ranking quality dipped after a feature release, no one argued over ownership. They debugged together. Time to diagnosis dropped because they had the same context.
Not every function can sit on every team. Security, legal, and finance span the org. The barrier-breaking move for platform functions is to publish roadmaps, SLAs, and contact points, and to embed for a sprint when a consuming team is doing risky work. One security engineer embedding for two weeks during a payments launch prevented a class of token storage mistakes that had burned the company before.
Eliminate slogans, exhortations, and targets for the workforce
You cannot poster your way to quality. Deming saw slogans like “zero defects” as noise that blames workers for systemic limits. In product teams, slogans show up as OKRs that target output disguised as outcomes, or as executive emails that demand “no more P1s” while cutting staff.
A fintech company I supported kept missing a stretch target of “reduce onboarding time by 50 percent.” Teams hacked at forms and UX copy, then stalled. When leadership stopped repeating the slogan and funded a cross-team effort to build a unified KYC service, onboarding time fell by 40 percent in one quarter. The target did not move the needle. The system change did.
If you must set targets, tie them to changes in process and platform. A useful target reads, “Migrate 80 percent of services to standard auth by Q3 and deprecate legacy endpoints,” not, “Improve NPS by 10 points.”
Eliminate quotas and management by numbers, substitute leadership
Velocity, story points, code coverage, and deployment counts make fragile proxies. Managed poorly, they act like quotas. Teams then inflate estimates, split work unnaturally, or rush changes on Fridays to hit a release count. You can feel it when standups turn into rehearsed status lines and retros drift into defensiveness.
Replace proxy quotas with a blend of observable outcomes and qualitative signals. When we shifted one department from “points per sprint” to “median lead time, change fail rate, and customer issue rate,” teams relaxed around estimation theater and invested in better slicing and testing. They also started telling richer stories about risk. Quality went up without a single pep talk.
Numbers still matter. Use them as instruments, not as leashes. Review them with the people doing the work and ask what they are seeing behind the trend. When a team’s lead time rose for two sprints, they explained they had introduced a new integration test suite. Leadership recognized the temporary cost was buying permanent signal.
Remove barriers that rob people of pride of workmanship
Few things crush pride like fixing the same defect class month after month because the platform will not move, or shipping features that customers do not use because success is defined as “done,” not “valuable.” Deming wanted people to feel responsible and able.
Two practical levers help. First, give teams control knobs. When a team can tweak autoscaling, adjust alert thresholds, and manage their error budgets without opening tickets to three other groups, they experience their own craft. Second, bring the customer into the team’s line of sight. Support ride-alongs, product analytics that show adoption and drop-off, and periodic customer calls change how engineers talk about trade-offs.
We piloted “customer notes” in PRs for a consumer app, one or two sentences in plain language stating the user impact. Engineers started arguing less about code style and more about whether the behavior matched the promise. Defects went down, and so did the loops between design and build.
Institute a vigorous program of education and self-improvement
This point goes beyond training. It is the investment in people beyond their current sprint scope. In practical terms, fund conference attendance, internal rotations, and certification paths that map to real responsibilities. A staff engineer who spent a quarter embedded with the data platform team returned to her product team with a deep grasp of data lineage. She pushed for and implemented event versioning patterns that prevented months of analytics confusion later.
Self-improvement also includes leadership skills. Many senior individual contributors struggle not with architecture, but with influence. Set up mentoring circles, give them air cover to lead cross-team initiatives, and recognize that impact, not title, is the currency.
Budget pressures will hit here. When money tightens, share responsibility for choosing what to keep. Teams who co-design their development plans are more creative at finding low-cost options, such as internal unconferences and recorded course libraries, and more committed to using them.
Put everybody in the company to work to accomplish the transformation
Deming’s final point speaks to culture change as shared work, not a memo from the top or a grassroots rebellion from below. In agile terms, that means executives model behaviors like attending post-incident reviews to learn, not to assign blame. It means HR and finance adapt performance and budgeting systems to support stable teams and long-term learning. It means platform teams publish roadmaps and accept outside contributions. And it means engineers and product managers hold themselves to the same standards they ask from their peers.
One company started monthly “system health” reviews that included engineering, product, support, sales, and operations. They looked at production incidents, support tickets by category, and deployment patterns. Each function left with one improvement they owned. Sales agreed to stop promising custom fields on short notice. Engineering committed to deprecating a fragile webhook. Support revised macros that nudged users toward dark corners of the product. It was uncomfortable at first. It became the most valuable hour of the month because it distributed transformation across roles.
Where agile practice most often drifts from Deming
Agile ceremonies are easy to schedule and hard to inhabit. The drifts I see fall into a few patterns.
- Backlog refinement becomes a sprint-lengthening exercise in parceling points, not a thoughtful shaping of work to deliver learning earlier. When teams slice by component instead of outcome, queues and handoffs bloom. Retrospectives become ritual autopsies of small cuts while the big system constraints stay untouched. Teams need executive sponsors willing to move org-level blockers, such as underpowered environments or conflicting priorities from two VPs. Incident reviews devolve into fault assignments or slide decks with the right words. A real review produces a handful of specific changes in code, configuration, or runbooks, and someone loses the pager duty for a week to make sure those changes land.
Notice how each drift contradicts a Deming point. Parceling points turns numbers into quotas. Toothless retros ignore system improvement. Blame-centered reviews drive fear back into the room.
Practical ways to start, even in a messy org
You will not convert an entire company overnight. You can, however, apply Deming’s thinking at the team level and create pull.
- Run one experiment that trades inspection for design. For the next two sprints, invest in improving your contracts and test data, and reduce end-of-line manual test time by half. Track escapes and developer cycle time. Share the results with peers. Replace one proxy target with an outcome. Instead of “deliver 120 points,” try “reduce median lead time from 8 to 5 days.” Ask leadership for cover to make system changes that support it, such as faster builds or fewer handoffs. Make fear visible and movable. In your next retro, ask, “What did we not say last time?” Then pick one fear source you can change, such as removing a public leaderboard that compares velocities. Invite another function into your work. Ask design or support to join backlog refinement for a month. Ship one improvement that came from their vantage point. Amplify the story.
Small wins matter because they show Deming’s ideas are not philosophy class. They change deployment calendars, customer email volume, and on-call sleep.
Revisiting the 14 points, briefly, through an agile lens
Deming’s list is often called deming 14 principles, and some readers want a succinct correlation. Here is the short mapping I use when teaching product leaders:
- Purpose anchors the roadmap, not the other way around. Quality is built in at each step, not inspected at the end. Supplier and tool choices weigh total cost and integration, not sticker price. Improvement is the day job, not a backlog label. Training means guided practice in context, not just courses. Leadership removes constraints and cultivates learning. Psychological safety enables speed and truth. Cross-functional teams own outcomes, not departments owning stages. Slogans do not ship value, system changes do. Metrics guide inquiry, not punishment. Pride comes from autonomy, mastery, and connection to users. Education includes depth, breadth, and influence. Everyone owns the system, from execs to support.
That list reads cleanly, but the work is messy. Two tensions show up repeatedly. First, investing in system improvement competes with feature demand. Senior leaders must hold the line and frame improvement as feature enablement, not feature delay. Second, decentralizing decisions raises inconsistency risk. The way out is to standardize a few high-leverage interfaces and guardrails, and allow variation elsewhere. Think paved roads for auth, observability, and deployment, freedom for domain logic.
A few numbers that move when Deming’s ideas take root
I have seen the following ranges many times after teams lean into these principles for a quarter or two:
- Lead time for change typically improves by 20 to 50 percent once test reliability increases and handoffs fall. Change failure rate often drops by a third when inspection is replaced by better contracts and environment parity. Mean time to recover can halve with regular game days and better on-call routines. Employee engagement scores around “I can do my best work” and “cross-team collaboration” rise by 10 to 20 points when barriers fall and fear recedes.
These are not guarantees. They assume leadership participation, not just team heroics. They also assume you measure baselines honestly. If your current lead time is estimated by gut feel, start by instrumenting. Numbers are more persuasive when they are trusted.
What to watch for so you do not backslide
Change fatigue is real. Three things tend to pull teams back into old habits.
First, personnel churn. New managers who were rewarded elsewhere for hitting quotas will reintroduce them. Onboard leaders to your philosophy explicitly. Share your operating principles and the stories behind them before they ask for a dashboard of points.
Second, incident spikes. A tough month of outages can tempt leaders to clamp down on experimentation and reintroduce inspection gates. Hold your nerve. Use the incidents to sharpen learning loops and harden guardrails, not to blame.
Third, executive impatience. When the board asks for quarter-over-quarter growth, the temptation is to demand output targets. Translate Deming into revenue terms. Show how faster lead time and lower failure rate increase capacity and conversion. Tie safety and quality to dollars with credible math.
The quiet power behind sustained agility
Agility that lasts looks boring on the surface. Fewer emergency meetings. Fewer heroics. More predictable delivery, steadier quality, fewer surprises. Inside, it hums with curiosity, craft, and clear-eyed trade-offs. Deming’s 14 points did not come from a world of cloud regions and mobile user bases, yet they fit modern product work because they describe human and systemic truths. People do better work when they know why it matters, when they can shape their tools, when they are not afraid to speak, and when leaders invest in the system instead of measuring the people into corners.
If your agile practice feels brittle, try treating Deming not as a history lesson, but as a field manual. Pick one point. Make it visible. Change one habit. Then another. The patterns will start to reinforce one another, and the noise will begin to drop. That is when the real speed shows up, not in points per sprint, but in value delivered without drama.