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:
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:
The advantages de Bono identifies are
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
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:
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 .
Agile Testing Related Interview Questions
|ETL Testing Interview Questions||Manual Testing Interview Questions|
|Selenium Interview Questions||Database Testing Interview Questions|
|Automation Testing Interview Questions||Software testing Interview Questions|
|Performance Testing Interview Questions||Embedded Testing Interview Questions|
|A/B Testing Interview Questions||Hadoop Testing Interview Questions|
Agile Testing Tutorial
Old-school Development And Testing
Agile Development And Testing
From Waterfall To Evolutionary Development And Test
How To Test A System That Is Never Finished
Implementing An Agile Testing Approach
Agile Testing In A Remote Or Virtual Desktop Environment
Testing A Derivatives Trading System In An Uncooperative Environment
A Mixed Approach To System Development And Testing: Parallel Agile And Waterfall Approach Streams Within A Single Project
Agile Migration And Testing Of A Large-scale Financial System
Agile Testing With Mock Objects: A Cast-based Approach
Agile Testing – Learning From Your Own Mistakes
Agile: The Emperor’s New Test Plan?
The Power Of Continuous Integration Builds And Agile Deve- Lopment
The Payoffs And Perils Of Offshored Agile Projects
The Basic Rules Of Quality And Management Still Apply To Agile
Test-infecting A Development Team
Agile Success Through Test Automation: An Extreme Approach
Talking, Saying, And Listening: Communication In Agile Teams
Very-small-scale Agile Development And Testing Of A Wiki
Agile Special Tactics: Soa Projects
The Agile Test-driven Methodology Experiment
When Is A Scrum Not A Scrum?
Analysis Of The Case Studies
My Agile Process
The Roll-out And Adoption Of My Agile Process
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.