Some amazing blog articles ...

Was it only yesterday I said I was aiming to be quiet?

I did a review of the articles I've read in the last couple of weeks - most are favourited on Twitter (so easy to look back).

Interestingly, reading isn't a silent activity.  And by that I don't mean I mumble when I read.  If you come across good ideas they challenge you, and you also want to champion.  And so here are the articles which most have made me think this last month ...

The Role of Testing

Let's start with Scott Barbers article about 10 things about testing which should die.  If there is just one recommendation of mine you should read, it's this one.  I don't agree with a few of them, but they are really some great points there for you to review as a tester.

The big challenge there is really, stop behaving like a spoiled child.  The idea that some testers relish their ability to disrupt delivery as a kind of power trip.  This was echoed in another article by Eliza F, Oi you tester, where she points out "being a mean tester doesn't make you a clever tester".

It's perhaps right, something about testing we need to challenge, the trait inside us to look at a train wreck and go "if only they'd listened to us".  Rob Lambert also touched on this on the review of a conference, where there was a talk about "them and us" referring to "developers and testers".

I heartily agree, developers and testers need to have a working relationship.  Although my friend Russell went too far when he ended up marrying his tester, Maxine.  Like I've said many times, developers are like strikers in soccer, and testers are goalkeepers.  We do different things, but we're part of the same team, and we need to understand the ways we support each other.

In that vein then, I found the following presentation by David Evans about What testers and developers can learn from each other fascinating.

Talking about developers

If I have a second "must-read" recommendation it's the following article about developer habits.  We all know the stereotype of developers working until late.  Why programmers work at night is just a piece of absolute brilliance.

It explores why when dealing with something complex like programming, your mind needs to focus for long periods of time.  It's not something which can be stop-started by interruptions of meetings etc.  As an ex-developer I agree, when code has clicked in your head, you just can't get it written fast enough, and you need to be left to get it out of your head.  It's a fragile thing and interruptions disrupt it.

What I'd pick up from this is in an ideal world you'd try and have any meetings with developers within the first two hours of the day, and try and leave them to get on with it the rest of the day.  Fits in with the Agile idea of stand up meetings at the start of day.  Pester them and they're less productive.

I will give this to my project managers to have a read on Monday.

Bringing fun right back

Oliver Erlewin's article on Fun, IT and quality was interesting to read.  Are we losing sight of the fact testing should be fun, we should feel engaged rather than down-trod and under pressure?  I know I'm getting guilty of that.

Likewise I loved Brent M Jensen's discussion about how he socialised what testing was doing in his workplace in Speed date your way to better software.  These seem like quirky and silly exercises, but bringing fun into the workplace is about getting testers more engaged on what they're doing rather than doing the "test zombie" workforce who might as well be test automation machines, never varying what they test, never exploring.

Building on from that Olaf Lewitz discussed What makes a good tester, championing problem finders and problem solvers.  We're perhaps more famous as testers for the former over the latter.

And finally

Rosie Sherrie wrote a brief article on The tester and the marketeer.  I am working on more and more projects which are led by marketing, and I do hopes she revisits and expands this.


And finally - just for kicks.  We all know our favourite websites.  Everyone moans every time Facebook or Twitter changes or evolves.  This article reminds us what they looked like when they first launched.

Shhh - the sound of learning ...

I'm going to attempt to be very quiet this month, but I'm going to tell you why ...

Writing this blog is a great experience, and it really helps me in my work.  However as part of an experiment, I'm aiming this month to divert my energies from writing to reading.

Why?  Well just as a way of exposing myself to other testers ideas.

I'd been thinking about this anyway - but then was inspired by Lisa Crispin's article on Professional Growth in the December edition of Teatime With Testers (well there's also an article there by yours truly).

In it she talks of the importance to find time each week for some professional growth.  This is kind of true.  Most of what I've learned is self-taught through home study.

These days though I don't have the time to work through text books like I used to.  I might tackle an area or a chapter.

I find Twitter really useful, and keep a professional Twitter account.  I have a 25 minute commute to work via train, and use it to follow several testers around the world.  I find better than test books is reading blog articles.  They expose you to a small area, with a couple of ideas, and a little bit of opinion. But it's easily digestible.  And they often provoke ideas or reactions.

I'm also a big believer that the best way to learn about testing is to not just learn about testing.  Most of this blog is about looking at things like sport or films or Star Wars (not that Star Wars isn't a film) and looking for the parallels and the parables which we can bring back to our professional life and be better at our job.  Learn but in a fun way that it doesn't feel like learning.

