Roundtables and Being Promiscuous

This post was triggered by a post on "007 Unlicensed to Test" about "bounce buddies" - people to bounce ideas off.

I use and really appreciate the use of bouncing ideas off of others. It's a good way to learn and refine your thoughts. I do this in my daily work. In another way blogging is a form of the idea bouncing - putting thoughts and ideas out to generate a discussion (I very much believe in blog discussion rather than blog preaching!)

I have two approaches to my "idea bouncing" in my work environment - one is informal and the other is slightly less informal (but not formal).

The Round Table
The seed for the idea came from my manager - a regular meeting of test leaders. I developed this idea into a roundtable discussion.

If you google for "round table discussion" you'll see different flavours of how they should work. The pattern we follow closest is here.

One of the ideas behind the roundtable discussion is to have a discussion of equals - all having an equal contribution - anyone can contribute with a discussion topic and all have the option to have a say.

The semi-informal gathering is a enabler for bouncing ideas - all are busy with different schedules of meetings and so having an opportunity of a small oasis to bounce ideas around is great. We only started this a few weeks ago, but it's been very positive so far.

I'd started a similar weekly meeting - with similar intentions - in a different group some years ago. Due to the nature of the discussions this became known as the "weekly complaints meeting". The current version is staying truer to the idea of a round table discussion so far.

Promiscuous?
I don't use this term in the sexual context but rather the idea of having an indiscriminent approach to who I bounce ideas off. This is infectious (again not sexually!) If you behave in a very open way about asking questions or views on ideas then the receiver is more ready to do the same back - ask their own questions or say "what do you think about xyz?"

That is a very positive result!

Firstly, you might not have the polished idea when starting to talk to somebody - but by the end of the discussion you're going to have clarified some things - maybe it was a bad idea, there were some points overlooked, you get a lot of positive feedback or you come up with a new idea on an unrelated topic.

Secondly, the other person is encouraged to ask you their own questions (assuming you respond) - re-inforcing the importance of a two-way flow in any discussion.

For me, this type of discussion typically happens by the coffee machine, in the corridor, a visit to somebody's desk or an email.


These two ways of bouncing ideas around and getting feedback have a very positive impact on my working life (even if the feedback isn't positive!) They are great ways to communicate and great ways to encourage communication.

Blogging is another way - although less fire-sure about getting the feedback.


So, do you actively bounce ideas around and if so what methods do you use?

Real-life maps & Testing

Two things triggered me to write this post...

I saw an amplified post from Jerry Weinberg on maps, here, and the ongoing Agile Testing Days in Berlin. I had a weekend in Berlin a couple of weeks ago - and I made a note in my notebook at the time.

After one day/night there I made a note "Map chaos: Scale and position on many Berlin maps do not correspond". Yes, I also had a testing perspective in mind.

I had looked at 4 different maps (from different sources) and none seemed to tie in or they all gave me problems of different kinds.

• On the plane I had been reading an flight magazine with a feature on Berlin nightlife - unfortunately their map didn't correspond to any of the other Berlin maps I had! I guess the map maker of that one was still under the influence when making the map - so yes, that was useless.

• After landing I decided to "go native" and travel as much local transport as possible. However, interpretting the map for the link between the airport and the u/s-bahn system was not straightforward (to my non-Berlin-trained eyes!) I eventually got the message by the time I was leaving!

• In my Time Out guide to Berlin all there detailed maps of the city centre (I was staying in Mitte - the centre) didn't have the street that my hotel was on - even though it was just around the corner from a main U-bahn station. This made even getting to my hotel tricky - as the last bit I did on foot. I got there by deducing which of the streets it must be based on the information I had of surrounding streets. Yes, I would've asked a passer-by but there weren't any...
  

• Then there was the map I got from the hotel reception - at least that one had the street of the hotel on it! This was the most heavilly used map. But even this one had problems - when trying to get to a local landmark we asked a taxi driver (you'd think they'd have a good grasp on the sites) and he was non-plussed. When we showed him the map and pointed to the place with the name, he called it something else as though it was obvious!

So what's the testing tie-in?

Yes, this works on many levels. Perspective (or context): You understand the map quickly if 1) you understand how the map maker made it, 2) you have a link to a common understanding of the mapping principles.

