Crossing at traffic lights on the way to work this morning, I looked towards the traffic. Then, involuntarily, I glanced in the other direction.
I grew up in Canada, where we drive on the right. I've lived in the UK for eight weeks now, and I know which way to look when I cross the road. Many curbs even have helpful signs: "Look left," "Look right." But I can't help looking the other way too. It's a habit ingrained in me.
Catching myself doing it yet again prompted me to ponder other habits of mind we harbor from childhood and school—besides please, thank you, and stand up for adults on the bus. One pattern I see wherever I work is an ingrained fear of authority. I can't count the times I've observed people hesitating to ask for the resources they need to do their jobs, or keeping silent when they know they should speak up. I see people not saying no, when no is the right answer for them and for the situation.
Alternatively, people say these things—but so quietly or obscurely that the intended recipients don't get the message. Then, often, they complain:
"We never get any training."
"They just keep piling on more and more work."
"We told them the quality was lousy, and now they're blaming testers for the bugs in production."
As a consultant and test manager, it's my job to speak out and tell the truth: about software, about software projects, about organizations, and about behavior within those entities. Clearly, that's not a simple statement, and it begs several questions. To begin with, what do I mean by "truth," and what makes me think I know it? Answering those questions adequately would take another column or two.
So I'll start with a basic premise. My training, experience, and background have equipped me with professional judgment that, coupled with the exercise of due diligence in a given situation, leads me to believe I am capable of seeing truth in my work. That's true for every competent consultant, tester, and test manager who shares my professional obligation to tell the truth—without compromise.
I consulted once with a client whose company was in trouble with a customer for releasing buggy software. My client brought me in to help fix their "testing problem," but it turned out that the buggy release followed a customer demand to increase scope without moving the release date. My client said, "We told them it was risky and they said they'd accept the risk. Now, they're beating up on us because the release was so bad."
I asked, "Did you spell out the risk? Did you tell the customer your programmers and testers needed more time to do good work on the increased scope, and that there was a high probability the release would be unacceptable quality?"
My client hadn't. Speaking explicitly about the risk would have been tantamount to saying no to the customer's demands, and they'd been afraid of offending their customer.
In reality, what could the customer have done if my client had said no to an unreasonable demand? Gone elsewhere, perhaps, but they'd already committed a lot of money to my client's solution and walking away would have cost much more. Faced with "no," the customer would have been annoyed, but would that have been worse than their (just) reaction to a poor-quality release?
I know there are times when the consequences of speaking up clearly could be disastrous for the speaker. I was once fired from a client project for insisting on telling what I saw and refusing to join the project manager in lying about the state of the software and the project. Many testers have a justifiable fear of job loss if they say what they know when others are keeping quiet about it.
It's similar for a consultant. A client could certainly boot you, me, or anyone out for delivering an unwelcome message. But, as James Christie wrote in response to my column, "So, You Want to be a Consultant?":
"A good consultant has to be brave enough to risk being thrown out for telling the truth."
And a good tester has to be brave enough to take the same risk. No compromise—in either case.