The Kobayashi Maru of Office Relationships

In Star Trek II : The Wrath of Khan, we’re introduced to the Kobayashi Maru test.  In a nutshell it’s an unwinnable situation designed as a test of character.

I’m almost ashamed to say this, but I feel the same goes with some difficult office relationships.

In an ideal world there wouldn’t be any conflict at work.  Everyone would be utterly professional, and emotions would never flare up.  We’d always have plenty of time to do everything, and when we asked someone to help us, there would never be any other priorities.  This would be the development world of THX-1138!

Of course the reality is somewhat different, we’re always under some kind of stress, and the person we urgently need something from may have different priorities.  And lets face it, people can be just plain difficult sometimes for the hell of it.  I try generally in the office to follow the rule “treat others as you’d want to be treated” – but it doesn’t guarantee me an easy day in the office, because it’s not always a given that when you treat someone with respect you’ll get it back.

This is going to lead to office conflict.  We can say “we need to be professional about that”.  It’s kind of easy to be professional when the people you are dealing with are also professional.  When they’re not - or more specifically, when you feel they're not (professionalism is in the eye of the beholder) - of course it’s going to leave you or anyone in that position feeling emotional, and this is where the Kobayashi Maru test occurs.

But this is something common we all confront at some point – dealing with conflict.  When you’re faced with conflict there are two obvious, and polar opposite forms of response,

You can’t handle the truth

Someone has upset you, so you retaliate with all guns blazing.  It’s very much like Jack Nicholson in A Few Good Men.

It feels at the time very good, at that moment you feel powerful and in command.  But if you’ve ever seen anyone explode like this, they always look like an ass.  It also crucially damages office relationships because often a lot of what’s spoken can’t be taken back.  Sometimes we might feel someone is being an idiot, but perhaps it’s something much better kept to ourselves.

The Paranoid android

“Oh what’s the use … they’re never going to listen to me”.  Much like Marvin the Paranoid Android, conflict is too scary, so keep quiet and just get on with it, and keep your head down.

Although this won’t damage relationships, it’ll damage you.  Feeling less a part of your job with less direction in what you’re doing, you’re essentially disempowering yourself.   You’re making yourself incredibly miserable, and worse still, you’re not conveying to others how unhappy you are about it and why.  So unless the people in the office are mind readers or ultra-perceptive, they can’t help you.


Not surprisingly given two extremes of behaviour the right way is somewhere in between.  With responding to any conflict in the office there are of course two factors going on – gain vs risk.  When we respond to conflict there’s a possibility of gain in our situation vs the risk of making a situation worse.  When we’re passive against conflict then we’re not going to risk making things worse, but neither are they ever going to get any better.

Here are what I think are tips to get the right feel for dealing with conflict,

Remain calm

Don’t get emotional, and don’t get dragged in.  Give yourself time.  As human beings we’re hard wired with our human intellect built on top of reptilian responses.  Reptilian aggressive responses are almost instantaneous.  Reasoned ones travel longer through your brain, almost building speed, and take typically 2-5 seconds longer.

So if you feel yourself about to snap back, try counting slowly to 5 and see if you’ve calmed down.  It gives your more reasoned responses time to kick-in.

Worse comes to worse, it’s better to bottle it than to burst.

Speak slowly

Kind of goes in with the remain calm scenario – but often when people are annoyed or agitated, they tend to speak a mile a minute.  This rapid patter tends not to help their argument, and comes over as a rant.  And just to make it harder, people don’t always follow what you say.

Don’t name call

You might think someone in your office is an idiot.  But calling them one to their face isn’t going to help you or change them.  Idiot / stupid / retarded.  Yup this one seems common sense doesn’t it …but  how many times have you still been in an office where someone has made this mistake?

Why do you want to call them an idiot?  “I think James is an idiot because he’s always delivering reports late, then changing them just as I start work”.

Better to remove the emotional and the name calling, “when your report is late like it was last week, it delays when we can start”

No time for threats

Well the obvious “do that again and I’m going to introduce you to my 9-iron” has no place.  But in conflict we can often fall back on an ultimatum.  “Do that again and you’re fired”, “speak to me like that again and I’ll leave”, or even “I’m going to tell on you”.