Okay - so here are some great places to start.  There are a few online testers magazines out there, which contain an absolute rogue's gallery (but in a good way) of articles,

Testing Planet (which I sometimes edit articles for, but ironically never been published in) ...
http://www.thetestingplanet.com/

Tea Time With Testers
http://www.teatimewithtesters.com/

Testing Circus (which I've had the Agile Haka published in)
http://testingcircus.com/default.aspx




I'll try and return at some point and list some of the better articles I've experienced ...

A year of blogging and for what?

I'm coming up to a year of blogging  on testing, and it's interesting to reflect back.

I first came up with the idea of this blog really as a place to collect some useful materials.  I've always worked in my companies as a mentor, and imagined this place as a mentoring hub for anywhere I'd work in future, rather than my hard work being locked into the company intranet of somewhere I'd long left.

But as 2011 turned, I moved out of just testing and into test management in my new role.  My new company offered a lot of challenges.  Sometimes I'm frustrated that “we're not there yet”, but we're making progress, all-be-it slower than I'd hoped.

Work has presented me with a few frustrating moments and dead ends.  I've found it useful from tough weeks to sit in front of my machine, and talk about what's gone wrong – but try and stay positive, and talk about how to make things right.

I think an article I personally go back to a lot, is the Kobayashi Maru of Office Relationships.  It was a very tense time at work, and somehow talking about it and breaking it down helped.  I've worked really hard since to build bridges with Pauline, and I'm hoping we have a much better relationship.  Ironically through the bridge building process I've found out just how much pressure she was in, and she's admitted to not always handling it that well.  What could have become a bitter office feud is turning slowly into two mates trying to watch each other's backs – relationships take some building.

Another stand out article I've written has been The Agile Haka, about getting teams to work better, which got published in The Testing Circus, and my General Manager read this month and gave it his seal of approval.  And finally Those Darn Test Estimates, which is more identifying when testing overruns – I refer to those root causes regularly with my Project Managers now.

Those were my favourites, though ironically not the most popular of my posts.  You can never second-guess your readers.

I thought I was going to write this blog to teach.  In fact I found every time I sat down to write, I actually learned.  Just sitting down and thinking of an aspect of work I was unhappy with helped me look at the problem, break it apart, and look for answers.

What else did you expect?  I am a tester after all ...

Why is it so important to be able to socialise after work?

We had a great night last week after work. A departmental meal and karaoke night had been organised for the Friday.  Everyone talked with each other, and often with someone new during the meal. We enjoyed a few drinks, and we got really into the spirit of things becoming quite competitive on the microphone.

It's important to like the people you work with (although I'm usually better friends with people outside of work). But it's important to do these events once in a while because there's an important though subliminal message within these things as long as it's all fun and games.

The office is a place of tension. Project managers want one thing, business owners another, testers and developers something even more different. I discussed a little about office tensions in the Kobayashi Maru ofOffice Relationships – I've worked many different projects in 15 years in the IT business, and it's a similar story everywhere.

But in a social environment, when you get on and even have fun with others, there's an important thing you come away with. No matter what the strains of the 9-til-5, you can get on with each other. Yes it's going to be tense at times and sometimes emotional. But it's nothing personal.  And that's something important to come away with.

The Rugby World Cup – learning to celebrate

The end of an amazing road for New Zealand – hosting the 2011 Rugby World Cup and of course also winning it.

Behind the Rugby World Cup has been an army of volunteers who've given up their time for something they had passion for.  I was among them.

A year ago in September 2010 they asked for volunteers, and I put my name into the ring.  Expecting something glamourous like marshalling at the odd free game, or meeting a celebrity.

