Principles Not Rules, part 2

My Current Challenge

I head testing within the treasury function of a bank.

Like many of our peer organizations, like many large enterprises, we have a history of having commoditized, juniorized and offshored much of our testing. Successive changes to location strategy have left our testers scattered in multiple locations, often geographically separated from their projects. In most cases testing has historically been performed by “independent” testing teams, poorly integrated into the delivery effort, managed via command and control by a handful of test managers in the centre. This model has proved expensive, slow, and not terribly insightful. It has done little to prevent a number of projects “going dark” with regards to the quality of the product being delivered – an event often followed by project failure. It some cases this model is barely – if at all – better than a placebo.

In contrast, what we want is testing that informs us about quality and helps keep projects transparent. We want effective testing that is worth what we pay for it: i.e. that is “cost effective” (the clue is in the second word!). We want testing that is integrated with delivery and that is supportive of our firm’s transition to agile.

In short, we have a big gap between reality and expectation. If this gap weren’t challenging enough, we operate in a highly regulated industry: we have a requirement to demonstrate to our regulators that we have an effective control environment. Certain programmes of work are under intensive regulatory scrutiny and this demands a high level of control and transparency.

This is my challenge: how to enable good testing – by empowering testers – yet still fulfil a seemingly contradictory need for control? This is where our “principles based’ testing framework – a way of thinking about, organizing and governing our testing – comes in. It has its seeds in Simon Sinek’s golden circle.

If you haven’t seen Sinek’s TED talk – Google it, it’s worth a watch. His main argument is that most of us don’t have a purpose, cause or belief that’s worth a damn, and that when most of us communicate, we’re all about WHAT we’re doing, or HOW, but rarely WHY. In contrast, he argues, successful organisations have a clear WHY – and they start from that in everything they do.

This got me to thinking: when’s the last time I heard (outside of a conference) any testers talking about WHY they were testing? When’s the last time I saw a test strategy that gave any even the slightest indication of the mission, goals or objectives of testing? So I started asking people. Why do you test? What value do you bring? I got a lot of generic and dubious answers: “improve quality”, “mitigate risk”, “provide assurance”, “because audit said we need to test”*. Unless you’ve been under a rock for the last couple of decades, you’ll know that there’s a lot of disagreement with these kinds of statements.

It occurred to me that, if so few testers have a clear sense of why they are testing, then much of their testing is in fact purposeless; and without any sense of purpose, it is easy to wind up doing a lot of things that add no value whatsoever.

I decided to start using the circles to help me address that, and to start tackling the empowerment paradox. Unfortunately, early attempts failed dismally: a lot of people got hung up and what’s a what, what’s a how and what’s a why. Much confusion! So I changed the model. Instead of Sinek’s why, how and what, I swapped in “purpose”, “principles” and “practices”. To round things off, I added “people”, giving us a model that looks like this:

Framework

 

 

 

 

 

 

 

In the final post in this series, I’ll explore this model in greater depth.

*”Because audit said so” is a phrase guaranteed to drive me Gordon Ramsey. I have no problem with the auditors themselves, but rather with the use of the word “audit” as an attempt to shut down arguments, or to excuse shoddy practices. Suffice it to say, that this tactic rarely works on me.

5 thoughts on “Principles Not Rules, part 2”

    1. See part 3 for a generic answer to that question. Specific purpose will vary from project to project depending on what kinds of information will be of most value.

Leave a Reply

Your email address will not be published. Required fields are marked *