Would W. Edwards Deming have a QA team if he ran a software company?

Would W. Edwards Deming have a QA team if he ran a software company?

For those of you who don't yet know where all this Agile stuff REALLY got started, here's some homework. reference: http://en.wikipedia.org/wiki/W._Edwards_Deming. The entire nation of Japan might be justified in thinking he's a pretty important guy. When I came across that article and it immediately forced me to question how any company that chooses to claim Agile development practices can have a QA team. My world was rocked just a little.

Fascinating bit of history there, isn't it? If you're cheating and haven't yet read that article while simultaneously not yet knowing the man, his philosophies on Quality, and are simply reading my blog post further, you're cheating. Seriously go read it. I'll wait.

For a quick summary, here are some important points to Deming's methodology:

1. Quality is everyone's responsibility
2. Eliminate quality control
3. Encourage quality over quantity
4. On-the-job training

In reading through that article and coming back to it from time to time, I've had the chance to crystallize some thoughts surrounding his philosophy. In general my perspective has evolved and these thoughts express how I see things working best, particularly in a mobile-first, software-as-a-service world.

Quality is everyone's responsibility

This one's an easy one. That statement warms my heart even if it comes from a man who would eliminate my job description entirely. I completely agree that Quality (notice the capital) is not the sole concern for the last guy in the production chain before a product ships. It's roots are set down by designers, strategists, and prototype developers who know how to identify risks and refine ideas and designs early in the production cycle. It must be actively and thoughtfully maintained by each person throughout the life-cycle of the project. It goes beyond just pride in your work by acknowledging the impact of your work on others and their work as well.

Eliminate quality control

I take this to mean remove it as a "final check" procedure and replace that with constant evaluation at every stage in the production cycle. This is reflected in practices such as Continuous Integration where developers are not off in the weeds on their own branches for extended periods of a project but instead aware in real-time of the impact their code changes will have on the overall project through constant testing.

I take it to mean that because I'm a QA Engineer, by profession. In some contexts you could correctly identify me as an SDET, in others a build engineer, in others a tester. It keeps my life at work interesting but the constant struggle to push for bugfixes can create tension between those in my role and those trying to ship a product quickly.

If you reference the Agile Manifesto's people vs. process line, that means identifying where your team believes a quality control process or drone will save them from shipping bugs. This is a Huge Problem(tm) for traditional companies to even imagine addressing. They have QA Managers, they have nice graphs, there are test plans, there are tool-chains (HP Quality Center et al)...  ...there is so much built around the notion that QA is a team, separate from the function of the rest of the team that it is easy for people to think QA is responsible for eliminating bugs. I've been asked "why didn't you catch that?" The developers in the room weren't asked "why did you write that?" It is insidious how much the over-emphasis on process offloads the responsibility for Quality onto the hilariously inappropriately named QA team. Just be a tester. Be a Quality evangelist too. But really, just be a tester. Everybody.

Encourage quality over quantity

My work is making it easier for engineers to demonstrate the success of their code by providing faster, more actionable feedback from tests. I'm able to prove the importance of quality by making it alive in detail through CI. The irony is that many in my profession are sent on Sisyphean missions to create piles and piles of test cases. Those responsible for ensuring quality can sometimes be tempted to generate test results from endless test plans and test cases to feel confident in a high standard of quality.

On-the-job training

Interestingly, this is one area where the software industry has the easiest opportunity and behaves the worst. On the one hand collaboration tools and pair-programming practices have made it very easy for senior engineers to mentor junior engineers and improve the quality of the team's output WHILE WORKING. On the other hand over-specialized job requirements (see the growing number of job requirements for "full-stack" engineers) and the purple-squirrel mentality in HR put pressure on the individual to come to work fully trained, with a demonstrated history and capability in every possible area where the company may need work done. Companies that invest in their employees and have systems in place that enable their employees to invest in each other do well here. I'm not talking about endless PowerPoint decks with hours of text to pour through. I'm talking about giving and receiving constructive criticism, portfolio reviews, open study, etc.

Final Closing thoughts

In the course of my post-college career in quality control and test engineering, I've worked in many industries though mostly software. These principles are universal. In order to really take advantage of these principles though, you need an organization that plays the long game. The sad fact is that with careers at any given company often spanning 2 years or fewer, with behaviors that are meant to optimize performance only over the short term, with pump and dump stock-price-motivated CEOs, investment in these principles is a tough sell. However despite having only recently learned about this Deming fellow and despite having an occupation he would certainly eliminate if he ran the company where I work, I find myself compelled to agree with his principles. I don't see myself as a test case wrangler, but as someone who helps teach all team members how to improve their quality and simply facilitates monitoring and feedback systems to that end. Yes, I execute tests. But my style is more exploratory. I investigate assumptions. In characterizing issues I've discovered through that perspective, I share that perspective with my peers and find that over time they begin getting better at managing those tasks within their workflow. It comes down to preventing bugs rather than focusing only on finding them and praying you didn't miss a bad one.

So that was a lot of text. If you're reading this and have some thoughts, please chime in by commenting.