My background is in TQM and lean manufacturing, but I’ve just moved into a Software Quality role. The dev team is using "Agile" and thinks my "Quality Gates" and "Documentation Requirements" are slowing them down. Is TQM even relevant in a "DevOps" environment, or do I need to completely rethink how we measure "Cost of Quality" in a world of continuous deployment?
3 answers
TQM is more relevant than ever, but the "Execution" has changed. In Agile, "Quality" is moved to the "Left" (Shift-Left Testing). Instead of your "Quality Gates" being manual sign-offs at the end of a month, they should be "Automated Tests" that run every time code is committed. The TQM principle of "Continuous Improvement" is exactly what a "Sprint Retrospective" is designed for. You need to stop being a "Gatekeeper" and start being a "Quality Coach." Help them define "Definition of Done" (DoD) that includes your quality standards, so it’s built-in rather than bolted-on at the end.
Dorothy, if we automate everything, how do we maintain the "Evidence of Compliance" that auditors usually want to see in a signed-off physical document?
TQM’s "Customer Focus" is the bridge. Remind the Agile team that "Working Software" is the primary measure of progress, and that requires high-quality code.
Exactly, Sandra. At the end of the day, Agile and TQM both want the same thing: a satisfied customer receiving a defect-free product as quickly as possible.
Joseph, modern DevOps tools like Jira and GitHub generate "System Logs" that act as your evidence. An auditor is actually happier seeing an automated log that proves a test ran 1,000 times with no human interference than seeing a single signature on a piece of paper. Richard, you should focus your metrics on "Defect Escape Rate" and "Mean Time to Recovery" (MTTR). These are the software equivalents of "Yield" and "Rework." If you speak their language, the Agile teams will see you as an ally who helps them ship stable code faster.