Become a team player....

We've all worked as part of a team as a tester before, whether that be in an Agile team where you work directly with developers or in a QA team in a more waterfall environment, but have we ever looked at how we can improve our relationships within the team? I'm not necessarily talking about nights out, although that undoubtedly helps, I'm talking about team relationships and enhancing them as you see fit.

It's been a long time since I worked in a Waterfall environment, however, I think the same principles apply to waterfall as they do for agile when it comes to team relationships.

When working in a team, the following are key principles that I think you should follow:

• Team first - Put the team first before any personal gain, if you are up for a promotion for instance, then don't just think about yourself, don't put your personal objectives above that of the team, this will be noticeable.
• Communicate freely with the team - Often I've been in teams where they've been deemed a bit loud, that to me isn't a bad thing, a team that plays well and laughs together undoubtedly works well together.
• Be honest with your team members - If you're having trouble doing some work, be honest and open about why, don't try and shy away from it, tackle the problem head on, and you never know people in the team might be able to help you overcome that team.
• Talk about personal life - Talking about your personal life builds the trust within the team, and with trust comes respect, which will undoubtedly help the team work together.
• Don't blame individuals - It's not any individuals fault as to why a product was released with a bug in it, people will ask the QA what was tested, and if it wasn't tested, then questions will be asked as to why, which is definitely a team question, was it a lack of communication? or was it a last minute change? It doesn't matter for the blame game, but it does matter so that you can learn from it and avoid it next time.

I read a blog recently here where she discusses the value in retrospectives, these are often invaluable in building team relationships, what is said in a retrospective should stay in a retrospective, and it's a platform for honest and constructive criticism as well as patting people on the back and saying they did a good job. Retrospectives aren't completely about actions, so long as people are honest with each other and relationships are developed, then that in my opinion is another positive for retrospectives.

So whilst that last point was agile specific, there's no reason why you can't have similar meetings in waterfall after a release, discuss (either with just QA or developers as well) what went badly, what went well etc. 

I think if an individual... no sorry, team, were to follow the above, then they would certainly all feel a part of something bigger than themselves, and it wouldhelp make work more fun, and help them work better together.