Experience report on a Miagi-Do challenge

I was attending the test automation day in Rotterdam, where I had the chance to meet a few Miagi-Do fellows and took the opportunity to ask for a challenge.

Huib Schoots (@huibschoots), Jean-Paul Varwijk (@Arborosa) and Matt Heusser (@mheusser) gave me the chance and we sat down for it between some sessions.

Huib took the role of the challenger.
And, boy, did I took a learning that day. Sometimes I felt like in Vaders Force Grip. 🙂

I had some time for reflection since then. Here are my learning’s.
Traps. Some I was expecting, some were unknown (to me). 
I try to summarize the traps, as I see them and will mark my comments as well.

Trap: Surroundings (Environment). We had the challenge in a time-boxed environment (since the next conference session was looming ahead) and the noise level and distraction was varying as well.

Maik: This is not unusual in real situations as well; we as testers also have to deal with that.

If you have the chance, setup a quiet, concentrated meeting with your stakeholders. Try to have as few distractions as possible, phone, email, walk-ins, etc. Maybe changing to an alternate place (meeting room, go out for lunch) can provide already some focus.

Nevertheless. Have a checklist, mind map or some guide at hand. Maybe even sketch it out on paper. Having it only in your head can or cannot work.

Trust me, if you sitting with three people all making comments (intentionally or not) and a personality like Huib (:-)), it did really distracted me from my mental checklist and my brain became a distracting factor as well (shame on you, my brain!).

Trap (which I brought on myself): Preparation time.
Maik: After the challenge was given, I didn’t ask for some private preparation time. Even 2-4 minutes might have helped me sharpen my mental checklist to the current context. And nobody “forbid” it. But by not even asking, I lost out on that chance!

Trap: Challenge setup and challenger agenda
Maik: Since it was a challenge, I expected some “rules” and even “hidden rules” of the challenger (here: Huib). Knowing that there were some and actually recognizing them or even actually engaging them is different.

For example: I expected that the challenger would hide or avoid certain information, till I trigger them. But sometimes I felt, I was actively led astray.

Which is okay, since it is a challenge; but it adds an additional layer of difficulty.

In reality I would expect that the stakeholder, who is coming to me, would “play nice” and “play along”. As in, we are on the same side.

Example: Stakeholder has no clue about testing. I would expect that he would play with open cards and acknowledges that fact. Then I can adjust my role and help him better; I need to give him different information as someone who knows about testing.

But that is my assumption. This leads me to…

Trap: Intention of the stakeholder
Maik: One thing I re-learned again is try to find out the intention of the stakeholder coming to you.

Stakeholder can have different kind of motives. They can look for a scape goat, they can be totally clueless to testing, they can really want to help you with all they can contribute, they might have already made up their mind about the product and just want “proof” of their opinion, they might want to help, but have a different understanding of the context.

It is not easy, if at all, to find out the intentions of the person you are talking to; especially if they are unknown to you.

I knew Huib in person from five days at the Agile Testing Days 2012 (@AgileTD), so he was kind of “unknown” to me.

 

Now the last trap, which I brought on myself and which is the hardest to admit:

Trap: Hybris.
Maik: I knew and know, that there are a lot of unknowns to me.

In Testing, there are situations, I haven’t encountered yet or software bugs I haven’t seen or found. I read a lot; I had the chance to apply some of it and I am trying to keep up with information.

So I betrayed myself by believing, I could do the challenge and do it good. I didn’t expect it to be a breeze, but manageable.

Besides the fact, that I love riddles and puzzles, I also wanted to show to my fellow Miagi-Do’s, that I know my game and can step up to the plate.

If you are a tester with experience or a consultant with a lot of exposure, you should treat each stakeholder with your whole focus and concentration and take their request or questions seriously.

Serious in the sense, that to really think about what their request is, what their questions mean (to them) and not brush to fast over it, cause you have done it many times before. Maybe you are right, but sometimes you might be wrong and doing not a good service to your stakeholder as you could have done.

 

Conclusion

For me it was absolutely great to take on a challenge and get feedback from peers I respect. I wish we all could open one big company and work together on a daily base.

Even if I busted on that challenge, my takeaways made this experience worthwhile.

2. PotsLightning announcement

The second PotsLightning peer workshop will be held on 27th of October 2013.
It is lined up on the sunday before the Agile Testing Days 2013 conference.

Some people are arriving the weekend before and now they have the chance to attend also a workshop with peers in a relaxed atmosphere.

This year we will do an Open Space format as not to restrict the flow via setting a strict theme upfront.

If you are interested to attend, please contact us via email.
Should you already know a topic you want to talk about, feel free to sent it in the email  and we make a rough idea collection on the website.

Twitter Hashtag: #PotsLightning

Here are the information in short:

Date: 27.10.2013
City: Potsdam, Germany
Venue: Dorint Hotel