Testing skills #3 - Leading Teams

If you are leading a software development team it is a good idea to provide to provide an environment in which each member of the team feels safe, valued and important.  It takes a lot of skill to lead teams without resorting to command and control style of managing the team.  Providing the team a safe environment in which it is OK to experiment a little and be able to learn from failing is crucial to encourage creativity and innovation within the team.   When leading a team in this way you can act as the facilitator and ensure that the bad elements of teamwork do not start to impact the team dynamics.  You can be the sounding board, the oracle, the voice of reason, the mentor, the confidant, by doing this you encourage the team to flourish which leads to success.

As a leader you also need to give the team a clear direction of what you expect the team to deliver, this can change as time passes however, this should always be transparent and visible to the team.  Ask yourself as the leader what do you want from the team?  What is your ultimate goal and then explain that to the team along with your preferred priorities.  Then step back and watch the team self-form around the problem to provide you with a solution.

The principles behind the the agile manifesto has some useful tips for leading and working in teams.

"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."

"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

J Richard Hackman provides the following five tips for leading teams.

1. Teams must be real. People have to know who is on the team and who is not. It’s the leader’s job to make that clear.
2. Teams need a compelling direction. Members need to know, and agree on, what they’re supposed to be doing together. Unless a leader articulates a clear direction, there is a real risk that different members will pursue different agendas.
3. Teams need enabling structures. Teams that have poorly designed tasks, the wrong number or mix of members, or fuzzy and unenforced norms of conduct invariably get into trouble.
4. Teams need a supportive organization. The organizational context—including the reward system, the human resource system, and the information system—must facilitate teamwork.
5. Teams need expert coaching. Most executive coaches focus on individual performance, which does not significantly improve teamwork. Teams need coaching as a group in team processes—especially at the beginning, midpoint, and end of a team project.

Leading Teams: Setting the Stage for Great Performances - J. Richard Hackman - 2002

Testing skills #2 - Influencing by listening

Having recently attended an excellent internal workshop on the' artistry of influence'.  One of the key takeaways I got from the course was to be able to influence you need to STOP and LISTEN to what the person is saying and most importantly how they are saying it.

During the course I discovered that when communicating we have a preference for using one of three types of senses, sound, sight and touch.  Which when converted into communication terms become auditory (sound), kinesthetics (touch) and visual (sight).

Do they use visual words such as 'see, bright, focus', kinesthetic 'feel, handle, hard' or Auditory 'hear, ring a bell, sound right'.

Once you uncover their prefer sense for communicating you can try and match their preferred sense.  This is called pacing and its roots can be found in our tendency to form tribes and groups based around similar traits.  This enabled us to survive as a group, since we shared similar habits and vocabulary.  It also encouraged strong relationships within the groups.

It is also useful to established the tonality of the person you are listening to.  Are they talking quickly, loudly, slowly or quietly? Ask a friend to help you practice by matching the voice tonality and their preferred sense.  By listening to others and the way they talk you can start to establish a rapport and build a relationship in which they can be influenced on a subconscious level.

Be careful when influencing others that it does not become more than just trying to persuade others of your thoughts and ideas.  If people feel or find out they are being manipulated then you will loose their respect and destroy any possibility of a working relationship.  The key aspect when trying to influence people is to ensure that they know it will have a positive benefit for them, even if at the same time you will gain a positive benefit.  The person you are trying to influence has to see a benefit in it for them.

It is not about YOU it is about THEM,

There is a lot more involved in using listening as an influencing tool and this is only an introduction.

Let me know how you get on with this tip on influencing by listening.

Further reading:

• Real world applications of pacing and leading
• How to persuade anyone using pacing and leading
• What is NLP
• Influencing skills: a how-to guide, or, How to get what you want without making enemies

It meets the business requirements

Recently I came across an interesting software requirements issue whilst eating out at a UK restaurant chain.

They had one of those common deals you can come across in similar chains.  You choose a main meal from a limited, but tasty, menu.  You get unlimited drinks of either tea/coffee or fizzy drinks. (soda) and you can have unlimited access to the salad bar .  To end your meal you get an ice cream sundae.  All of this for the sum of £9.99!

I was with my wife and we both ordered a main meal and a drink.  Whilst our meal was being prepared we went and selected our bowl of salad from the salad bar.  We set about eating our salad, during this time the drinks arrived followed by our main meal.  We only just managed to finish our main meal and was feeling rather full by now.  So when the waitress came over and asked if there was anything else we both said no can we skip the ice cream sundae and just get the bill.

The table was cleared away and the bill arrived......

Can you guess how much the bill came to?

If you are thinking the same as my wife and I you would think the bill would be £19.98.   The actual bill came to £20.13.  I queried this with the waitress and she replied....

"Oh, that is because you did not have the ice cream sundae!"

Our reply was "WHAT", We have less but it will cost us more?

The waitress was very confused and went to see her line manager. Who came over and explained that what they will need to do is order us the ice cream sundaes and then go and let the kitchens know that there is no need to make it.  They did say we could take it with us!  Ice cream, in car for hours & warm day  not a good combination.

