When does feedback or a discussion become an argument?

Someone told me that blogs should be personal. I also believe they should be relevant to your readers, and not just a complaint session. This may be one of my few very personal blogs you will see.

I wrote an article ago with Lisa Crispin on “Testers: The Hidden Resource”, and posted to a yahoo group asking for feedback. What I was looking for, was a response to our ideas. Did it ring a bell with anyone? Did our ideas really transfer over to non-agile teams? We thought so, but wanted other people’s opinions.

I have been a proponent of constructive feedback for years, both on teams and personally. I guess I expected constructive criticism from the group (wrong assumption). Don't get me wrong, we did get some of good feedback, but not all was constructive. That leads me to the topic of this blog.

What is the difference between a debate, discussion, feedback and an argument? My adhoc definitions (not from a dictionary) as I think of them are:

Debate: opposing views with rules
Discussion – not necessarily opposing views, just talking about a specific topic
Feedback – giving an opinion on a subject to a person
Argument (as in quarrel): opposing views without rules. Without rules, people play on emotions, and might use any form of one ‘upmanship’ they can find.

When I give feedback to people, I have been trained to watch how people respond to what I say. In email or in forums or yahoo groups, we don’t have the ability to watch how people respond. There are some not so subtle ways by using CAPS to make a point (email etiquette says that is yelling). But mostly, we can only take the words at face value.

As a person giving feedback, I cannot control how people respond to how I say things so I usually am pretty careful, but like everyone, I can trigger negative responses without meaning to. In our article, we triggered a few negative responses – not unexpected. What was unexpected was the ‘attack’… at least how I perceived it.

It is not necessarily what you say but how you say it. If you don’t care what the other person’s feeling, then discussions can quickly deteriorate into what I think of as arguments. Of course, there are people, like me, who react negatively to these types of attacks, and tend to shut down. I personally dislike arguments and yelling – I claim childhood issues. I have had my share of arguments and have not found them very fulfilling or useful. It is a no win situation. There are many reasons why people don’t want to participate in heated discussions and it doesn’t necessarily mean they are wimps for not participating in them.

On a personal level, I can take negative feedback, as long as it is not what I perceive as a personal attack or threat against me or a friend. I am the first one to say - it's not personal, but threats trigger an emotional response whether it is on a public forum or in a private email. I find I would rather shut down the discussion rather than enter into what I perceive as an no win situation or argument. It was suggested that some people might think I was wimp if I chose to do this. Maybe I am, but I can live with it.

I personally don’t read discussions that I perceive fall into a “contest of wills”, so I’m not sure why I would be expected to actually participate in something I don’t believe in.

So, back to the original question? When does feedback degrade into an argument? I think it is whenever someone takes the feedback as a personal attack, whether it is meant that way or not, and then plays to win.

Testers: The Hidden Resource

An article by Lisa Crispin and myslef just got posted on InformIT - “Testers: The Hidden Resource“. This was an idea that popped into Lisa's head one day when she was driving to work, after we had just finished the book. We think testers have a lot more to offer than most development organizations realize. See what you think, I’d love to hear your comments. Are we too optimistic or do you agree?

Check Lisa's website to see other comments as well.

Traceability

At the beginning of February, there was a discussion on the agile testing yahoo group on traceability. The original question was “How do you know what piece of code affects what user stories and what documentation and what tests?” since agile values working code over documentation. In our book, Lisa and I have less than a page on traceability and the first paragraph recognizes that traceability matrices were pretty much the only way to know what had changed and when in a traditional project. In agile those restrictions aren’t there. We have many other methods that provide an automatic trace from story to story test to unit test to code. These tests become part of the regression suite so that every time they are run, the story is tested.

If we think about that, why do we need to link the code changes to user stories? User stories, requirements, features evolve over time. Each story or feature builds on previous ones so the likelihood of a test being in sync with a user story is low. The need no longer exists. If you are using a continuous integration tool, you can see what code is being changed on every check-in if you really want to. It is easy enough to add in defect numbers in check in comments so that even defects could be traced if needed.

In my experience I have found the request for traceability often comes because history has shown that side effects occur because the developers haven't told the testers what exactly was changed and the final testing often showed up unanticipated problems. In agile, each story is tested as it is developed, with unit tests and acceptance tests and any other tests that it required (including performance, etc). If there are issues you find them right away with your suite of automation. I used to be a fan of traceability because it was the only way to understand what was changed. I have found I don't need it anymore.

Sometimes auditors will request traceability for regulated industries. If they don’t understand how version control works, or the power of automated tests, you may want to show them how you have automated traceability, and explain the cost of maintaining any type of manual traceability.

A related discussion about 7months ago on "Traceability Matrix in an Agile Project" and was summarized by Vikas Hazrati at http://www.infoq.com/news/2008/06/agile-traceability-matrix. One of the main points I got from that discussion is the difference between traceability and a traceability matrix. A matrix is just one implementation of the need for traceability. I also liked Michael Bolton’s reference “Transparency over Traceability" in his 2007 article entitled "Lean Traceability: a smattering of strategies and solutions" at http://www.cmcrossroads.com/content/view/9089/264/.

Before you blindly start a traceability matrix, ask the reason for the request and question the cost of maintenance against the benefit. In regulated environments look for the simplest thing that meets the need to provide evidence that the software works as specified. It may not need a full traceability matrix. Use your source control to your advantage. Use naming conventions on your tests that help identify what is being tested, or perhaps even integrate your requirments into your automation framework. Think simple to keep maintenance as low as possible.