In actual fact my volunteering meant I had an office job, working with IT creating photo passes.  As it would turn out, a portion of this has been my actual day job.  So not really glamourous.

But is that a surprise?  When work needs to be done, it needs to be done.  Sometimes it's unglamourous, sometimes dull, sometimes tiring.  But it needs to be done.

The best part after the win by the All Blacks was the victory parade in Wellington.  As volunteers, we got to wear our uniform and walk behind our team through the streets.  It was an amazing experience.

Oddly enough we've been reflecting at work about projects, and how we end the.  Invariably projects complete a little later than liked, and we scurry from one to the next.  We lose our ability to celebrate success in any form.

All told my volunteer work for the World Cup added up to about 7 days.  And yet we walked through the streets with a bit of fanfare, we got a mention of thanks from the Prime Minister himself.

And yet I put many more hours and effort into my work and projects.  But do we find the time to have our own celebration?  Perhaps it's time we did.

[Look very carefully and you'll see yours truly in the volunteer army behind]

Dennis Ritchie dies

Last week Steve Jobs died, and consumers and world leaders stopped to pay tribute.

This week Dennis Ritchie died … and many outside the world of computing will go “who?”.

He was a computer scientist, who not only created the C programming language, but also helped to create the UNIX operating system in the 60s and 70s.

If like me you have ever done programming, you've no doubt done it in C – it's a hugely popular language, and incredibly powerful and flexible one. It's spawned and influenced many of our current languages like C++, C#, Perl and Java. If you've programmed in C, then you've owned C The Programming Language by Kernighan and Ritchie.

The same can be said for the impact of UNIX, itself written in C.

The technologies have made pretty much every type of device and gadget you can imagine today possible, it's used to program mobile phones to XBoxes. You cannot imagine the world of software today without them.

Quite rightly it's been said that the world of computing has lost a titan.

Those darn test estimates …

How long is a piece of string?  I'm tempted to be a wise-ass and say that to project managers when they ask me “how long will it take to test my project?”.

That's actually unfair, experience gives us as testers an idea, based on similar projects, of how long it'll take to test.  But one of the problems is, testing is an activity which has a complex relationship with other factors in a project – we can keep testing and testing, but if development don't start fixing some bugs, we're going to be here forever!

So yes, we can look through the designed features and estimate how long it will take to script, and how long to execute those scripts.

But how long until the product is finished testing?

How long is a piece of string?

Having worked in a test consultancy, there is no doubt about the importance of estimates.  They need, when a project manager looks at them, to be attractive but also realistic, with some contingency.

What we introduced was a list of estimates for testing tasks for “best case”, “probable case” and “worst case”.


                BEST   PROB   WORST
Test Plan         1 2 4
Test Conditions   2      3      5
Test Scripting    4      7     10
Pre-Testing       2      4      6
UAT Execution     4      5      8
Retesting         2      5     10

This gives the test manager some leeway, usually if things go okay it should follow the Probable estimates.  If they book the Best case estimates, be very worried.

What I'm finding is my project managers are taking my estimates, adding the Probable case figures together and times it by an hourly rate to get a budget. I don't know why I'm so surprised ... makes sense, but I'm used to working against time and not $$$.

Unfortunately at the end of the last two projects we've been considerably over that budget.  There seems to be several factors at play which determine which of those estimate paths our testing is going to follow, and it's important to understand and recognise them.

Software Delivered Late

You book in a test contractor to help you test for 6 weeks.  They arrive on week 24 to start analysis and scripting, with some test execution happening in week 26 for 4 weeks.

Then your chief developer tells you there's going to be a 2 week delay getting the build together, it won't be available until week 30 now.

You've made a commitment to your test contractor, and are so obliged to pay him, and possibly find them other work.  If you can't get them to assist elsewhere, then by week 30, you're 4 weeks in and not testing yet.  You've blown over half your budget, and Lord help you if there's any more delays!

We all know developers can often deliver late.  Late software is going to burn up budget.  You need to work with your Project Manager to make them aware of their duty to get software to you as scheduled in order for your budget to be met.

Software Delivered Is Of Poor Quality

Kind of the flip side of late delivered software.  Your vendor has promised that the software delivered has been unit and system tested, and no bugs were found.

You wrote your test plan for acceptance testing, expecting the software to have been extensively tested beforehand, with a certain level of quality.  Your project manager and you are expecting what's delivered to be a candidate for release.  You turn it on, and immediately notice a dozen problems, not able to finish basic use cases.

The developers under duress delivered what they had available to schedule instead of flagging any delays.  Little if any testing has happened, and basic bugs are being discovered only now.  Testing 101 says "more bugs = more fixes = more builds = more retesting".

One thing I try and do with vendors is ask for a release note and end report for testing, detailing what defects were found and what were fixed.  This is a bit of a game of bluff.  If I receive an end report which says “everything was tested, and no defects were raised” I get suspicious.  Very suspicious.

I've also had vendors on conference calls inform me “we're running a build up now, you'll have the install delivered in an hour”.  I pull my project manager to one side when this happens and warn them that maybe that will mean no testing whatsoever has been done …

The Delivery Chain

If you have developers on-site who you can give defects to, they fix, build, test it's possible to get a build almost every day.

If they're off site, only receive defects daily, have to courier builds, you'll be hard pressed to get a build weekly.

If you have two weeks to test, and have a daily build, you'll have 10 opportunities to get it right.

If you have weekly builds it's not likely to happen.  Your second build will have to be perfect – and it usually takes about 3-4 even with an initially high quality piece of software (there are always tweaks needed).

Time erosion

It's so easy to happen.  You have,

• a daily half hour team meeting
• a one hour weekly project progress meeting
• a one hour weekly project technical meeting
• a daily 15 minute end-of-day defect wrap up meeting
• each day you spend half an hour writing a progress report for the concerned business owner

Oh you're giggling there, but we've all been there.  Did you add it all up?  Yes, you're losing about a day a week.  Look at your estimates, did you plan on there being so much leakage?

I'm finding we're increasingly working on projects where there are a large amount of meetings to keep track of progress.  This needn't be a bad thing, and small meetings daily can help set the direction and key priorities of the day/week.  But it's easy for reporting to actually delay any progress being made, and become a sizable and unknown overhead in itself.

And some projects need test management – how do you budget for that?  It's not a solid “task” again more an ongoing overhead.

Requirements?

Requirements?  We didn't have time to write down everything we asked for!

Due to constraints a project has been only broadly defined, but you're required to perform specific testing against it, to a limited timeframe.  Oh and business analysts are too busy to answer your questions, so just get on with it and you know, test!

This is a nightmare position to be in.  You press a button, a message is displayed.  But you have no idea if it's the right message or not.  There are some things you can do – you can check the application didn't die when you pressed the button, and the message made sense in the context of the button.

But if you have vague requirements, you can only vaguely test.  Such projects really feel like they're setting up the test project to fail.  And take the blame.

Another variant of this is you raise about 10 defects against requirements, there's a review, and a business analyst says “oh yes these aren't defects, I asked for these changes by phone from our vendor”.  If things aren't documented, how can anyone keep track of these changes?

Take it easy.  Take it nice and slow.  That's no way to go.  Does your PM know?

Thankfully there's usually a place for these factors in a test plan under risks and assumptions.  But I can't emphasise enough to you the importance to talking them over time and again with your project managers before you embark on any test estimates, so they can understand and more effectively evaluate the risks and the impact to budget.

Testing's Men in Black

At a time when the world is watching the Rugby World Cup in awe of a certain set of men in black, it's interesting to see how this story has been doing the rounds on the internet – thank's to the Testing Club's Rob Lambert

http://www.t3.org/tangledwebs/07/tw0706.html

It's a no doubt apocryphal urban legend about IBM - but a lot of fun to read anyway!  In the 1960s the world of computing had a different emphasis – programming was a much slower business, and there was one shot at delivering software, no patching, it had to be right on release.

IBM supposedly found that programmers who wrote the code were blind to any faults in their software when it came to testing.  Some people though showed a natural aptitude, and thus one of the world's first test teams - “the Black Team” - came into being.

The Black Team were made up of the best-of-the-best when it came to breaking software.  They became a kind of bogey-man to terrify young developers, able to break any software they came across.  This tale here is just a brilliant parable of the supposed lengths they'd go to in order to test software ...

http://www.penzba.co.uk/GreybeardStories/TheBlackTeam.html

Tales of the Black Team go further, telling how team members started to form an identity together, wearing all-black to the white collar IBM offices.  Some even growing Dali-esque moustaches they would twirl sinisterly as they tested.

I'm very dubious – but I absolutely love how software testing, which feels sometimes like a very recent discipline (in New Zealand sometimes it feels not quite respected as a profession at all some days), has managed to pick up this urban legend.

But it also takes me back to one of my first posts here, on “what is software testing”.  The tale of the Black Team is all about a team who go out of their way to break things.  The story where they work out the resonant frequency of a large tape reader so it rocks itself over whilst reading a file is bang-on-the-money for a lot of people who see testers as people who just go out of their way to destroy.

Today in a management meeting it came out that the business owners see testing as a problem.  “The project was all going well until testing got involved”.  As if testers are responsible for the defects they encountered.  I think the reality is much closer to “we managed to delude ourselves that everything was fine until testing gave us a wake up call”.  If testing is done well there's no hiding the truth of where a project lies.

But no- testing is not about breaking things.  It's about proving quality.  And that can be a bogey man of it's own to a complacent project.

Steve Jobs - a legacy of quality ...

Steve Jobs has died today at the age of 56 …

He leaves behind him a successful legacy, with Apple computers now the most lucritive IT company in the world, having ridden out the financial recession where other companies have stumbled.

But is the financial ledger at Apple his only legacy?

I first heard about Apple with a passion back in 2003.  Lots of people in my C&C project were getting Macs.  It was explained to me by one of our developers “you know how on Windows, you try and install software, need to put an update on, has to reboot, won't work, then the update fails and trashes your installation?  On a Mac it just works”.

That seems to be part of the Steve Jobs alchemy – in a world where we're used to software not working first time, where we know we're going to get some quirks until there are a few updates, Apple seemed capable of making products that seemed virtually faultless.  In fact, it would become big news if any issues were found.

Here are what I think are several traits which have made Apple unique,

• They don't work to release deadlines.  They release a product when they're satisfied with it.  Only this week we had complaints that the iPhone 4 was 18 months old, and wasn't it time for a new one to be released?  Apple work to their own timetimes, releasing products when they're ready.
• Diversity.  Or maybe lack of it.  Nokia makes many brands of phone, a new one each month.  Apple only make one phone – the one you want.
• Simplicity.  Apple products are designed to be accessable by everyone.  Hence the uptake of their products includes people outside the normal “gadget freak” band.  So called “silver surfers” (older computer users) find Apple intuitive where Windows leaves them baffled.
• Quality.  As my developer so rightly put it, Apple products “just seem to work”  [It looks easy, but incredibly difficult to achieve]

It's ironic but many companies are obviously trying to chip away at Apple's lead.  They are envious of it's strong position, and hungry to take some of the market, so

• They rush out a product to be first to market.
• They cram their product with as many features as possible, hoping to beat Apple on specification.

But it never works out for them, because in their gold rush to feature add, their product suffers in the quality realm, and word gets out it's a stinker.

We all want a piece of the Apple pie.  I sit now on meetings which talk endlessly about the important of “customer experience”, the Steve Jobs buzz-word.  But when marketing types are talking up the planned “customer experience” they're not trying hard enough to bake quality into their products.  That's not taking on Apple, that's setting yourself up to lose your customers to Apple.

Today Steve Jobs was described as a contemporary Leonardo da Vinci.  I don't think that's right – as his genius wasn't so much in technology as in business.  I described him at work at a modern Henry Ford of computing – who also made products only in black.

But tonight, I think weighing things up, he was perhaps a William Denning of the modern computer age, a champion of quality, although of course, quality with a price tag.

Spinning Plates – The Test Manager's Stage Show

I've been a test manager about 6 months now all told ...  As a senior tester I used to scoff at what my old test manager got up to – but now I know!

If someone asked me what it's most like, to me it would be spinning plates …

We know the stage show.  Someone sets about 6 plates spinning, and keeps rushing between them to give them an extra bit of momentum to keep spinning and not fall off.

And that's pretty much what I do – our company has a whole host of projects in the pipeline.  I look at the future load for the next few months, and get involved in early meetings about them, review business requirements (if they exist), write the original master test plan, work out how much effort it should require to test, and try and organise test resources so we've got someone to do the actual testing.  And maybe a bit of sleight of hand to keep two projects from getting to testing at the same time ...

It means getting involved in a lot of projects.  Our department is part of customer delivery, and a lot of projects as you can imagine come through us for testing.  I always need to have a trick up your sleeve in case something comes late so we're not busting the budget.  Have a rabbit in the hat, just in case I need extra resource because time's running out.

As a rough rule of thumb (and don't tell my project managers) I always plan for myself to do pure test management … so when things get tight, I can go “all hands on the pump” and magic almost an entire tester out of thin air for 30(ish) hours a week.  Of course that can only be a short term band-aid, and on some projects that's not enough.

But all of the above can become tiring!

In Agile it's said you become much less effective if you're always task switching during the day.  Something like 20% they estimate.

Yesterday I kept track, and I worked on 5 projects during the period of the day.  Ouch!

Although joking about it on Twitter this morning I am starting to show some signs of fatigue.  Getting bits mixed up between projects, when someone asks me a question there's so much I am working on, it takes me a while to straighten it all out mentally.

At the beginning of the year after being “on the bench” (not working on site and doing desk based training) – I was sharp, eager.  Now come October, with an unforgiving workload, we're just getting by week to week.  All the promise of trying to improve processes in March has been whittled down to “just get it out the door” - and not by management, but by me.  The delays that are part of any testers lament have forced us into a level of technical testing debt, and we're having trouble getting things out to time because we're so close to delivery dates.

And I know I've talked about it before in this blog – but no-one wants to be the one to tell the business owner their delivery dates are unachievable, especially when everyone else is saying there's no problem.

I know people should have the courage to, but everyone quite rightly wants to give it their best shot at achieving it first.

So right now, I'm realising we're in a kind of testing deathmarch.  There are things we need still to get out this year.  But we have a freeze from late November onwards – I'm hoping we'll be able to catch up on ourselves a bit then, and hopefully set up 2012 for a bit of an easier year.

Otherwise I'm sure we're all headed somewhere in a very large basket ...

The strangest measure of stress

We are a stressed department – no doubt about it.  We have two very major projects going through user acceptance tests, and time is tight (hey it's a testers life).  Testing is “lucky” in being the same group across both projects.

Stress is a communicable disease.  To revisit the story of Chicken Little, all it takes is one stressed bird to set off the whole farmyard.

Sure enough we'll have a meeting and everyone leaves in a complete flap.  Then 3 hours later I sober up and remind myself I'd planned for this, and we'll be fine.  But under stress you forget such details.

I've become quite aware just how much my memory leaks (and it's not just me) – there is so much going on around it's hard for your brain to process the urgent from the trivial – esp as everyone thinks their part is important (remember marketing and the “wrong shade of green”).

I do an aerobics dance class (Body Jam) – it's my only vice honest!  It's both mentally and physically challenging – you have to build up a routine of choreography to execute over 55 minutes.  It's usually good stress relief, and I'm pretty good at it, but lately I'm all over the place.  Just lost.

That's kind of echoed at work, the stress is such you're so busy fighting fires you don't have a plan anymore.  Classic waterfall exhaustion.

I don't like stress, it makes us into different people.  Short term not so bad, but long term it reduces our effectiveness.  I've also had a colleague and best friend commit suicide because stress put them in such a bad place ...

So here we are ticking down the days, in stress and terror we might not reach our deadline.  But the real fear though ... the real fear is reaching it.  Because that makes this way of working "a successful way of working".  Oh my God no!

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!