The Hidden Dangers of an Independent Quality Organization

Share
Reading time ~3 minutes

“We need an independent quality organization, to keep the project managers, developers and business honest”

Today I thought I’d let “Bad Captain” take the helm for a few minutes.

In talking about software quality at Agile Cambridge a couple of weeks ago, the audience were invited to share their insights. Mine was to “avoid independent quality hierarchies” – to which I received a small round of applause (likely from those that recognize the dangers). I’ve had this article in the shed for many months and although my context has since changed, there are many in the software world that face this pain and need your support.

We trust our managers and teams with the finances of multi-million dollar projects, we trust them with staff pay and appraisals when those knowledge workers are generating our primary source of income and we trust them to preserve our intellectual property!

OK so in many cases we have reviews but these are within the same organization. Some companies sadly don’t trust their teams with the quality of what they’re delivering in the same way?

  • What happened to damage or erode the trust?
  • What’s being done to rebuild it?
  • Is it beyond redemption?
  • Who can lead the change?

Most managers I know and most development teams succeed by having a high level of professional pride and integrity and by doing the right things for their team and product. In the situations where a manager or team doesn’t behave in that way it’s incredibly rare that they don’t get called out by their peers.

  • It’s professional and long-term product suicide to short-change quality, we just don’t do it.

There is no good reason for a manager and team to not set their own high quality standards and meet them.

Beyond “keeping teams honest”, the other argument I heard for an independent quality group was:

“Because it’s a required function further up the management chain, that’s just the way it is”

Don’t get me started on empowerment, continuous improvement and root cause analysis. It seems incredible that in the 21st century, staff in many organizations perpetuate this attitude. The truth is that this is still incredibly common.

Unfortunately I don’t have all the answers today but here’s a couple of thinking tools to present…

Let’s run on the assumption that we really do need an independent quality group. As I see things, that team has 2 options.

Option 1: Set a high quality bar and challenge/encourage teams to meet it. Negotiate down or stand your ground when the project teams challenge the setting of the bar.

  • We’ve just built a new source of conflict and waste in our organization with a management chain that have a vested interest in their group’s own continued existence. Nice move!

Option 2: Set the bar at a level we think the team can meet.

  • We’ve just low-balled our quality for the team. Better still, the team working on delivery are not accountable for raising their quality game because that’s been taken away from them!

Now let’s turn things around.

Option 3: Let teams and managers set their own quality bar. Arrange a proper review where the team use their professional pride to challenge the level they set and determine what’s achievable, what they could strive to achieve next and what are the business and engineering benefits of doing so?

Risk: The team low-balls their criteria.

  • Mitigation: Lead by example, drive a culture where everyone takes personal responsibility. Reward and recognise teams for raising their game.

Funny, for some reason Option 3 doesn’t seem to need independent QA.

Where I work right now doesn’t have an independent QA/QC organization. Our quality is high, as is the level of trust exhibited throughout the company.

This is the simple stuff, don’t break it with vested organizational interests.

Caveat: I understand regulated environments have a necessity for compliance and  independent oversight however that compliance environment is either for safety or due to exceptionally high trust-related risk . If that’s not relevant to your organization, why then are you still doing it?

I’ll return the rudder to Captain Crom in future.

Share your thoughts...