Archives for category: People

Coworker: I like this site. But not the stuff in little grey font, just the big bold ones.

Me: So, just the original Agile Manifesto, then?

Coworker: Yeah.

This isn’t actually testing-related. I’m on the board of a small non-profit organization. We have monthly business meetings wherein we try to figure out where we’re going in the future. We have roughly two factions – those who want to make sure nothing changes, and those who want to change things. Individual members shift position depending on which issue is being examined, which I suppose is not a surprise.

It seems to be an unspoken rule of the group that things are settled by consensus. I say “seems to be” because I am new; all the major decisions we have made during my tenure of a few short months have been unanimous, often with long-suffering looks, big sighs or other signs of annoyance from some of those voting aye, and most often from the people who opposed it. This is a toxic dynamic.

Always requiring consensus creates resentment when someone votes “yes” but means “yes but.” Even worse is someone voting “yes” because they feel they can’t say “no.” This is destructive to the team, the individual, and confidence in leadership (if this were at work, I’d be more likely to dismiss the latter point; an agile team has very little need of a leader in my experience, but that is a different post entirely).

I’d rather have the “yes but” out in the open where it can be addressed instead of having to ferret it out from under the guise of conformity. Yes, it’s uncomfortable to vote no in public – especially if you are the only one voting no! At the same time, voting yes and complaining about it later because you didn’t really want to vote yes is harmful in a number of ways.

Voting no is scary, and if you’re a person who values conformity, can be extremely difficult.
Voting yes when you mean no is a betrayal of your own decision, and possibly a betrayal of your own values.

It kills self-confidence to turn around like that (or at least it does for me.)
It kills confidence in the group to have someone who supported you complaining bitterly to your face about how they wish they hadn’t. How can one trust a vote again if people are not going to vote to the best of their ability to analyze and make decisions, but instead follow along with something they don’t like or even agree with?

Forcing conformity through a perceived norm does all of that. I’m not sure what in the group dynamic means that everything has to have this unspoken conformity, but I want to try to tease it out. We don’t need this.

We need – all of us – the ability to vote no without the cloud of shame hanging over our heads.

I am not a fan of conflict across departments. You know the kind – the DBAs don’t like the software developers, the developers don’t like QA, QA wrangles constantly with the project managers. All that kind of conflict manages to accomplish is spreading strife and interfering with a process that, from my point of view, doesn’t need any more interference.

Where I work, QA does wrangle constantly with the project managers. We have different ideas of what “quality” means. We have different ideas on how long, exactly things will take (and the software developers are different again.)

In the interest of fostering communication across departments, I am going to do a little cross-department snooping: I’m going to shadow with the product owners, find out how they do what they do and why, and see if I can’t feed it back into the QA process.

This ought to be interesting.

In the world of testing, we use words.

These words are things like “Load testing, penetration testing, functional testing.” These words mean things, but not the same things to all people all the time.

If I say “I need to load test this product,” and mean that I want to see if it can hit a certain performance goal, and a coworker thinks that I mean I am going to load it until it breaks and see where the break point is, we are likely to have an argument about the best way to do it and whether it even needs to be done. Here’s the thing: that word “Load Testing” can mean both of those things in different products, or even the same product.

How do we come up with definitions that work for us? Maybe we don’t use the same word to mean three things. “Context” is another big one; I can talk about the context of a program, meaning the environment in which it runs; the context of a discussion, meaning what cultural or immediate environmental issues have invluenced it; the context of a bug, meaning what I had to do to make it happen. All of these rely on environmental cues, but.. get this.. you have to pull the meaning from the context.

Maybe instead of saying I am going to load test a product, I should say that I am going to verify that the product meets its performance goals. That removes the destructive connotation of the load-it-til-it-breaks kind of load testing. Maybe my coworker should refer to destructive load testing, and make it very clear that when zie’s finished, that product is going to be down or at least misbehaving.

Either of those or both would be good options, but neither is as short or snappy or convenient as just saying “I’m starting load testing today.”

There comes an additional layer of confusion when technical and nontechnical members of the team refer to a single thing using different words, or worse yet, use a single word to refer to multiple things. To me, a “spec” is a series of statements telling the developers what they will be doing with a product. However, coworkers on the team, but not the technical side, have referred to the program itself as a spec. This has led to enormous confusion.

How do technical team members communicate to nontechnical the difference between the map and the territory?

If they tell me I am receiving a spec today, and I got it two weeks ago, I am going to be understandably confused, and the product owner will be understandably upset when I ask for clarification, thinking that I’ve had the product for two weeks and have not tested it.

Communication problems are the root of the great majority of interpersonal issues I deal with, and they could be solved so much more easily if we would slow down and use the right words. While the meanings of words are not absolute and users of language must be sensitive to context, neither should words be used for things they are certainly not.