Something to Say . . . Techniques to Free Communication Logjams Agile Testing

If the problems are the same, so are many of the solutions. The methods I am going to suggest are tried and tested inside and outside IT projects. Because all humans carry taken-for-granted assumptions about the world, it is easy to believe that our communication preferences are the correct ones. We need to understand and empathize with others;they may have different preferences. As the team interacts, it will need to build understanding between the team members to help build shared assumptions and hence trust.

Although many taken-for-granted assumptions are shared, there will be differences between cultures, organisations and family/friendship groups. Just because you “always do it that way” it does not mean it is the right way. One of our assumptions can be that others will share our taken for granted assumptions. If we discover that other people have different core beliefs, we are surprised and may dismiss their views as wrong–it is hard to see other people’s view.

We may also assume that other people communicate in the same way as we do, that they share our sense of humour, use body language in the same way, and share our preference for written, pictorial or verbal messages. I recently had a discussion with a colleague because we could not understand each other.

It turns out that we used two key phrases in opposite ways, both equally correct but meaning the opposite to each other:

  • I had used “I think” to mean “I am not sure” but my colleague had used “I think” to mean “I am certain.”
  • My colleague had used “I feel” to mean “I am not sure” but I had used “I feel” to mean “I am certain.”

These communication differences are increased by cultural differences between organisations, and between colleagues from different types of organisation, and from different countries.

The following sections review a couple of techniques that I have found valuable in freeing communications logjams, specifically De Bono’s Six Hats in a Meeting and cause and solutions analysis with Ishikawa Fishbones.

Technique 1:De Bono’s Six Hats in a Meeting

Sometimes collaboration can be held up by conflict–personality clashes, insuperable arguments, and endless, unresolved conflict. We find ourselves always contributing in the same way–pessimistically, optimistically, coldly, or emotionally! And we notice that other people are equally predictable. As a consequence, we find that the meeting dissolves into acrimonious chaos, with people no longer on speaking terms. Can we do anything about this?

Edward de Bono decided that we could, and the Six Thinking Hats was the result. I first came across it as an idea for improving software projects from Jens Pas’ EuroSTAR presentation and workshop as a means of introducing emotional intelligence to rationally biased software projects–in other words, allowing fact-based people an opportunity to also express emotional views. The “six hats” encourages people to take different roles at their meeting. It allows them to deal with one problem at a time and to focus on resolving problems. You can refer to the hats in two ways:You can define the thinking process that’s required in a given situation, or you can comment on how someone is communicating without appearing critical. So you might be struggling with an apparently insurmountable problem, and call on the team to put on their green hats to generate some ideas. Or you can ask someone who’s getting negative to take their black hat off for a moment–this is a more neutral request!

By using the hats we set rules for behavior. Everyone wears the same colour hat at the same time, and the hats are not associated with particular people. This allows meeting members to move outside their perceived stereotypes and allows time for different, sometimes difficult types of communication. De Bono discussed the order and way the hats are used; it depends on the meeting and the problem, as well as the team’s experience in using the techniques. Suppose we have a meeting to discuss a design for an interface.

We might have a meeting agenda like this:

  • Blue hat to set the scene–why are we here and what do we want to achieve?
  • White hat–what facts do we have that everyone can agree on?
  • Red hat–do we like or dislike the design–what is our gut feel about it?
  • Yellow hat–hat are the good things about the design?
  • Black hat–hat disadvantages can we see?
  • Green hat–can we identify new ideas to help us overcome the black hat points?
  • Red hat–how do we feel now?
  • Blue hat to close the meeting-what are the next steps?

The advantages de Bono identifies are

  • powerful, focused working, which is time-saving because the meeting is not filled by confrontational arguments;
  • removing of ego by removing confrontation, allowing the meeting to deal with
  • one thing at a time.

All the ideas from all the people at the meeting are treated as parallel rather than confrontational. Once a complete picture has been arrived at using the Six Hats, then it is easier for people to agree to a solution or make a decision. We can use the hats to change focus: “It looks like with the yellow hat thinking we’ve identified some real advantages to the approach we’re discussing. Let’s just try some black hat thinking–what are the disadvantages?” You can find more information about de Bono’s work on thinking, including the six thinking hats, on his Web site.

Technique 2:Cause and Solution Analysis with Ishikawa Fishbones

Cause–effect analysis helps us look for the root causes of problems, using causeand- effect diagrams, sometimes called fishbone diagrams because of their shape orIshikawa diagrams after the person who first developed them, but now widely usedin identifying quality and other problems.

Put simply, this is a structured form of gathering and sharing information, either in a brainstorm meeting or as work is going on, day to day. It is used in factories,with a blank fishbone on the wall in easy reach by a production line, so that anyonecan add an idea about the cause of a problem or a potential solution.

Periodically,the group working on the production line will discuss the information and ideas gathered in the diagram and decide on problem solutions.This open approach with simply documented ideas to which anyone can contribute lends itself to lean manufacturing nd to agile project teams. In both cases,the teams are empowered to analyze and change their own processes to facilitate fastimprovements.The diagram is simply a means of helping us think about and classify the causesof problems and their underlying root causes. The first step is to draw a fishbone diagram with the effect(which is the problem or symptom noticed)on the head of

Ishikawa fishbone

Ishikawa fishbone

the fish. Then, label the ribs of the fishbone to show typical areas of root cause. You can choose your labels. Typical ones are “The 4 Ms-Manpower, Machines, Materials, Methods” or the “PEMPEM” labels, which give People, Environment, Methods, Plant, Equipment, Materials ,or you could make up your own labels.

In a traditional project, a brainstorming meeting would be called to generate causes for the effect, grouping the ideas on the fishbone to show how they relate to each other. In an agile team, the fishbones could be started on a whiteboard or flipchart in a brainstorming session during team meetings or between team meetings as people have problems to solve; ideas can be allowed to incubate naturally. Even for a traditional project, we would want to put the diagram on a public board so other people can see it, comment on it, and add to it, and so that the people can suggest other causes. The diagram in Figure shows the very start of a discussion of a problem: the first two ideas have been added. Notice that–because we are looking for a root cause–we are not just adding ideas at the major bones. We backtrack, adding one or more causes until we reach a root cause; a defect has reappeared because a fix was made to an earlier version, because we forgot to tell everyone that the bug fix was in, because we did not realize that other people might change this code module . . . and so on. We add ideas under each of the headings. Although a quick look tells us this is highly likely to be a configuration management problem, the breakdown helps us see whether we need to look at an improved process, tool, or education of the team as they move from a traditional approach(only I can changethis code) to a collaborative approach(we work on this problem together).

We then “reverse” the fishbone, to go from a problem to a solution. To do this we draw the diagram in reverse, write our proposed solution in the box, and then under our fishbone headings discuss whether the proposed solution will work:

  • What actions do we require under the 4 Ms or PEMPEM or our own titles to make sure the solution works? (Note: whichever titles you use, make sure you have a place to look at time, money, and staffing, which will all constrain the solution.)
  • What advantages or positive affects will the solution have?
  • What disadvantages or negatives can we identify?

You can use different-color pens for the advantages and disadvantages, so you could match pen colors to the de Bono Six Hats R _ colors, using yellow for optimistic and black for pessimistic views [72].

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

Agile Testing Topics