Maura van der Linden – Blog

Last week, in the course of commenting on James Bach’s blog, I explained that I liked to learn by laying my beliefs and understandings in front of others for them to question things I may not have questioned and, in turn, to question them to see if knowledge or views they have fill in something for me. James responded that this was called “transpection.”

It has a name? Who knew?

Transpection basically means to learn by putting yourself in place of another (to quote James’ blog post on transpection). This is different from introspection (contemplation of one’s own thoughts and feelings) and extrospection (examination of things outside oneself). It’s also different than the often-referred to “put yourself in someone else’s shoes” because you need to put yourself in someone else’s brain, really. It’s less role-playing where you imagine what that person might be thinking (which I think would be still be highly subject to your own views) and more based on really asking questions of someone else about a subject you are interested in.

Honestly, this truly fascinated me. I was not only interested in the fact there was a word for this process but the fact there was spurred me into reading and thinking about the process of transpection. As with many things that catch my interest, I mentioned it a few times and James kindly pointed me at a few other definitions of it.

Then James invited me to join him on skype to have him run me through a transpection session with him. This was a really interesting experience – not terribly comfortable in some ways and yet quite eye-opening in others. Now, mind you, this is coming from a person who has experience with James’ personality and does understand what he’s trying to do in advance. I got frustrated once or twice and felt obtuse several times but it was really fascinating to experience it and, at the end, hear what James’ response to the questions he asked me were.

I’ve read James’ list of problems with transpection on his blog and thought I’d give you my views:

• Feeling interrogated or tortured – I did feel a bit interrogated but wasn’t that part of the point? On the other hand, because I can see what the goal was, I knew repetition of a question/set of questions meant either that I had an interesting view or I really needed to look at my answers. Tortured, no – other than when I could NOT, even to myself, validate a stance I had taken. Time for that stance to go.
• Being judged – We all judge each other all the time. I expected it but, in return, I was judging my reactions and James’ approach too. It was definitely a two-way street.
• Being treated like a lab rat – Yep. But I had a psych minor and undergrads are the lab rats of the psych world. So it was familiar ground and I don’t feel demeaned by it at all. I learned and James learned and that’s the point.

What did I learn?

• I have fallen a bit into a trap of reliance on metrics and my own fixed idea of what a test/test case consist of. This is more limiting than I would have guessed, actually. This is probably rooted, at least in part, in having done test automation recently.
• My particular order of examination seems to put visual appearance lower on my list than many people would have it. I need to consciously push it further up my list to compensate. This is almost certainly rooted in the fact I have no real visual memory so it can be quite difficult for me to deal with visual appearance and it’s never my default behavior.

I saved our skype session so I can examine it a few more times to see what else I learn from it. I will note that I did experience a bit of James’ excitement when he hears something interesting. In this case it was my mentioning the fact I had no visual memory. The questions were rapid and many but I didn’t interpret it as sharp or angry – just very curious and wanting to gather information.

I will point out that this type of questioning does require that the need to “be right” or “win” be analyzed as well. I suggest that if you go into a transpection session to prove you are right, you will limit the benefits you can get from it. I also think this desire could be at the root of people feeling attacked or offended. Being right is not the point. Learning is the point and, to learn, you need to be willing to examine what you think you know and your views and reassess them in light of new information. If I went into this session with something to prove, I would not have gotten out of it what I did.

After the skype session with James, I ended up thinking more about my lack of visual memory and ended up trying a somewhat clumsy version of it on my husband, Chuck. I asked him questions about how he finds things around the house and remembers where they are. It sounds simple but it can be cause for friction. I thought it might be interesting because he, unlike myself, is highly visual.

• We both start by looking for an object in its designated “home” if it has one.
• If it is not in its home or has no home, Chuck pictures where he last saw it and looks for it there.
• If it is not in its home or has no home, I remember where I last put it and look for it there.
• If that fails, we both try nearby areas to the one we expected to find the object in.
• If that fails, we both resort to trying to figure out where the other person would have decided to put in instead and then check there.

It’s a very simple example but it pointed out something interesting to us. It answers the question of why if I cannot find something, Chuck usually can and vice versa. It also points out a symptom of my lack of visual memory. I cannot picture where I saw it. Instead I rely on where it SHOULD be or where *I* put it.

Since then I’ve done a lot of thinking about how I cope with my weird brain wiring and compensate for it, when necessary. I’ll have to write a separate post on that.

I have the dubious pleasure of trying to provide documentation for a small application that is basically a helper application for our product. It’s NOT complicated and it shouldn’t be causing nearly the amount of drama that is currently occurring. This has been probably twenty times more frustrating than my big project.

Now, one thing to understand is that the doc team (of which I am a member) is not integrated with the project team officially. We are a separate organizational unit. With the product team of my big project, they use Scrum and I attend their weekly planning meetings and the daily standups if I feel I need to. They are very transparent and I can check the tracking log at any time to update my plans.

