Tales about team building ..

I’ve recently watched and was inspired by something on Netflix.  I’m not going to tell you the title, but see if you can guess it from the description below …

• The lead character is a bit of a wash out
• They are introduced to a group, and time is ticking down to a big event
• At first no-one gets on particularly well.  They try to prepare for the big event, but it doesn’t go well.  They bicker a lot.
• Almost when all hope is lost, there is a bit of a breakthrough.  There is a sign of promise, and it bonds everyone together.  The lead character finds themselves stepping up, and suddenly it looks achievable.
• Just on the eve of the big event, something goes wrong, and it feels like it’s all going to unravel.
• But when it matters, everyone knows what’s expected of them, steps up as a team, and everything goes off well.

Does that plot sound more than a little familiar?  I’d love to know what program came to mind for you, but I’m actually talking about a Danish TV show called Hjørdis, where they’re putting on a big, anti-bullying show at school.

But this plot has been used a lot in films like The Mighty Ducks, Cool Runnings, Dodgeball to name a few.  It’s what Carl Jung called an archetype.  It’s a kind of tale we find we like to use a lot in storytelling, especially for the genre of sports or "let's put on a show".

Since watching Hjørdis, I've found myself wondering why we like to tap into this kind of story so much.  Is it because it’s just good drama?  Is it because we just love the underdogs who come out on top?

I think far deeper, it’s that although we might like to think a bit of the Star Trek Enterprise model, of a crew all being “the best of the best”, and being able to take on everything the Universe throws at it (from rogue self-aware technology, alien invasion schemes, God-like energy beings, and a profusion of planet-of-the-Nazis), this isn’t the case.  Most successful teams aren’t successful because they have the best people (although ability is a factor), but because of how well they work as a group.

In fact psychologist Bruce Tuckman put together a model for this (and maybe some Hollywood blockbusters should start giving him credit), which is known as Forming-Storming-Norming-Performing.  And it pretty much follows the plot points above.

According to Tuckman, if you put together any group of people, on the way to becoming successful as a group, they will live out the drama of those plot points.

Let’s take the original Star Wars movie as an example, and show those stages.

Forming

Everyone meets up with one another.  Luke finds out about Leia and Obi-Wan, and they pick up transport to their destination through Han Solo.  Right now, they’re a group with just loose affiliations with each other, and no general purpose.

Storming

Quite literally, they’re storming through the Death Star.  They’re shooting a lot of Stormtroopers, but also taking a lot of shots at each other.  They all have widely different goals, but learning to align some of them, with mixed results,

• Luke wants to rescue the princess
• Leia wants to get the secret plans to the Rebellion
• Han wants to lie low, not get caught, but get out of there (also get paid)

Most of all, they’re bickering.  A lot.

Of course, this is also where much of the best dialogue comes from,

• “Wonderful girl. Either I'm going to kill her or I'm beginning to like her.”
• “Look, Your Worshipfulness, let's get one thing straight. I take orders from just one person: me”
• “It's a wonder you're still alive … Will someone get this big walking carpet out of my way?”
• “No reward is worth this.”
• “You came in that thing? You're braver than I thought.”

Norming

They get away from the Death Star, but they’re some TIE fighters in persuit.  Han and Luke get to the guns.  Leia and Chewbacca take the helm.  The droids run damage control.  Everyone slots into place, and they work together, taking down the enemy.

At the end, even Leia gives Chewbacca a celebratory hug!

Performing

Luke flies with a whole lot of other pilots against the Death Star.  His number seems up, when out of the blue, Han Solo flies in to cover his back.  They blow up the Death Star and everyone gets medals.

It’s of course interesting to note that when J. J. Abrams rebooted Star Trek in 2009, he followed a much more Forming-Storming-Norming-Performing plot for his team.


For those of us not writing Hollywood scripts, and just working in software teams, where does that leave us?