Take contours as an example - if you don't know anything about contour lines then they're not going to mean anything on a map - and you could end up trying to climb some big hills unintentionally!

Underground/subway maps are typically drawn from the perspective of having a neat/even distribution of the lines & stations to be able to show that in a "nice/tidy" way. They're not meant for guides to "how to get to the station if you're walking above ground".

So, what were the bad assumptions with each of my maps?

Map #1: It turned out that this map was not to scale and only vaguely correct where the rivers junctions and districts were concerned - it was very scant on detail. Lesson: If the detail isn't there (and you need it to make sense of the situation) be suspicious - start asking questions.

Map #2: No real guide how to use for the bus-ubahn connections - for the un-initiated. I don't mind "using to learn" but it would be good if the map told that's how I'd learn about it... Lesson: Sometimes you just have to suck it and see!

Map #3: Although the book was a 2009 edition my hotel straight was on a line with the "wall" - meaning that the street wasn't useable on the first maps that they'd based their guide on. Lesson: Use your own "fuzzy belief" or "fuzzy logic" - use the information you can see and confirm - where there are gaps use the surrounding information to help interpolate/deduce.

Map #4: This seemed to be the most accurate and useful map but it still was understood by some of the locals. They obviously had their own map (whether real or mental). Lesson: Synch'ing your perspective to someone elses is important (and probably underrated in communication.)

What more did I learn from the exercise?
These apply everywhere, but including our daily testing lives:

• Don't take anything for granted - especially when 4 different sources are giving 4 different versions of information. Don't take for granted that whoever you communicate with have a shared perspective - check that you're both "in synch".
  

• Always try and have an assessment of your own meaning of the situation. Take the data you're getting and make your own story - how you'd re-tell the story of all the information you've just taken in.

• Lack of data in a situation where you need it to make sense of the situation? Whether this is map reading or interpretting a customer requirement - it's time to start asking questions!

I'm sure there are more map-making & testing analogies out there. Anyone?

What's Your Testing Motto?

Do you have a motto in your testing work?

What's a motto?
Do you have a general approach to your work? Maybe it's an attitude or general starting position. Maybe it's something that sums up your team approach, your problem approach, the approach to test issues - it could be a separate approach for each or a single approach that works on many different levels.

When I first started as a trainee function tester (that was the job title) one of my first team leaders said to me, "Anyone will help you, but you will have to do the work."

Personal Motto
I liked that, adopted it and personalised it. I reframed it for my use as, "I'll help with anything, but it's you who needs to do the work."

This fits into the teamwork approach grouping of mottos, or phrases that sum up my approach.

On the face of it this could sound negative. I never interpretted it that way when first hearing it and have never meant it that way when using it. To me it is an enabler for teamwork. If used within a team it means that everyone supports everybody else within the team and also that everybody contributes to the team. So, from that perspective it's very inclusive.

I don't remember the last time I used the phrase (maybe 2-3 years ago), but everybody that works with me (including managers) knows about it, buys into it and I occasionally hear it used in front of me - so it's an idea that is easy to adopt and spread.

People like and see the value in it, whether it's called a motto, a phrase or an attitude.

Other Mottos?
Can I find a phrase that sums up my attitude/approach to problem solving and test approaches? Mmm, let's see:

Problem solving: I'm a divergent thinker and emergent learner, so I think my attitude has got to be broad coverage, initially shallow and follow-up on key areas.

Test approach: This is a combined top-down and bottom-up approach, trying to understand the big picture as well as digging into the details (a typical answer from a divergent thinker and emergent learner!)

Note, it doesn't mean that these approaches always work for me - but they are starting points.

Why bother?
You could ask the question, "why bother trying to sum up my testing approach?" Maybe you have a list of things that you could categorize that you use, something taking a page or chapter to discuss.

Well think of the example of twitter. Sometimes when trying to get a message across (in 140 characters) you need to re-think what you want to say, cut out the noise and try to distill the message.

It doesn't always work - sometimes you remove part of the message/meaning as well as the noise. But, try it as an exercise - what do you do, why and can you describe it? It's a very powerful exercise.

Do you have any mottos?

Can your testing approach or attitude be summed up in a few words? In your own words, or somebody elses...