Several years ago, as a consultant, I had the opportunity to work with a client on modernizing their Quality Assurance processes. At the time, I was at the phase of my career where I viewed QA as just ‘testers’. They were sort of secondary characters in a play that starred programmers. Like the ponies in the Lord of the Rings. Important, sure, but they didn’t get their own swords or anything.
So I took a deep dive in to Quality and started at (close to) the beginning, with W.E. Demming. He was one of the first Quality gurus, and became known for his work in Japan following WWII (he has a wikipedia page). The one thing that really resonated with me from researching him was his idea that you had to drive out fear from engineering. At the time, I was still in the ‘bugs are bad’ phase, and because of that, made all the classic mistakes in programming. I wasn’t good at testing my own work, and wasn’t particularly good at telling our testers where to look for bugs. I also viewed testers more as impediments to my amazing software being released than as allies.
On the whole, this led to inferior software. What I took away from Demming was that as a leader you need to create a culture where errors are part of the work we do, and processes are in place to catch them, since it’s the entire organization’s job to prevent errors. It’s not just the developer, or just the QA team, or the business owner, but everyone.
The problem with implementing this is that bugs do cause real problems. Thus, it’s harder than just saying ‘bugs are part of life’ and moving on. You need to do several things as a software leader:
- Never penalize developers in public for errors. Most developers take great pride in their work and shaming them reinforces their reluctance to face their errors.
- Empower QA. Create an environment where no questions are off-limits to the QA team. They have the final say in the release of the software, and should have the blessing to ask all the hard questions.
- Force honesty. When handing over work for testing, there should be no fault in telling QA: ‘This area is a bit less well-baked because of reason X’ Rightly, QA should review that area early to mitigate risks there.
- Lead your team in owning up to your own bad programming. You, as lead, should also say ‘wow, that was pretty crappy on my part’.
There is no reasonable expectation of perfection – you are trying to foster an environment where problems come to the fore so that they can be caught early, rather than by the customer.
At the heart of this, I feel, is fear. Fear of failure, fear of being singled out, and fear of reduced job security. In general software engineering, the team as a whole should have a culture where individuals aren’t afraid of bugs, but are able to produce great software because they help each other product great software.
As a leader, it’s up to you to set a tone where this sort of culture can take hold. You want to think about how you relate to your team and how you deal with tricky things like after-action reviews. If you do it well, you have fostered an environment where everyone can comfortably discuss any areas they think they can improve, and you can collectively work on improving those areas with better process.