When we find ourselves on a team where there’s bickering and tensions are rising, it’s very easy to say “this team is not working”.  But the truth is, it’s a quite normal phase in team evolution.  You need to try and work with the team, coach it, give it time and focus on moving beyond this phase.

For more on dealing with conflict in teams, you might want to revisit my post on the Kobayashi Maru of office relationships.

The Project Manager's Yellow Brick Road ...

I've been thinking a lot about this article this weekend - it was originally written and published for Teatime With Testers in 2011.

It was inspired by getting to work closely with a couple of our Project Managers at Kiwibank, in "getting shit done" mode.  Really centrally it is about leadership - and how good leaders help to nurture and also give space to their team, so they have the freedom to do their best work.  [That's what good Scrum Masters do, don't they?]

This theme was central to many of the talks this week at the Agile NZ, and none summed it up better than the talk by Ian Taylor, who has founded and ran a company on this premise since the 80s ...

You might have read the book.  You more than likely have watched the movie.  But are you living the values?

Once upon a time, there was a software engineer called Dorothy who worked for a small Kansas IT company.  But her career felt too restricting, and she yearned to move to a bigger company.  So when she got the offer to up sticks and move over the rainbow to Oz (or was it Aus?) she uprooted herself and followed her dreams.

It seemed that someone had dropped a house on her predecessor, and Dorothy had to step into her shoes.  Yes they were very nice ruby slippers, and brought with them some considerable power, but with one previous owner (now deceased) they seemed a little cursed.

Dorothy was immediately greeted by a delegation of little people from Oz, who truth be told were glad to see the back of the previous Project Manager, who they felt had mistreated them.  It was all quite exciting, but Dorothy realised she didn't have a team yet.

After meeting with Glinda from HR, she was told to follow the Yellow Brick Road.  This was a golden path set out for projects, and the Wizarding CEO at the end expect delivery of a completed project, or would get almighty angry. The Wizarding CEO lived in a gleaming Emerald City - so called, because it provided all the green to fund projects.  But the path before them was hard set, and Dorothy shouldn't deviate for any reason.

All looked like it was going to be smooth until the Disgruntled Business Owner Elphaba arrived.  She had liked the previous Project Manager, and was more than a little annoyed to find Dorothy in her shoes instead.  She told Dorothy in no uncertain terms to "watch out my pretty".

A little unnerved, Dorothy decided to head down the golden path of project management regardless.  The first person she came across was a lion, who was being terrorised by some flying monkeys who were the Business Owners enforcers.

Dorothy managed to shoo the monkeys away, and the cowardly lion was pleased to see Dorothy.  He explained his tale of woe to Dorothy.  He worked as a Business Analyst, but was too scared by the wicked Business Owner Elphaba  and her enforcers.  His work was never good enough, and he just kept having to make changes to it.

Sometimes he felt the changes being made didn't make any sense, but he was too afraid to say, feeling it better to do what he was told, and hope to please her one day.

Dorothy took pity on him as he started to cry, and told the Cowardly Lion, if he'd do some requirements analysis for her project, she'd help to keep the flying monkeys of his back.  The Cowardly Lion was encouraged by that, and promised he'd follow her.

They went further along the golden path to their objective.  The Cowardly Lion had written a few initial requirements down, and was learning to not take it personally when Dorothy made suggestions.  They were not complete rewrites, but enhancements, making better and better requirements.

But they soon realised requirements were nice, but they really needed something developed now.  They came to a field, to see a scarecrow having the stuffing knocked out of him by more flying monkeys.  Dorothy ran after the monkeys, but there were too many of them.  To her surprise, the Cowardly Lion let out such a fierce roar that they soon scattered.

The Scarecrow was a sorry sight.  They gathered him together as best they could.  He worked as a Developer, but he was always being told by the flying monkeys how stupid he was.  He felt he was too stupid to carry on as a Developer he was sure, and was thinking of giving it up and going into something else.