This little project (a single program manager, dev and tester) keep telling me they are “agile” but they have no idea what they are doing beyond having a daily meeting which seems to take an hour every day, pestering everyone else and changing schedules and basic assumptions so quickly I swear I am getting whiplash. There is No Clue here.

I’m frustrated – VERY frustrated – at this point. My team does run on a Scrum process and I keep having to defend my prioritization, my schedule and deal with each time they change their minds and (often) never tell me. The following seems to be unclear to them:

1. Changing schedule dates – drastically – at least once every week or ten days does NOT mean you are agile. It means you have no idea what the scope of your task is and you are allowing schedule creep and bad planning to win while you rush to try to get this project out the door.
2. Changing core deliverables and/or concepts without talking to those you depend on to provide you with something you must have before you can ship and which these changes affect does not make you agile. It means you are risking your project, your shipping and your working relationship with these people you are dependent on because you either think you can push them into doing your will or you are incapable of remembering your dependencies.
3. Refusing to provide the requested information so a team you are dependent on can do their job and “rolling your own” version of what you think they need instead does not mean you are agile. It means you are unwilling to work with that other team and can come across as passive-aggressive or ignorant and the other team still needs the information they requested.
4. When given a schedule by another team, pestering for updates constantly when they are meeting their schedule does not mean you are agile. It means you are annoying them and making them less likely to try to get things done early because they are spending that precious time responding to random emails on things that have already been discussed multiple times.
5. Trying to push a release out the day before a three day holiday that backs up on a week when most staff are on vacation does not make you agile. It means you are foolishly focused on the earliest date you might bully people into shipping instead of having contingency plans for when things may go wrong
6. Asking for documentation to be done off a non-finalized UI to “speed things up” does not make you agile. It means you are asking your doc team to write documentation at least twice and hoping they catch any instances of the non-final UI before the docs ship. Skeletons are okay, but you won’t get RTM ready docs.
7. Shooting of wild plans from the hip does not make you agile. Disorganization, lack of ability to plan and think through processes as well as a lack of ability to track issues, decisions and schedules makes you a project from hell and someone that quickly becomes the person no one wants to work with.

That is all. My tongue may bleed soon from biting my tongue at work.

Today I was asked an interesting question about how I felt as a female tester and whether I thought I needed or wanted a group focused on Women in Agile.

I had to think a bit about my own history in test and remember the few bad times I’ve had as a female tester. Most of the times I had problems was not because of my skills as a tester but because of other people’s impressions of what a female tester was or could do. Their own prejudices were the issue. What did I do? In one case the person was outright disrespectful and I personally confronted them. In the other two, I did my job and I did it well and I refused to worry about what they thought of me.

When I think of any group called “Women in X”, I immediately try to figure out what the purpose of the group is. I am never a fan of any type of diversity quotas or rules. But I consider that there are HUGE numbers of ways to be different from another person. Things like skillsets, experience, interest, hobbies, etc. Being a female is a part of my makeup but it’s only a small part of the puzzle. I’m more likely to consider myself an Agile tester or a security tester than I am a female tester because I don’t think being female is a major point I bring to the table.

Is that wrong? I don’t think it’s wrong or right, per se. It is how I strongly believe in selling myself and how I try to judge others.

Another aspect to consider is that having a group like this also tends to polarize people (mostly men but some women as well). It carries undertones of political correctness, quotas and reverse judgement. A Men in Agile would do the same to some women, if you’re honest. It’s similar to the argument of why to have a Black Music Awards and not a White Music Awards. Someone is always left out and offended. It’s not unifying, it’s divisive.

As a female tester who works in an Agile environment, I’m not sure I’d appreciate the idea that someone put a divide between myself and my team, at least in some people’s perception. Agile is a much more collaborative and peer environment for test than many, does it need a division like this? Why just in Agile? Why not at a much higher and broader level?

I’ve been a member of diversity councils before and, in fact, worked with the women’s organization within Microsoft for over 8 years. I do believe that women should be given early exposure to all the variety of professions they could enter. Too many women don’t consider fields they could enjoy and be successful at because of misconceptions of those professions for the women in them. I believe this is a valid effort but I think this is true for some socio-economic groups and ethnic groups as well. Being women isn’t much different from any of those other groups other than it’s an identifiable social programming. I have issues when an effort to become and foster technology and technical skills becomes more about fostering resentment and a victim mentality than anything else. And it’s very tricky not to fall into that trap.

In this case, I do NOT know the charter of the group Women in Agile. I have no idea what they are trying to accomplish, why they feel it’s needed and what they think they can do. I’m purely talking about my own experiences here. They may have a great plan, I’ve not had a chance to check it out yet. Agile doesn’t seem to pose a unique challenge to women – most problems appear to be more women in IT than Agile in particular.

Diversity is valuable – ALL diversity is valuable. In my co-workers, I want as diverse a set of skills, knowledge, experience and aptitude as I can get. Yes, gender is a part of that but it’s not a huge piece. At least in my own case, I’m content with being a “tester” (though more a programmer-writer anymore) than a “female tester”.