About me
•Kiwi based in Sweden
•Work at House of Test
•Title: Test Consultant
•Started/co-started 2 testing meetups
•Avid fan of cooking shows
•Board game fiend
@NicolaO55 #AgileTD
The two things people hate
the most:
how things are and change
@NicolaO55 #AgileTD
What you’re up against
” It's not just that people fear change, it's also that
they genuinely believe (often on an unconscious level)
that when you've been doing something a particular
way for some time, it must be a good way to do
things. And the longer you've been doing it that way,
the better it is.”
@NicolaO55 #AgileTD Source: https://www.huffpost.com/entry/why-we-dont-like-
change_b_1072702
My context
•“Agile tester” / Test consultant
•Had the support of someone with a “leadership job
title”
•Large, rather international project
•Project was moving towards an “Agile way of
working”
•People had to write test cases
@NicolaO55 #AgileTD
Why try to bring in change if you don’t have a
leadership job title?
•A title is just a title
@NicolaO55 #AgileTD
Why try to bring in change if you don’t
have a leadership job title?
•A title is just a title
•It can inspire others to come up with and
bring up their ideas
@NicolaO55 #AgileTD
Why try to bring in change if you don’t have a
leadership job title?
•A title is just a title
•It can inspire others to come up with and
bring up their ideas
•Good ideas won’t necessarily come only from
people with a leadership title
@NicolaO55 #AgileTD
Influence:
the capacity to have an effect on the character,
development, or behaviour of someone or
something, or the effect itself.
@NicolaO55 #AgileTD
What’s in it for me?
What do you want to change?
WWIT
@NicolaO55 #AgileTD
What’s in it for me?
What do you want to change?
Influence
WWIT
@NicolaO55 #AgileTD
What’s in it for me?
What do you want to change?
Influence
Trial
WWIT
@NicolaO55 #AgileTD
Danke schön!
•Feel free to keep in contact:
•Nickytests.blogspot.com
•Nicola.owen@houseoftest.se
• Recommended reading:
Explained: Why We Don't Like Change
@NicolaO55 #AgileTD https://www.huffpost.com/entry/why-we-dont-like-change_b_1072702
Editor's Notes
Work at House of Test
Kiwi based in Sweden
”Test Consultant” what I actually do, depends on the project I’m on (everyone on my project is a test consultant)
When I was talking to my fiance about my talk and he was giving me feedback on it, one quote came to his mind:
The two things people hate the most: How things are and change.Sometimes I (and other people) complain about things at work; the way things are. But just as often I hear people complain because something has changed, or they heard change is coming.Even though, people seem to dislike both, I think it’s a lot easier to leave things, as they are - than make change happen.And that’s what I want to talk about today: My experience in bringing in change……... when I didn’t have a leadership job title.
“Agile tester”
Test consultant
Had the support of someone with a “leadership job title”
Waited a few months
Large project - had been ongoing for many years
Rather international project - various nationalities represented in testing including Swedish, Egyptian and Indian
Project was moving towards an “Agile way of working” yet to figure out exactly how testing fit into this puzzle
People had to write test cases, lots of upper management liked to have these for their reporting
When I started on this project - I remember being warned about how others had tried to make change happen in this project and things were slow moving. I had never been in a project with so many dependencies, so many different test teams and environments etc. At the start, I just wanted to get an idea of what’s going on in the project.
Once I looked around me, I realised there were some opportunities for change.
The most obvious one was to introduce exploratory testing. There was constant talk of the project becoming more Agile - and we were constantly getting squeezed for time for testing.
I found that while there seemed to be plenty of time to write test cases, while testers were waiting for the features to be developed, there was hardly any time to actually run them. Deadlines were fixed, so there was a rush to execute a lot of test cases and deal with the admin that comes with executing test cases in a test case tool.
When I asked around about why we are using test cases - the answer I got was because that’s how it’s always being done. For me, that wasn’t a good enough reason to not change things.
The second thing I noticed was the lack of visibility and clarity around testing. Testers were “testing”, or “writing test cases” or “executing test cases” but really what exactly is happening?
I thought a low tech dashboard could help here.
Lastly, there was an opportunity I saw, which was one that the test manager pointed out to me.
Who here has heard of a test assessment?
Now, this was my first time coming across a test assessment. To me, words really are just words - so I was pretty excited to actually see one.
A test assessment was kind of like a checklist. It was a mandatory checklist with the same questions for each feature and this had to be done by a test architect, not by the development team.
Taking a step back, the test manager and I discussed - what exactly is this document trying to do?
It seemed to want to investigate the risk of this feature, what needs to be tested and what is needed to test this feature.
Now to address this, what questions would be better to include?
So we created a different list, but we said: this is a suggestion; a starting point
Your goal is to investigate risk, and see what needs to be tested, and how etc.
I then organised a workshop around this.
People figured out the value a test assessment was supposed to add, we ended up coming up with something new called a “test analysis” I think it’s better to let people figure out a process that fits the current state of things, instead of something that was setup for the past.
When I was trying to change things in our project, I tried to take a step back and ask myself.
For the people who are affected by this change, if they asked themselves: “what’s in it for me?” what would they say?
Since I’m not a mindreader, I asked people in our project questions - lots of questions.
I wanted to know what people liked and disliked about our project. What did people struggle with?
By catching up with people, I started to get an idea on what the answer would be for them: if they asked themselves “what’s in it for me?”
For me, a title is just a title - it’s a rough indication of what I am expected to do at work BUT someone with the same title could be doing something very different at work
If you have some good ideas, and you want to make them happen - I don’t think a lack of “Formal authority” should stop you.
I did find that in my project where I tried to make change happen - some people only seemed to consider my ideas at all, because they had the support of someone with a “leadership title”. Meanwhile, there were others who looked at the ideas for what they were, regardless of who came up with it.
I think having people see that someone who has ideas, who doesn’t have any “leadership title”, actually make something happen - can make people think. “Well maybe my voice matters, I think “this idea” could be a good idea, why not say something?
Why not open the floor to everyone? Not just to ones with apparent authority.
Influence
Titles may come with influence but influence and an ability to make change - can happen without a title.
A leadership title and having influence are NOT the same thing.
But, I think a degree of influence is needed to make change happen, whether or not you have a title.
So then how do you build influence?
(How did I build influence?)
Earn Trust
This takes a bit of time, but the main thing I did was to stay true to my word and be a clear communicator. By this I mean, if I said I would get something done, I got it done by when I said I would. If I didn’t know something, I said so. If I said I’m unsure but will get back to you, I actually followed up. If I said that I should be able to get it done by a certain day, but I need this criteria to be met - then I kept people updated so they knew that the criteria wasn’t met - so I was currently blocked.
Get buy-in from the right people
For me, at this project, this was very important. Aside from the fact that I had the test manager’s support for some of my ideas, I also had the buy-in from a lead developer/solution architect in my team who people seemed to follow. So by convincing him of my ideas, I found that other developers and managers in the project were more open to my ideas.
I find that you don’t actually need to convince everyone, or even a lot of people of your ideas - but there are probably a few key people on your project who you SHOULD convince.
Let’s try it
On my project, when I was talking to my test manager about introducing exploratory testing to my team, she suggested to me that we introduce it “as a trial”
If you want to introduce something new - one way to approach this is by saying: Let’s try this for a few days/few weeks/few months. And then see how it goes. Assuming it’s a good idea and people are happy with it - they won’t want to go back. The thing is, convincing someone to “try something new” is a lot easier than convincing people to change things.
Another thing about having a trial is that, based on my own experiences, people don’t seem to like change - but then they get used to it.
By introducing a change as a trial, people will think that they can easily go back to how things were - which is technically true. But realistically, I find that once you’ve had a few weeks (or a few months) of a different approach - you might not want to go back to how things were.
Introducing Session Based Test Management to my team meant that the testers in my team had a lot more freedom to structure their testing in the way they saw fit, and they could explore opportunities. The testers in my team also found that testing felt like more of a mental challenge (in a good way) with Exploratory Testing.
After about a month, the other testers in my team and I discussed how our trial with Session Based Test Management had gone, and guess what - they were pretty happy to continue Exploratory Testing using Session Based Test Management