Dorothy told him that was nonsense.  They needed a Developer to help them, and here he was.  The Scarecrow wasn't sure at first.  He finally agreed to take it on, but only until they found someone more suitable and cleverer.

So they set out again.  This time Dorothy didn't seem to have much to do.  The Cowardly Lion passed the Scarecrow his notes, and talked them through a bit at a time, so the Scarecrow wouldn't get overwhelmed.  Every so often they got to something they weren't sure of, and Dorothy would make a decision on what she thought would be right.  But mostly they could sort it out between them.

The Scarecrow seemed to forget his initial reluctance, and got designing and coding, asking questions of the Lion as he went along.  The code seemed to be coming together, but they couldn't really be sure.  What they needed now was a Tester.

As luck would have it, at this point they came to a metal man, who'd rusted into a statue.  He made a plea, but no-one could work out what for.  It was the Scarecrow who noticed that in the metal man's hand was a piece of paper which read,

Category 1 incident

I have noticed I am starting to rust, and require immediate lubrication, as I'm continually losing motor function as the corrosion continues.

The Scarecrow worked out that maybe the metal man needed oiling. He found a nearby oil can, and together he, the Lion and Dorothy oiled and pulled until the metal man could move again.  He said he was called Tin Man, and he worked as a Tester. Unfortunately he'd not got on well at his last project, and was told he raised too many defects. In fact his coworkers told him he didn't have a heart with some of the things he came to them with. So they'd left him outside to rust. He'd tried raising a defect report to get oiled, but no-one helped.

Dororthy couldn't believe her luck, just as she needed a Tester she found one. But she was concerned - the Lion was only starting to find his courage, and the Scarecrow was only starting to believe in himself. A Tester without a heart could set them back all the way to Munchkinland.

"Look", she told the Tin Man, "we have to get this project as finished as possible before we see the Wizzarding CEO in the Emerald City. I need you to really look for the big things, and try not to make too much fuss over the little ones".

"Oh", said the Tin Man. He was quite taken aback. Usually it was his job to point out all the faults in other peoples work, and he was very good at it. But what Dorothy said made sense to him, the big issues were the important ones, and he'd tackle them first, but list the little ones for later reference.

Even so testing did not go well. The Tin Man asked questions of the Lion, who became afraid and lost his voice. When the Tin Man noticed problems in the Scarecrow's code, the Scarecrow said this was proof that he didn't have a brain, and shouldn't be doing this.

But it did get better - as the Scarecrow worked on the bugs, the software became more robust, and the Tin Man remembered to tell him this, and how good the new builds were. The Scarecrow even started making suggestions to improve the design. The Lion began to realise the Scarecrow and Tin Man were deferring to his judgement and calls about how the requirements should be interpreted and became more confident. And the Tin Man began to realise he was a valued equal member of the team, and felt they were all working together to improve quality.

The wicked Business Owner tried many time to take them off course, to send them in the wrong direction or to send them in circles. But Dorothy managed to keep them on the right path and pour water on their problems.

By the time they reached the Emerald City, their work was done.  The Wizzarding CEO was much impressed, and he told them as much in his teleconference.

The Lion had shown his courage, the Scarecrow his brains and the Tin Man his heart. And it was all down to Dorothy's leadership.




The Wizard of Oz is obviously a classic film. What's interesting is that though Dorothy is the heroine, she of herself doesn't do anything that amazing.  Though she defeats both the witches of the East and the West, it's more by accident.

However in her journey she meets a dysfunctional group of people in the Scarecrow, Tin Man and Lion. But through her mentoring and leadership, they become capable of much greater things. This is a quality of truly great leaders.  And thus they are shoes we should all aim to fill ...

Playing office games ...

This weekend, my son played what was to be his last soccer game for his school - yes, next year he will (with luck) be off to University!

It was a hard game, and his team lost.  It was made more difficult by the attitude of the opposition - they'd previously been found cheating in the season (fielding a lot of players who weren't even members of the school).

