The abstracts are (mostly) all in. Not long now…
On Saturday 18th April, the MEWT 3 invitees will disrupt the convene at the tranquil, and picturesque Attenborough Nature Centre, Nottingham to discuss Software Testing and Communication Skills.
Paul Watzlawick is quoted as saying “You cannot NOT communicate” so at MEWT 3 we want to explore the different ways we communicate our ideas and views with others, especially in those crucial situations such as:
- Going against the prevailing consensus
- Broaching difficult or sensitive subjects
- Attempting to change entrenched views
- Dealing with so called “difficult people”
- Communicating in culturally diverse team
Attendees and their chosen specialist subjects are listed below:
Speaker |
Title |
Abstract |
| Adam Knight | Testing, Support and Documentation – Lessons learned from a combined role | For years I’ve been performing a mixed role, managing not only Testing but also Technical Support and Documentation for a data product company. These three disciplines – whilst distinct, for me have one strong connection and that is a focus the customer. This might be through communicating with customers directly, or by representing the customer interests within the development process. In this experience report I’ll examine and compare the different means of communicating information, both to and from the customer, that exist across these connected teams. I’ll look at the differences in information sources, media and interfaces involved between each role and the customer, and how these differences present distinct challenges for each role. From looking at examples from my experience I hope to explore the following key points:- – What principles of good communication apply when working in technical documentation and technical support – What anti-patterns in communication I have experienced when working in these other disciplines – If there are any lessons that we might take from these to apply in our testing work – The different information that is readily available to each discipline that we might look to share between teams for mutual benefit |
| Anna Baik | Credibilty | Whatever communication we receive, the source always affects how we evaluate it. As testers, our credibility affects how people receive the information we provide. If we aren’t credible, then nobody will listen to us. It also affects how we evaluate the information we get. Let’s not kid ourselves, we are not infallible beings just because we are aware of the possibility of bias. That doesn’t make us unbiased, and we’re stupid if we think we are “above all that”. We make judgements, and some of them are wrong, and a lot of those judgements we’re entirely unaware of even making. I think this raises the following points for discussion: How do you work effectively as a provider of information in an environment where *what you are* immediately puts you into negative figures in terms of “credibility points”? How do you get the information heard? How do you work around problems even getting access to information you need – “you don’t need to know that”? How do you not go crazy? And whatever your frustrations at being misjudged by people who don’t understand what you do or how you do it – aren’t you doing the same every day? Can you even build credibility with people who have such strong preconceptions about your capabilities that they can’t even let themselves see any evidence to the contrary? |
| Bill Matthews | Dealing with conflict | I will recount an exeprience from early in my professional career when communication turned to conflict (nearly resulted in fistfights in the carpark) and how some simple ideas and language patterns defused tensions and brought the team back together with a renewed understanding and purpose. Since that then I’ve encountered and used the same patterns in similar and related situations (e.g. challenging the status quo, dealing with the so-called awkward team member etc) to good effect and wanted to share these with you all. These are: – The power of acknowledgement – Redirecting unproductive thinking towards the real “problem” – Refining what the “problem” is |
| Christopher Chant | Lessons learned from customer services | The experiences and techniques developed during my career in sales and customer service and how they can be applied to software development. Most jobs require a great deal of communication and collaboration and software development is no different. It’s common in Sales and customer service jobs for employees to receive training in effectively communicating to satisfy both the customer’s and company’s needs but isn’t the case in software development. The increase in the number of distributed development teams makes developing these skills even more important. I’d like to share some of the lessons learned from a career which started by trying to provide excellent customer service in challenging circumstances and has equipped me with the skills to prosper in collocated and distributed teams. |
| Daniel Billing | Testing Influence and the Geek | One of the key issues I have as a tester is communicating my ideas, thoughts and needs, and therefore influencing the people around me. Those things I need other people to understand, so that they can be taken forward and used in other peoples testing. Part of the problem here is that I am a geek. I identify as a geek, as I suppose that is the label that best fits me culturally, beyond my race or gender. I feel that being a geek is a culture in itself, which anyone can be a part of. Being a geek, more often than not, can often impair your ability to communicate and influence others, within families, social circles and definitely in the workplace. The term invites stereotyping, which I want to avoid and break out of in the discussion. Geeks are generally seen as obsessively knowledgeable about a single subject or small range of topics, and it is normally in the technology or popular culture space. Geek personal behaviours and communications can be interpreted sometimes as being either unprofessional, inconsequential or irrelevant. Sometimes these behaviours are labelled as being on a spectrum of some special learning and educational needs. Influence is a by product of good communication. If you aren’t communicating well, then your influence stemming from that communication will almost certainly be limited. The main points of this talk will be to elicit discussion around: ● Supporting teams and individuals to develop communication confidence and the ability to influence others ● Developing methods to filter the personal white noise out of professional communication ● Developing presentation and visual aids which allow the personality of the presenter to shine through, rather than dry content |
| Dorothy Graham | Criticism and Communication | What do testers do? They are critics, often of other people’s work. The way in which criticism is communicated is key to good and effective testing. In this talk, we will look at what criticism is, and its different types. How do we respond to being criticised? This is important to know how to be a good critic. There are different types of communication. We will look at the difference between push and pull style, and I will outline Virginia Satir’s communication interaction model with an example. criticism is what tester’s do; it is important to understand how it feels to be criticised and how to criticise well the way in which we communicate is crucial to effective interpersonal interactions; we will look at two models of communication criticism and communication are critical skills for testers |
| Duncan Nisbet | Failing to communicate a model on communication | I gave a talk at a conference about the Satir Interaction Model. Unfortunately, the examples I used in the talk offended one of the guys I work with so much that we no longer talk. (he’s now moved onto another team) In this experience report I will outline the examples I gave & why I think my colleague took so much offence. I’d be interested in hearing your thoughts. The talk was meant to demonstrate how hard effective communication can be. I guess that point has been proven, though not quite the way I expected… |
| Neil Studd | Testing in the Dark: Lessons in cross-site communication | The nuances of body language and intonation are a critical part of effective communication, so how do you adjust when these are stripped away? With offshoring and multi-site development projects on the increase, testers are often asked to receive and deliver information over email and IM. Failing to dodge the pitfalls of misinterpreted communication can quickly lead to confusion, teams working at cross purposes, and potentially project failure. In this report, Neil will share his experiences from a decade of working with remote teams, including: • Real-world scenarios where the medium was responsible for obscuring the message, and how these were remedied • How to break down communication barriers between sites, without appearing to be a disruptive influence • Looking at Albert Mehrabian’s often-misinterpreted “7%-38%-55% rule” and how it can be applied to communicating remotely |
| Raji Bhamidipati | Effective communication in remote teams | In the last few years we are seeing a lot of change in working patterns within the IT industry. One such change is the change in working patterns. Geographical limitations no longer stop people from working at awesome places of work. Gone are the days of long commute to work! Remote working is taking the industry by a storm with some very positive and encouraging results. Whatever maybe the reason for the commute, new remote working practices are here to solve many problems. Although some big well-known companies have put an end their remote working opportunities, there are many more companies that are embracing this practice with a zeal. In this session I would like to start by talking about Remote Working in general and in the latter part talk about this from a tester’s point of view. I have been a remote worker for more than a year and will draw heavily from my experiences to furnish the session. By the end of the session I hope to cover: Remote working – what it means Pros and cons of remote working Impact on testing within a team when some or all of its members are remote workers Tips and suggestions on making remote working easy |
| Ranjit Shringarpure | My experiments with communications | In this talk I discuss the outcome of an experiment I deliberately set or to study the impact of the different ways n which I communicated with the different teams on the current project; and how it impacted me, my team, them or anyone around us. In particular my focus was limited to the ‘Daft’ idea of Information richness theory combined with Berne’s theory of Transaction Analysis. |
| Richard Bradshaw | The Negative One | My brief experience report will be on a discussion I had with a current colleague, where I attacked an idea of theirs having just heard it. In return, they labelled me Negative, not the first time this has happened. I will share my reflection on this discussion and subsequent learning, to ensure that I don’t take the same approach again. How it’s important to pay attention to far more than the idea its self, such as the person, the problem there idea is trying to solve and what is the problem with just letting it go? |
| Simon Knight | Applying the Golden Rules of Improvisation in a Testing Context |
What are the golden rules of improvisation? How might they be useful when working with project teams? Explore and experience them for yourself in this short talk. |
Also attending but not speaking – Stephen Blower, Neil McCarthy, Christian Legget.
About MEWT
MEWT is an invite only peer conference, organised and facilitated by:
Proudly sponsored by Equal Experts.
MEWT 3 is sponsored by Equal Experts
Recent Comments