Organisation

Don’t make it easy to be ignored

Most people hate saying no. Our reluctance to disappoint someone, or a fear of conflict, can lead to us doing all kinds of things that we didn’t intend to do just because we couldn’t, or wouldn’t, say no. Our fear of saying no often extends so far that we’ll avoid putting other people in a situation where they have to say no, just in case they feel as bad as we do. The result? We don’t get what we want. even worse, we never learn how to effectively ask for what we want.

There will be times when you have to ask for help, and failing to get people to agree will mean things don’t happen; things like events, because you always need speakers, or parties. At work it becomes even more pressing. Modern workplaces are built on collaboration so you might find that you can only succeed with the help of others. The good news is that almost everyone working in these collaborative environments is expecting to be asked for help, you just need to learn how to do it.

Step 1 – Know what you want. 
It is very hard to ask for something that you don’t understand or can’t articulate. Take some time to decide what it is you actually need to ask for. Is it time? Budget? Assistance?

Step 2 – Be Specific.
Often the way we ask for something is the problem. Either through inexperience or nerves we make the request so vague that we become easy to ignore. People are busy, they might not have time to dig through your long statement to try and work out if you asked for something without actually asking for it.

Step 3 – If the request is crappy, or if you know they’re busy, you need to appeal to their ego.
Everyone has an ego. Appealing to it can make a huge difference in helping someone decide if they’re going to help you or not.

Here are a few examples to show how these three steps can make a huge difference:

Example 1

Other person: “So anyone able to tell me anything about X?”
Everyone else: Thinking – I’m not sure exactly what she wants but this little thing I know probably isn’t important “…”

A more effective version
Other person: “So I’m stuck on this bug. Anyone worked on this code recently? Amy didn’t you look at it recently?”
Me: “Nope, that was this other thing but I think Adam might know more”
Adam: “I don’t think I know much more but let’s pair and work this thing out!”

Why it works: Explaining why you’re asking for something helps. Targeting an individual within a group will always be more effective than a vague full group address. If you don’t know who to target just pick someone who is responsive, diligent, and kind, they’ll help you find the right person.

Example 2

Other person: “I was wondering if you were going to be in the office tomorrow?”
Me: Thinking – umm, that sounds like it could lead to something bad… “Umm, so I’m not sure yet. Why…?”
Other person: “Ah, I was just looking for someone to do this crappy thing for me”
Me: ….

How this could have been better
Other person: “Could you do me a massive favour and be in the office to look after X tomorrow? I think you might be the only one around who can help”
Me: Feeling needed – “Oh hey, yeah sure, tell me more”

Why it works: There are three parts to the success of this one:
– You acknowledge that you’re asking for a favour. And you actually ask them for something instead of making loose statements.
– You’re up front about the crappy thing you want someone to do.
– You appeal to their desire to be needed (very effective!).

Example 3

Other person: “So I’m looking for people to talk at this event”
Me: Feeling a bit interested but also busy “Oh hey, yeah maybe one day…”

How this could have gone better
Other person: “Oh so I’m organising this event (and it’s going to be awesome because of X) and I’d love you to come and talk about Y”
Me: Feeling flattered but still busy “Oh really? Well sure, I’ll see if I can fit it in”

How this could have gone even better
Other person: “Oh so I’m organising this event (and it’s going to be awesome because of X) and I’d love you to come and give that talk you gave at Y. I really loved it.”
Me: Feeling loved beyond belief “Oh really? Well sure!”

Why this works:
You’re selling your event to the person by telling them why they should care.
You’re explaining why you’re asking this specific person.
You remove a load of work for them by telling them you want a specific, already existing, talk.

So next time you need something to happen take the time, and a deep breath, and actually ask for what you want.

Advertisements

Should developers own acceptance tests?

A couple of weeks ago I watched a talk from Dave Farley that said developers should own acceptance tests. It’s a great talk, you should watch it if you haven’t already. Afterwards I realised that I was going to have to write this blog post to explain why I thought the talk was brilliant, but misleading.

First, let’s define acceptance tests. Dave explains them as “trying to assert that the code does what the users want the code to do”. For me they are the tests that we perform (with, or without tools), to decide whether to accept a feature/system or not.

Dave’s talk addresses an important topic. Namely that testers shouldn’t be the owners of these tests. I totally agree with this statement. In all the projects I’ve worked on, I have never seen a test suite solely owned by testers being a useful thing. Of course the testers usually design brilliant tests, and these tests often uncover serious issues before any code gets released but they are still a terrible idea for two reasons.