In this game, Cameron faced a team who seemed to play dirty at every opportunity - some brutal tackles (which would be banned even in rugby), a tendency to be forever calling for a penalty, and just being rude at every opportunity.  Cameron as goalkeeper played the game of his life keeping balls out of the goal, but it wasn't quite enough.

Cameron called his team in at the end, and called for them to cheer and applaud the opposition.  Then privately, he gave his own opinion,

"I'm actually glad we lost, if winning would have involved behaving like they did".

A double dose of sarcasm for sure, but surprisingly short on bitterness.  What I love about my son is that he absolutely meant it.

Of course, his words have been ringing around my head ever since - how did a teenager get to act so mature about something like this?

It made me reflect back about a team I used to work on, many years ago back in the UK.  I worked in a large multinational IT company, the kind they write Dilbert about.  A lot of aspects of the company were not too bad, then in 2003 I was assigned to a particularly toxic project I'll called NavyNet.

This project had a lot of problems (ironically which could all be traced back to people problems).  For me the most obvious was the kind of "snitch culture" that went on.  You never got feedback directly, but there seemed to about a group (which I've always assumed to be a minority) who seemed to go around reporting/complaining about coworkers regularly.

A few of us seemed to spend every month being told that "someone has complained about you".  And having to go through it with a HR representative.  Ironically this caused some deep friendships, as I soon found it wasn't just me.  It was really frustrating, I was even told by HR that "the problem isn't so much your work ... it's the perception about your work".  What does that even mean?

A bit like my son, I had a difficult game to decide how to play.  I have to admit I gave serious thought to joining the accusers and trying to get the drop on someone before they got the drop on me.  But instead I tried to go "I'll show them", and worked harder, and tried to showcase what I was doing more.  But the complaints just kept coming.

Then after two years, I learned how to win.  I left.  And I never went back.

I found other projects and companies who took the office environment and culture more seriously.  I kept in touch with my friends on the project, and they were more miserable than ever.  They seemed truly envious of the fact that I had moved on, and was happy now.  But it had to come with a very hard realisation - I could never make this project happy.

It was a hard lesson.  Unlike my son at his game, I have to admit, I do feel bitter - I pretty much view those as two completely wasted years of my life.  Years that I will not get back.

Talking during this years Kiwi Workshop on Software Testing (KWST), Chris Priest had an experience report on such toxic work environments which blew me away.  You could tell those who'd experienced such offices, especially by their passion to avoid such places in future.

For a time in the late 90s/ early 00s, it felt like this kind of Office Space experience was just going to become more and more frequent.  But thankfully at KWST, there was a good proportion of attendees (typically the younger testers) who had never experienced that kind of environment in their careers - and who I'll admit to having a degree of jealousy over that.


So there is hope.  But as I've said to someone at KWST - we're really good at talking up our successes.  What's hidden is someone successful typically has built this on a lot of hidden failures and hard times, which lie beneath the water line.  This why Chris Priest's experience report was so powerful.

Like my son's game and the NavyNet project, if success in a field involves compromising your fundamental sense of fairness.  If success involves doing something which you feel deeply makes you unhappy and respect yourself less, then maybe the only way to win is to smile, and walk away.

Windows 10 - playtime ...

My Windows 8 machine asked me if I wanted to update to Windows 10 today, I didn't hesitate.  Alas, as soon as I did, I remembered how I have a testing event in 2 days time, and I kind of want my machine to be fully working for it.

Ideally for most upgrades like this, you really want to wait a few weeks for it to be released and them to "work the kinks out".  But we're testers right?  Even if it's inconvenient, you just want to know, get in there and look and play.

I've seen a few complaints about Windows 10 and comparability on my friends updates on Facebook.  I was a bit baffled by that - because these are the same friends who tell me they buy Apple laptops because "Bill Gates".  [So how would they know?]

Maybe I'm just a product of the 90s, I still find FRIENDS pretty funny, and think listening to Blur is pretty hip.  But I think Windows is an amazing product overall, with the sheer spectrum of machines it will end up running on.  Recent changes for Windows 8 I found difficult at first, but then I really fell in love with it when I looked back.

Most of all, as a tester, I like to play around with something new.  And I could easily lose a whole weekend just trying things out.  So far I've found that my anti-virus software needed to be uninstalled and reinstalled (well, techinically the platform has just changed underneath it).  I'm also finding my Google Chrome crashed - and wondering if it'll happen again.  [Stand by not to be shocked, but upgrading to Windows 10 resets your browser preference to Microsoft IE ... I mean Edge.  Nice try guys, but ....]

I've also had a go with Cortana, particularly trying to see what it can do, and how good the voice recognition is on it.  This is me trying to say "Hal 9000" ...

Again, probably not surprising, but Cortana links to the Bing search engine.

At the end of the day, I think releases like this are an exciting opportunity to explore, and get a look at a new system.  In our work days, this is what we live for - to discover the good and the bad in a new piece of software.  And most of all to work through the problems.

Enjoy ...

The lion value system ...

When I was working reviewing More Agile Testing for Janet Gregory and Lisa Crispin, there was a whole forum of discussion which was running parallel to the book creation.

One topic we explored though was getting the balance right.  Everyone knows one of the great things about agile teams is that they interact and they talk about issues as they come up.  They're highly social.

However at the same time, there are stretches where people need to focus, and be uninterrupted for a time.  How can you get the balance right?

Back at Kiwibank we had an interesting system - our team had worked hard to think about what our "tribal identity" was.  In the end we thought of a lion as a mascot - because they represented the courage, ownership and attitude which we felt was core to what we wanted to achieve as a team.

Each of us had a little plush lion on our desk.  When you needed to be left alone, he was placed strategically to tell the rest of the team (although new people would have to be told this rule quite quickly as they'd be forever asking "what's with the cute lion" to the person who expected to be left alone).

People weren't allowed to have this lion on display for longer than half a day without explaining - it was there to be used as needs be.

Likewise if we had a meeting, and there was something you needed someone to know was really important about, and you might need them to listen to (especially if you weren't the loudest voice in the room), you'd bring the lion with you to the meeting.

In a way, the lion represented a kind of social contract between team members, and it's something I'm looking back at and wondering if it's worth (and fun) implementing on my new team ...

Here Be Dragons - Critical Thinking film

We've been talking about critical thinking a lot in part posts.  I am actually hoping this year to explore aspects of critical thinking in more detail, especially looking at how critical thinking impacts testing.

I was introduced to the term "critical thinking" really in the RST course run by James Bach.  He has a lot of areas he's explored critical thinking for testing, and I'd like to build on that - or at least find my own way of describing the process.

Until then, I want to point you in the direction of this video "Here Be Dragons" which explores in a short 40 minute form some of the fundamental concepts of critical thinking.

Enjoy ...

Confirmation bias in testing ...

In my previous post I explored about some mistakes I made looking at the New Horizons mission to Pluto, introducing the concept of confirmation bias.

Like many people, although I was vaguely aware of the concept, it took James Bach's RST course to formally introduce me to the concept.  As I discussed in the previous article, our eyes will sometimes see what our mind and emotions want us to see.

In fact it could be said that the very profession of testing occurs because of this effect.

Take a developer who is writing a registration page for a new system.  He goes through it, provides his name, email, date of birth, and it taken to a "Welcome Stuart Cook!" message.  He concludes "it works for me" and moves onto his next exciting coding task.

Can we really say at this point that registration has been "tested"?  The developer enters some data, he sees what he want's to see - he gets a "welcome" message - and to him this confirms that everything is working.

We have all occasionally fallen into this trap (I know I have) - one test does not cover everything.  Being aware that we have a tendency through confirmation to jump to "that works" is a key part of the RST course.

Entering some details, and getting "Welcome Stuart" is a good start in testing.  But we're not there yet.

Is it for instance just a message?  How do we know for sure that account has been created?  We could check the database, and maybe do a login, to confirm we can use the account.  If Stuart hasn't made the login page yet, then maybe we will have to settle for checking the database.  You were going to check the database weren't you?

A minor thing - but what if we create an account for someone who isn't called Stuart - would we still get "Welcome Stuart" as a message?

Then there's the case of "what if we provide really long, diverse fields for answers to the registration questions - what happens then?", plus of course "what if I provide junk answer to the registration page - does it still make my account?".

All these many heuristic ways of testing a registration page were covered back in my Back To Basics series, which is worth a recap.

Sometimes as testers we're seen as being a bit tricky and difficult to work with.

When Stuart the developer checks his name in the scenario, he says "it works" and moves on.

But when we as testers do the same test we say (or rather we should say) "I have some confidence that when I provide details similar to the situation described that the system should work as expected for the scenario provided".

Isn't that written in a lot of safety language?  Some in software development feel uncomfortable.  Lets take some time to explore the phrase I used, and why I used it ...

"when I provide details similar to the situation described"

I provided the following details - they include first/middle/last name of a certain length using certain characters, a certain date of birth, and a certain password complexity.  If the system is presented with data which includes,

• Characters I didn't include
• Strings which are much longer/shorter
• Date of birth which is significantly different to that I used
• Password which radically differs in structure

Then I will be less confident of the outcome of the system, as these inputs differ considerably from the scenario that I used.

Are you comfortable with that?

"the system should work for the scenario provided"

If I've tested the "account creation" of a registered user, I cannot then say I've also tested the "account rejected" scenario.  This is pretty basic, but again in our confirmation bias, if we see an account has been created we can jump to "well this works", where there are really some scenarios that you really DO NOT want it to work.

"I have some confidence"

What a weird statement to start with?  Surely you're sure aren't you?  Okay - I take the above points, but you've created a Stuart Cook user - surely you're 100% confident that if provided with the same information, that you can create a Stuart Cook account?

Actually no - indeed if you've already provided details for a Stuart Cook account, then surely providing the same identical details will mean an error - you can't create two identical accounts after all.  And if you vary the inputs, then there is a level (however minor) of uncertainty.

Okay - so let's say we delete the Stuart Cook account after you've made it.  Surely you're 100% confident you can make it again?

Nope.  One thing I've learned recently since working on highly available test rigs with load balancers.  Sometimes you can get the most frustrating kinds of errors.  You try something and it fails - so you get a developer over, and run it 4 times, each time it passes.  Your developer walks away in disgust, and the problem comes back.

Rather than being transferred to the tester funny farm, it turns out that the problem you're experiencing happens only on one server, and just by pure luck, you've been pointing to the wrong server every time you've been on your own testing!

So what's the cure?

Well, the first step is to know that confirmation bias is a thing, and a very powerful motivator.  We, our developers and our project managers are going to want us to "race to the finish", so there's a lot of pressure to "tick the box and say it's okay".

That statement I used is correct,

"I have some confidence that when I provide details similar to the situation described that the system should work as expected for the scenario provided"

So what's the solution?

Firstly, try different scenarios - make sure you cover all the scenarios you'd expect.

Secondly, vary the inputs to try a broad range of situations.

This was covered as I mentioned in my Back To Basics Testing series, but here we're looking at the "why".  Why we need to do this - the more we've covered the more confidence that statement gives.

But we can never be 100% confident - testing is always a trade-off between trying different inputs, expecting different outputs, whilst being aware all the time that the project clock is ticking, and we can't take forever to do this.

Good testing is about choosing those cases wisely, trying to cast a net across possibilities and experience to try and find potential problems.