Problem-solving with First-order measurements

Today I attended a meeting at work, where I noticed a pattern. It was a problem solving meeting. Problem solving in the sense that it was identified where we wanted to get, then identified where we are and between both positions is the problem that needs to be solved.

The target

The pattern I realized is the fact that it seemed to be pretty clear to everyone in that meeting where we wanted to be at. Though where we wanted to be was clear for everyone I suspect in retrospection that we had a shared understanding of this. The target was implicit. No one spoke up where this would be. Personally I think the target was ambigious and therefore not well defined. Recently I read a similar example in Quality Software Management Vol. 2 from Jerry Weinberg. The amibious term in his example was “Quality”. In his example everyone would like to have “Quality”, but he found out about the different understandings of “Quality” by asking control-questions.

The current position

Since there were just weak second-order measurements available and no common understanding of the situation at hand, it was hard to gather where our current position was. There was a lot of speculation. Since we were hit with a problem from our colleagues in a timezone three hours behind ours, we did not have immediate feedback. Instead we had filtered feedback through some emails and through participants who attended the chat the night before. This feedback was filtered, uncomplete and in order to find out the current position the meeting participants where vaguely speculating bringing in their own interpretations about the meetings at hand.

The problem

Overall we did not have a shared understanding of our target, no common understanding of where we were at this very moment. Therefore the problem we had to deal with was a meta-problem. The problem between the position where we wanted to be and where we were was fluent and not-distinguished. Therefore the problem to be solved in that meeting could not be understood and therefore not solved. The problem we had in that meeting had to do with the problem that we failed at the first two steps of problem solving and since this meta-problem was not solved, we could not solve problem.

Solving the meta-problem

In reflection in order to solve the meta-problem here are some alternatives that could have helped:

  • Shift the meeting to a later time, so that our colleagues can give us direct feedback, rather than relying on emails and filtered or biased feedback.
  • Abandon the meeting when you find out the participants are not prepared with the information available at the meeting start. Usually you just need to this once in a learning culture.
  • Have a skilled facilitator, which is prepared and has no hidden agenda. This is difficult to realize in a project, which needs to hit the ground this year in recession times.

When you’re faced with a meta-problem the next time and realize it, pick your favorite from this list.

Exploratory Testing – Learning

Over the course of the Agile Testing Days in Berlin I realized why Exploratory Testing works. Personally I found a model from my past, which explains Exploratory Testing based on face-detection systems. After some initial feedback I decided to break it in three different posts: Learning, Scanning and the Differences. I will start with the part on Learning.

Continue reading Exploratory Testing – Learning