Firstly, we have an entire suite of tests that exists and runs without any developer involvement. Unless you work in a team that really doesn’t think about testing in any way before code get handed over to testers then this is going to cause test duplication. If your developers really don’t think about testing then you probably have some serious silo issues that need addressing. Go and sort those out before you read the rest of this post. But seriously, developers think about testing all the time. Allowing acceptance testing to be separated from development is going to guarantee duplication in tests. It’s also likely to guarantee some gaps in testing as the approaches of developers and testers are not joined up.

Secondly, testers are brilliant at designing tests. We should expect them to be able to turn up some issues, many of them fundamental and serious. Why wouldn’t we want to do that much earlier in the process? Acceptance tests are usually run against a release candidate. Often a release candidate contains one, or even several weeks of work. Waiting that long to run these tests and then turning up a problem is going to make for some expensive re-work.

In Dave’s talk he argued that developers should be the owners of acceptance tests. To me this sounds like a bad idea. Acceptance tests should be a measure of how well the feature meets the requirements. Developers are probably least qualified, or at least biased enough, to be unable to make this decision. That’s not to say that testers should be the owner either. We still want to avoid creating any kind of “wall” for code to be thrown over.

So who should own the tests? Maybe the team would be a better owner. If acceptance tests are truly going to be a measure of how well the feature meets requirements then it seems to me that a business/product owner needs to decide what gets tested. So we ask the business owner to define the journeys that need testing. Testers know a lot about designing good tests so the Testers should be helping to turn those journeys in to good test scenarios with suitable test data. Developers know how to write robust code so the Developers should be writing and maintaining the tests.

The end result is a well designed, and implemented test suite that actually tests something the product owners wants to have tested.

This collaborate test design brings together the strengths, and input, of the entire team. We give testers the opportunity to uncover issues, but the collaborative nature of the test design means it’s likely to happen far earlier that it would if testers own the tests. Maybe even at the test design stage instead of a week later during release testing. Developers can write the tests and avoid many of the “tester written test” issues. The test scripts get treated as any other code, written and maintained by developers. Finally the real strength of this approach is being able to involve the business owner in the discussions. Hearing about the things they’re worried about right at the beginning can have a massive impact on the design and implementation of the feature.

In fairness I think Dave was actually arguing for exactly this approach. Developers should absolutely be at the heart of acceptance tests but I don’t think we should use the word ‘own’. Teams own things, not individuals. The right group of people collaborate to achieve the best result.

An efficient tester

Are you efficient? Do you work in a well-organised and competent way? I think most of us aspire to be effortlessly organised, to be in control of our lives. Some people raise children, run businesses, and still manage to find time to file their papers. The rest of us go around in a haze of hastily bought birthday cards, missed appointments, and mental to-do lists.

Unfortunately efficiency isn’t something that turns up in your life to sort things out like a benevolent fairy godmother. Efficient people have systems and techniques to help them organise their life.

To-do lists are a great way to keep track of tasks but if yours looks anything like mine they they can get overwhelming. Spending time at the beginning of each day choosing the most important tasks, the things that really, really, must happen today, can help. Once you’ve chosen the ‘must do’ tasks you simply hide everything else away for another day.

Batching tasks can also be a great way of saving time. If you have three bank transfers to make then doing them all at the same time will save you two online account log ins. Bulk buying birthday cards will save you multiple trips to the card shop. Grouping meetings together keeps useful chunks of the day available for hands on work.

Tools like Evernote, Feedly, and Instapaper help save important, or interesting things. I find the volume of interesting articles shared on Twitter to be overwhelming. Setting up an IFTTT channel to save starred items to my Evernote account has been a huge help. Now instead of trying to read or categorise links as they come up I save them away and deal with them all in one go.

Automation can be another way to remove waste. A simple automated script to create test users, or set the system under test into a desired state can save considerable time and effort. However, as with all automation, there are creation and maintenance costs associated with getting the script running, and keeping it running as the system develops.

Recently the fantastic Danny Dainton reminded me how important it is to automate small tasks as well as big ones. Removing a couple of mouse clicks a day might not seem like much, but over time those seconds will add up to big time savings.

One of my favourite tiny tasks to automate is editing URLs. When I’m testing I frequently switch between test environments and production ones. It only takes a second or two to highlight and change the necessary part of the URL but over an entire day these few seconds start to add up. A simple JavaScript bookmarklet takes this tiny task and makes it a simple button click.

As I go through my working week I look for monotonous, or repetitive tasks. Are there ways to batch these tasks? Can I use Boomerang to schedule emails in advance? Maybe I can find, or create, a tool to do this task for me. Each time I save time, I’m creating an opportunity to do something better, to become a more efficient tester.

How do you make yourself more efficient? Do you have a favourite tool or script to help you?