The problem with an ultimatum, it’s often delivered in an emotional state, and it represents a line in the sand, and almost a challenge.  If someone challenges that line, are you going to stick by what you said, or lose face?  When you give an ultimatum, it’s usually yourself you’re putting in a difficult position, not the other party.

Learn to bury the hatchet

It doesn’t do well to carry a grudge.  Making great software is stressful at times, and yes, emotional.

It reminds me of the times I’ve put on a play with amateur drama group.  On dress rehearsal night nothing works quite right, costumes split, props don’t work, people forget their lines and the director is screaming you’ve got it all wrong.

Rehearsal night is a cauldron of seething tension, everyone is getting on each others nerves, there are cries of “never working with you again”.  One week later the curtain falls on the last show, everyone hits the after-show party, and they’re hugging each other going “I know we don’t always see eye-to-eye but I think you’re really lovely”.  Oh yes and a lot of alcohol is consumed!

So what inspired this article?

Friday I have to admit wasn’t a good day, I had a run in with Paula one of my project managers.  I can’t claim to be 100% not at fault, but neither did I think she was being fair.  I was pretty upset and angry,  feeling my work is never really appreciated by Paula.  I spoke to her calmly that I didn’t feel helped by her, especially over issues of trying to get testing done early.  I didn’t speak my mind fully, but I was upset and felt some of what she said felt like a threat.

Back home I was giving serious thought to looking for another job based on this incident.  One unpleasant project manager can overshadow the other four project managers that I have a great relationship with.  Come Monday I came in feeling a bit weary, but with the emotional blinkers off she has complemented testing services at least 4 times this week, and it feels a bit like Friday never happened.  In the long run it’s just probably better to chalk it up to “one of those things” stressful development brings out, but be weary if it happens again.

After all we’d not appreciate being judged to harshly when we have a bad day …  The important thing to learn is workplace conflict like the Kobayashi Maru test doesn’t have winners.  It just shows the person you really are underneath and the person you can strive to be.

Testing and the Cassandra syndrome

What a stressful week!

We’re now a couple of days from formal User Acceptance Testing for our new product, and we have a limited 2 week window.

In an ideal world we’d have had an early version of the software to run preliminary tests on.  But there was only one machine available, and the priority was both to give this first to marketing and then to training because “testing wasn’t due to formally begin until a week later”.

This made for quite a frustrating experience, as I tried to explain to management the importance of testing getting an early look at it.  But I wasn’t really listened too – I was told as our window was so tight, it would “just have to work first time”.

It actually made me quite angry – this was project management by desperation, and flew in the face of everything I knew.  There would be defects I said, as in my experience projects always had defects.  It’s one of the fundamentals of testing “test early” but management were insisting on a rigid waterfall interpretation of “test at the end”.

My feeling of this is much like Sun Tzu who said that,


“a victorious army first obtains the conditions for victory, then seeks to do battle.”

Basically I interpret this as before you formally test, you test informally anyway to know the overall quality of your product and when if it’s ready.

In software there’s often a “can do” attitude of we can do anything.  Unfortunately this sometimes becomes as the above comment “we’re so stretched for time, it has to work first time”.  Everyone is optimistic it can be done.

This is where the Cassandra curse comes in.  Cassandra was an Oracle blessed with the power of divination.  But after a fall out with Apollo, she was cursed that her prophesies would never be believed.  And so she could see the future but was powerless to prevent the disaster she knew was coming.

This is something I think too many testers feel.  When many managers and developers feel “hey it’ll all work first time”, testers are all too experienced that often it doesn’t.  They know this because it’s their job to deal with things when they fail, and they’re expert at working the problems.  In all my development experience, I’ve only ever had one thing work first time (ironically it was also the most complicated thing I wrote, a search algorithm).

Problem is it’s hugely demotivating to be ignored or disbelieved when you try and warn a project there are problem ahead.

We finally managed our preliminary tests today – a couple of big issues, but a whole host of mediums one as well.  Perhaps too many to address in the time left.

But hey, that’s why they call me Cassandra ….

Chicken Little and the Tester Who Cried "BUG!"

