The Testing King's Speech
I remember sitting watching "The King's Speech" one evening some time ago. Did you ever see the film "The King's Speech"? It's an interesting study. The thing is, most people watching it saw it as a study in how one man, a Prince who, eventually, would be crowned King. He did not want to be King and as he had an elder brother, the heir, it seemed unlikely. Of course, the brother had some interesting "relationships" with people that were inappropriate. The result of those eventually led to the older Brother, who by then was King Edward VII of England, abdicating the throne in 1936.
Most people who see the film take away a story of a triumph of will on the part of the man who became King George VI. With the assistance of the speech therapist, of course.
I noticed one distinct thing early on. The Prince, Albert, not yet George, and his wife Elizabeth pay a visit to the speech therapist (Lionel Logue). After a brief, unsuccessful visit with Albert alone, this second visit consisted of Albert and Elizabeth telling Logue how they wanted him to do his job.
It was interesting, because he had been asking questions that made Bertie/Albert (not yet George) uncomfortable. Stuff where Bertie/Albert did not understand the purpose of the questions. Logue explained that there was possibly information he needed to help Bertie/Albert within the answers. Except Bertie and Elizabeth would have nothing to do with such flim-flam and silliness.
They wanted him to fix the physical problem of his stammer.
How many times does someone come in and demand the team do something that will not serve the needs of the project, team or company. When we, as software professionals, push back, they, the project manager or business analyst or manager or maybe a would-be scrum master, tell us to do what we are told. That is our job. So just do it.
Being the compliant, obedient people we are we just give in and do it their way. Right? Testers should focus on finding bugs. Unless we should focus on making "sure the software works." Maybe we should focus on ensuring confidence in the functionality. Perhaps we should focus on all of these things.
Nonsense. We might do those things on some projects, based on the needs of the project when they are the right thing to do. Here, by "right" I mean within a reasonable professional code of ethics. Of course, it might boil down to "keeping your job" but that has never really held much sway for me. At least not in the last 15 or 20 years or so.
How do you approach or respond to someone who is telling you what you should be doing? What about when they have no real expertise or experience within their argument, other than "I'm your customer and this is what I want"?
I am reminded of the philosopher-poets who wrote:
You can't always get what you want
But if you try sometimes, well, you just might find
You get what you need
What is Wanted vs What is Needed
Many people confuse wants and needs. There really is a difference, no matter what people trying to sell you something might say. Sorting out what is needed from what is wanted can be really hard.
There is the noise, buzz, and clamour of managers, project managers, someone else saying they "need it NOW!" Then there is the voice in the back of the head that says, "Something doesn't quite feel right. Something is out of sorts."
How do we sort out what is really needed? The easy way is to tell them "that won't work." I'm not sure that works either. The not-quite-as-easy way is to say "Well, I'm not sure that will work, and here are my concerns..."
The thing often wanted from us, as testers, is where we say "OK! I'll do precisely that!" Which will make the requester/demander go away happy. Odds are they'll be back, not so happy, but that won't be for a while so that is just fine for now. We can figure out something to tell them later. Not today.
The option that Logue used in the film (and in real life) was simple. He said, "OK, we'll do it that way." He then proceeded to do "physical exercises" and "training" to deal with the stammer. He did this knowing that the chances of it working were incalculably small..
In the process of working through these exercises, they conversed. They talked. At one point it became clear that Bertie was actually left-handed but had been trained to act right-handed. This led Logue to comment that this was not uncommon. There were questions posed as "interesting ideas" that Bertie answered, simply because he was relaxed. His guard was down and he was more open.
In the end Bertie came to rely on Logue. He even offered an apology, in a very Royal Family sort of way, for his previous “bad behavior.” In the end Logue did what was needed. It started by simply being willing to help.
Importantly he took pains to not dismiss the words used to express the wishes, and desires of Bertie and Elizabeth. He made sure they knew he wanted to help. He focused on being willing to "do what they wanted" until it became clear something else was needed.
We can push back, gently. We can offer help. We can set the conditions. We must also know what to push back against. We must know why.
I'm not sure I can do what Logue did, at least on a regular basis. I've tried, with various levels of success. Some folks were OK with that. Other folks wanted something like "that and only that." They wanted me to precisely do that one thing, exactly what they said. I have a hard time with that, particularly when they can't answer basic questions around the intent of the software.
Granted, working as a consultant or contractor, you may have a bit of leeway that an "employee" may not have on the surface. Know how you can contribute, then do so.
You may not get a CVO (Commander of the Victorian Order, an "Honour" given for personal service to the Monarch of Britain) out of it, but I expect you'll be able to sleep at night.
Your comment will be posted after it is approved.
Leave a Reply.
The new home of Pete Walen's observations, comments and thoughts on Quality, Software Testing, Agile and Scrum.