Working in an agency, I move projects frequently, often to a team with at least one or two members I've not worked with before. I think it's fair to say that when you are new to a team people tend to treat you with some level of suspicion until they get to know you and your particular style of working, especially if you are a tester - it's a bit like a school inspector coming into the classroom, everyone worried they are going to be found out (even the teacher, in fact especially the teacher).
One thing I like to do to break the ice is launch in quite early with a question or comment to the whole team, whether that's in a stand-up meeting or some other form of communication (email/slack/etc.). Nothing aggressive or accusatory, possibly a general query about the environment or some aspect of the functionality that's (hopefully) got a straightforward answer - mainly to show that you are getting to grips with the form of the project but don't know everything. It's a good way to disarm any feelings that you are there to disrupt, antagonise or finger-point, and also allows you to gauge who are the people who are able to answer any further questions you may have.
Defect raising (as I previously touched on in Diplomatic Baggage) is also a good way a qualming any fears or reservations the team may have, by keeping the content of the factual, impersonal, and succinct; the aim of the defect should be to improve the product, not demean the developer or criticise the design. And do bear in mind that different people will have different motivation; developers will want a clean solution whereas project managers will want the most cost-effective (which may or may not be the same). A brief explanation of what impact the defect will go a long way to convincing people the defect is worthwhile and isn't just "going through the testing motions". You should be supporting the team, not becoming a hurdle to progress.
One of the best tips I was ever given was to never tell someone how they should fix something. Make a suggestion by all means, but phrase it as such - the developer knows far better than you what to do; telling them what they have to do will not only get their back up but may also send them down a cul-de-sac of investigation that just wastes project time. It's all too easy to point to one thing being the problem when the root of the problem is somewhere else, so stick to the symptoms rather than speculating on the causes.
Most importantly, be approachable. Two minutes answering a developers question (however obvious the answer may seem to you) can save hours of defect tennis, and more importantly, lets the developer see that you are, in fact, human. It also supplies some rare feedback on your defect raising skills - if there is a way for something to be misunderstood you can guarantee it will be; rather than treating that as a failure of someone else to understand, take it on board as something you can improve on in the future. It's you that's got the problem, not them.
Finally, be trustworthy. If you make a mistake, or miss something, own up to it. If someone else makes a mistake, if there is something you could have done along the way to spot it, take your share of the blame. Shared responsibility is the best way to build a great team.
One thing I like to do to break the ice is launch in quite early with a question or comment to the whole team, whether that's in a stand-up meeting or some other form of communication (email/slack/etc.). Nothing aggressive or accusatory, possibly a general query about the environment or some aspect of the functionality that's (hopefully) got a straightforward answer - mainly to show that you are getting to grips with the form of the project but don't know everything. It's a good way to disarm any feelings that you are there to disrupt, antagonise or finger-point, and also allows you to gauge who are the people who are able to answer any further questions you may have.
Defect raising (as I previously touched on in Diplomatic Baggage) is also a good way a qualming any fears or reservations the team may have, by keeping the content of the factual, impersonal, and succinct; the aim of the defect should be to improve the product, not demean the developer or criticise the design. And do bear in mind that different people will have different motivation; developers will want a clean solution whereas project managers will want the most cost-effective (which may or may not be the same). A brief explanation of what impact the defect will go a long way to convincing people the defect is worthwhile and isn't just "going through the testing motions". You should be supporting the team, not becoming a hurdle to progress.
One of the best tips I was ever given was to never tell someone how they should fix something. Make a suggestion by all means, but phrase it as such - the developer knows far better than you what to do; telling them what they have to do will not only get their back up but may also send them down a cul-de-sac of investigation that just wastes project time. It's all too easy to point to one thing being the problem when the root of the problem is somewhere else, so stick to the symptoms rather than speculating on the causes.
Most importantly, be approachable. Two minutes answering a developers question (however obvious the answer may seem to you) can save hours of defect tennis, and more importantly, lets the developer see that you are, in fact, human. It also supplies some rare feedback on your defect raising skills - if there is a way for something to be misunderstood you can guarantee it will be; rather than treating that as a failure of someone else to understand, take it on board as something you can improve on in the future. It's you that's got the problem, not them.
Finally, be trustworthy. If you make a mistake, or miss something, own up to it. If someone else makes a mistake, if there is something you could have done along the way to spot it, take your share of the blame. Shared responsibility is the best way to build a great team.
Comments
Post a Comment