All of the orders were taken on a mobile phone app which fed back to the main system and the kitchens.  There appears to be no option to be able to mark an order as one of the deals. Each item is entered individually.  Once you have the four items it now knows which are part of the deal and works out the price.  Now the question to those reading this..... "Is this a defect?"

From the business requirements perspective this is, I guess, what they wanted from the software.

Since entering each item one at a time and then working out if it is part of the deal allows them to manage stock control and keep business costs under control.  It has one less step for the operator to carry out rather than if they had to press a button to indicate it was a deal,

From the end user experience perspective it is flawed.  It appears they did not expect customers to decline something that was in reality free. From the staff working there they had to override the system and implement manual processes to enable the correct price to be calculated. At the same time this will upset the stock control reporting that they have two less ice cream sundaes than they actually do.

When we look at software requirements and we start testing these requirements, it is important we look at the implementation from all perspectives.  This is especially true for systems that businesses use to help facilitate customer service.  Get this wrong and it can leave a bad impression on the business customers.

Testing skills - Abductive Reasoning

This is the first in a series of hopefully short articles which looks at  skills and techniques outside the traditional testing that can be useful to those who practice testing.

Future topics planned include:

• Influencing by listening
• Note Taking
• Leading teams
• Persuasion and how to sell
• Speaking the language of business 
• Remote teaching experiential style
• Going beyond the model

If you can think of any others that would be useful please leave a comment. 

I am making these public,  since by writing it down and making it public I am committing myself to do it.  That is your first tip in this article, if you want to commit to doing something which you keep putting off, writing it down and make it public.

Abductive Reasoning.

 Abduction came about from the work of Jo Reichert, in this work Reichertz came up with another cognitive logic process to describe discovery when the researcher encountered surprising findings in the data. He called this "a cognitive logic of discovery".  Before this there were two types of reasoning in common use, 'inductive' and 'deductive'.

• Inductive - Making generalized conclusions from specific observations
• Deductive - Proving or disproving a theory from observations (scientific method)

Abductive reasoning is an important process for those involved in testing.  The majority of time when we are testing we discover surprising behavior in the software.  This normally makes us rethink our theories of how the software works and as such we begin to re-evaluate our understanding of the software.  We create a new rule, or test idea to further investigate the surprising element of what we have just tested. This is key within grounded theory; our thoughts about the software and how it behaves change as we explore the software more.  How we report these surprises and the behavior of the software is crucial to the value that testers provide to a project.

"There are two strategies involved in abduction, both of which require creating the conditions in order for abductive reasoning to take place"* (Reichertz, 2007: 221). 

The first is a ‘self-induced emergency  situation’ (Reichertz, 2007: 221). This means that in the face of not knowing what to make of a surprising finding, rather than dwelling on the infinite number of  possibilities, the analyst puts pressure on themselves to act by committing to a single meaning.

The second strategy is completely antithetical to the first. It involves letting your mind wander without any specific goal in mind, or what Pierce (1931–1935), a key writer on abduction, called ‘musement’* (Reichertz, 2007: 221). "

Qualitative Research Methods in Psychology: From core to combined approaches - Nollaig Frost - 2011.

Reichertz makes the following observation about these two strategies.

"What these two quite antithetical strategies have in common is tricking the thinking patterns of the conscious mind in order to create ‘an attitude of preparedness to abandon old convictions and to seek new ones."
 The SAGE Handbook of Grounded Theory:(Sage Handbooks) - Antony Bryant, Kathy Charmaz  - 2010.

Testers need to be able to abandon their old convictions and seek out new ones.  This is especially important when we are testing software, since our biases and beliefs and previous experiences can influence our decision making. Using some of the methods described in this book can allow us to challenge our thinking about the software and engage in abductive reasoning.

One famous use of abductive reasoning is that used by the fictional detective Sherlock Holmes by Sir Arthur Conan Doyle.  Many people believe, wrongly, that Sherlock Holmes uses deductive reasoning to solve his cases, when in reality he used abductive reasoning.

"Holmes' method doesn't resemble deductive reasoning at all. Instead, it's much more similar to a form of reasoning known as "Abductive Reasoning"Debunking Sherlock Holmes Myths - Maiza Strange  May 2014

To summarise abductive reasoning is taking your best guess based upon your current knowledge, observations and experiments.  These pieces of information maybe incomplete but you use your cognitive reasoning processes to form a theory or conclusion.  For example:

"A medical diagnosis is an application of abductive reasoning: given this set of symptoms, what is the diagnosis that would best explain most of them? Likewise, when jurors hear evidence in a criminal case, they must consider whether the prosecution or the defense has the best explanation to cover all the points of evidence. While there may be no certainty about their verdict, since there may exist additional evidence that was not admitted in the case, they make their best guess based on what they know."Deductive, Inductive and Abductive Reasoning - Butte College.

Further reading on abductive reasoning:

• Abduction, Deduction and Induction in Qualitative Research - Jo Reichertz
• Abductive Thinking and Sensemaking: The Drivers of Design Synthesis - Jon Kolko
• Abductive Reasoning - Wikipedia - 2015

This article has been taken from the Testing and the Social Science chapter in my book - The psychology of Software #Testing.