We all know the story of Chicken Little – he sees something fall from the sky (an acorn) and is so convinced the sky is falling in, he spreads panic around his friends, and they go off to seek the King, but end up getting eaten by a sly fox who uses the panic to lure them to their doom.

It's a sad fact but in the world of testing there are a fair few Chicken Littles.  And if you have one on your project, your developers in particular will get tired of them pretty quickly.

On a previous project with EcoEnergy we reviewed some designs for a website with development and marketing. And we got from marketing “oh no – this is a showstopper, the red is the wrong shade”. Looking around the table the developers were incredulous, but recovered assuring this was a minor change, and would easily be resolved.  But for them the bigger concern was the fact that all the data they were receiving from the back end was wrong, and thus they were misleading the customer.

With both the acorn falling from the tree and the wrong shade of red, not big issues. The acorn falling was actually a known feature of an acorn tree.  I know it's easy to mock the marketers, but although getting the look right for them is important to them (an application which looks ugly isn't going to lure people), at the same time as the developers were right to mention it's easily resolved, and not quite the sky-falling-in showstopper.

As testers it's our responsibility to inform management and developers when big bugs come along.  The kind of defect that jeopardise product delivery and timescales. So for instance, the misleading data which means we're liable for misinforming our customers, the system crashes etc.

Time plays a big factor too.  If our logo issue was discovered the day before go-live, it would be more critical.  But likewise if you get a serious bug weeks out from delivery, it's kind of the norm, and as long as it's defected and put on a path to resolution, it's nothing to get too worried about at that stage.

I figure as testers we're like the boy who cries wolf ... or should I say BUG! If we say BUG! too many times, eventually people are going to stop listening. I mentored a tester who escalated every defect she encountered the same way, even the cosmetic ones – eventually all her emails were being left in developers intrays, because they wouldn't / couldn't separate the urgent from the cosmetic

It's a bad place to be in, because a tester who's let that happen has lost the trust of her developers, and it's a very tough place then to be effective and win that back.  With the tester I mentored, I managed to steer her to rate her defects, and the really important ones she should really try and get the developer in to see what she'd experienced as soon as possible.  It became so much easier then for developer and tester to work together and solve the problems she was finding.

As I've said privately many times before, nothing really beats having a developer or business analyst on hand to ask “hey is this right” when what you're testing looks wrong.

Indecision and other vices ...

Indecision

Following on a little bit from yesterdays talk of indecision, it's time to talk a bit about Foxhole Norman.

We've recently been rewatching the excellent Band of Brothers.  Norman Dike, aka Foxhole Norman is an archetype all too familiar to anyone who's worked on a software project.

He was a replacement officer for Easy Company and described thus,

Lt. Dike wasn't a bad leader because he made bad decisions. He was a bad leader because he made no decisions.

Rather than fighting, he would usually remain in his foxhole.  If there was a crisis he'd try and return to base for more orders.  He was constantly absent.

He embodied indecision in a place where indecision was deadly.

Rashness

On the other end of the spectrum is acting rashly, which has equal perils.

As kids at Junior School we were often told the tale of Gelert the dog.  He belonged to  Llywelyn the Great,, a Welsh Prince, and was his favourite hunting dog.  However one day Llywelyn comes home to find his infant son's room ransacked, and his son missing.  But there is his dog Gelert covered in blood.

So Llywelyn draws his sword, and kills Gelert there and then.  But the dog's dying yelp causes the hidden child to cry.  Looking around the room, he sees in actual fact there's a dead wolf in the room, and Gelert has died protecting his son.

Overcome with remorse for what he's done, he builds a memorial to the dog, and curses his rashness for the rest of his life.  When Mr Barrett told that story there wasn't a dry eye in the house.

This teaches us not to act rashly, and indeed acting rashly is worse than indecision.   It's good to want to know more before making a decision, but how long do you leave it?  Collecting more and more and more information on any task does not mean in the end you're actually achieving, eventually it means you're wasting time and not actually doing anything.

Another Way

Sooner or later you have to make a leap of faith.

Ironically the longer you leave making a decision, the bigger that decision will have to be, and the more critical it'll be you make the right one.

