Changing the Goal Posts

I got a chance to watch some Gaelic Football recently as my two sons have started playing hurling and gaelic football.  Hurling is a fairly ferocious sport where everyone goes for the ball with hands and sticks. Gaelic Football gives the appearance of being a far kinder sport. However, the Australian version (aka Aussie Rules), is a much more physical and aggressive game.  One thing that differs between the Irish and the Australian version is the goal posts. In Aussie rules points are scored when you kick through one of four poles, Gaelic, you kick into or over a pole. Little differences but really important to know and get right.

hurling

Adam Goucher had a nice post this week on communication and letting your team know where the goalposts are. Well I have had a similar goalpost problem. Except in mine, the goalposts changed. How I scored the goal had changed, and no-one had told me.

I have a very nice client (he’s a client, so he has to be nice, well in this case he actually is very nice) but new to the software development, and a grappling with some of the basics do’s and don’t to mostly people in IT take for granted.  It’s the basic advice they require most. Like, letting people know when things change, so I can relate to Adams comments.

I spent a good amount of time before the project, understanding who the stakeholders were, and the mission of the testing effort. I explained to them the many different types of testing I could perform, such as Usability, Performance, functionality, Installation and Configuration. It was decided to narrow the scope to robustness, it was a prototype after and all and as long as the screens did not crash, that would be satisfactory.

The day before delivery to their customer, there was a review. The stakeholders were dismayed at the state of the screens and the way the functionality worked. But I spluttered, “you told me you didn’t want Usability Testing”  What a frustrating experience. They had changed the goalposts!

The experience left me angry and frustrated. I had approached the whole exercise well. I had involved the stakeholders, I had worked out their mission. Why did the customer have to go and change their minds?

I suddenly felt empathy developers whose requirements continuously change.

It then struck me that in a way I was the problem. I was being too inflexible and rigid in expecting an inexperienced customer not to change their minds.

I’ve resolved to be far more open in my approach to what’s required (for this project). As long as the customer understands the financial implications of such decisions who am I to argue?

After all is not the customer always right?

One Comment

  1. Trish Khoo asked me this question on consulting in relation to the above post:

    “So I am wondering, if faced with that situation again, how would you approach it in a more flexible way, but still being able to limit testing scope? Like, would you try to figure out what extra requirements (such as usability) might be needed when discussing at the beginning? Or would you just keep an eye out for potential issues regarding things like usability, performance etc while testing, and highlight them to the customer if you see anything that looks like it could be a problem? Or maybe have a checklist of “light” tests in these other testing areas and run through them in addition to the robustness testing?”

    Initially I would still find out what they want up front, to determine their scope. This would always be my priority in testing.

    However, during testing, I would make more of an effort to discuss anomalies outside the agreed scope.

    For example, even though Usability is ‘out of scope’ I would say something like: “I noticed the screens looked really odd, is that how you want them….”

    I think time and money are always factors in deciding what you can or can’t test, I think generally, I would try and keep the communication verbal, as its quicker and cheaper than writing bugs.

    The key would be to put yourself in the position where you are able to discuss bugs outside the scope with your client during the project as opposed to leaving it to the end.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>