Make decisions early, try to make their impact small, review them regularly.  If they're wrong you'll still have time, and almost always something is salvageable.  It sounds like I'm going all Agile again, and maybe I am.

Just don't be a Foxhole Norman ...

The Curse of Indecision

May was a quiet month on the blog front, as our family sadly dealt with a death in the family, my father-in-law.

Dealing with death is about one of the most traumatic things most families deal with.  And there is an awful lot to organise.

In my father-in-law's case, a will could not be found detailing his wishes, and an awful paralysis crept in amongst the family.  Because no-one had a piece of paper with his wishes, no-one decided anything to do with his funeral, what kind it would be, buried or cremated.

Everyone was so frightened about “getting it wrong” and being judged to have gone against his wishes, no-one did anything for over a week.

This is probably the worst kind of decision paralysis – not making a decision didn't change the fact he was dead or that he'd need a funeral.  It took a lot of courage for one sister to go “I think he'd want ...” and everyone fall behind that.

Indecision is probably one of the worst thing in any project.  Indecision is often disguised as waiting for more information, but really it's often just putting off the point where a decision will be made,

In my book it's always easier to work with a decision which creates problem than just waiting on hold for any decision to be made ...

The Death Star wasn't Agile - the video ...

Yep - why read, when you can just watch!

Are you not entertained?  

The Death Star wasn't Agile – and other Imperial failings …

This started as a joke I put up on Twitter, but the more I thought about it, the more I feel how we could learn a bit from the Empire, by looking at how they run projects, and how not to fail like that in our teams.

1)  Death Star Vs Alderaan

The Death Star is a planet killing ultimate weapon.  Woot!  And part way through Star Wars IV A New Hope, it appears above Alderaan, and blows it to smithereens.  

This Governor Tarkin claims this is the first demonstration of it's firepower.

Now if this was a truly Agile project, then in the first part of the film, the Death Star would have gone around blowing up an asteroid first, then a small moon, before moving onto Alderaan, to effectively show the capability of it's destructiveness in a couple of iterations.

Okay so the Death Star worked - but what if it hadn't?  Instead of feared throughout the galaxy it'd have been on the "and finally" section of the news.


2)  Getting the Death Star working

There is a gap of 20 years between the films Revenge of the Sith and A New Hope.  In A New Hope it's said that the Death Star is only just operational.

And yet in Revenge of the Sith, the Death Star is shown under construction – that means they took 20 years to finish it and work the bugs out of the system!

Ever heard of deadlines?  C'mon we've got a galaxy to run here!

3)  Blowing Up The Death Star

The plans of the Death Star appear in the second film, Attack of the Clones.  In A New Hope, the Rebel Alliance get a hold of them, find a weakness (the exhaust vent leading to the main reactor) and attack it.

Yes – it took over 20 years to get the Death Star working, but they kept to the original plans – they never went “wait a moment ...” and thought of a better way?

4)  Stand-Up Meetings

The Empire never got the hang of stand up meetings.  Look at this – only Darth Vader is getting into the spirit of it.  And even then he ends up force-choking another member.  Which is a novel way to keep meetings from over-runing.

5)  Armour Plated Solutions

In the Battle of Hoth the AT-AT walkers won victory over the Rebels landspeeders.  Ish.

The AT-ATs were better armed and armoured.  They won, they took out the bases reactor and shields.

But they were also very slow.  By the time they got to the reactor, the Empire had given their competition the Rebel Alliance enough time to get ahead of them and move on to a new base.

Had the Empire used landspeeders themselves, they could have quickly taken out the reactor, and wiped out the Rebels there and then.

6)  Embracing Failure

No-one in the Empire really learns from failure – as they often end up being force-choked to death.

This is particularly bad as sometimes the one to blame for Luke Skywalker getting away is Darth Vader himself.  Poor management.

7)  Hoping the Little Problems go away

On Endor, the Empire was plagued by little fury pests.  Rather than deal with them decisively, the stormtroopers just hoped they'd go away and not bother them.

In the end those pesky Ewoks ended up ganging up and becoming a giant problem which brought down the Empire.

When you can, exterminate those Gremlins before they gang up on you!