Encouraging Teams to Work Together

Many of the teams I work with sometimes struggle to understand why working together as a team is important. There have been comments like "You're not technical enough to be involved this early" etc. from a dev to a QA, and I strive to get everyone involved as early as possible, reasons being:

• Helps people understand things from the start - if a decision is made early on, then at least they know why it was made
• Everyone is on the same footing, you're not just throwing something over the fence when it's been developed or even when it's been groomed to the QAs to understand how to test something. By having them involved early they can start thinking just how they are going to test something.
• It helps people bring value from the start- especially from a testing background, if a tester can start testing things early, even requirements, then value is coming straight away, and it's far easier to change a requirement than it is to fix a bug in code

I'm sure you've all seen the above diagram (cost of fixing a bug/time found) in some form or another, so I won't bore you too much, but lets test as early as we can! (I have to admit that I was bored last night (the wife was out) and decided to draw some drawings for the blog on my Surface! So I hope you enjoy the drawings! (this is the first of many!))

I want to talk about working together as a team and how to encourage teams to do so.

I'm sure most of you understand what I am talking about, but in case you don't, for me it is not just a set of activities, it's a mindset, it's everyone doing all they can together to get things done, performing reviews across the team It's about getting everyone involved from an early stage to gain insight into what is going to be developed. It's about pairing and getting to work with different people with different skill-sets.

The above diagram (T Shaped Skills) shows in a rather abstract way what a cross functional team looks like, you'll have people with different skill-sets who may be better suited for different tasks, but if they work alone we'll never get the other people up-skilled in other areas and we become dependent on people for their skills. By disseminating knowledge we'll hopefully as a result end up up-skilling people and we can start to have a highly effective cross functional team.

"Why should we bother working together as a team? I can get this stuff done by myself easily!"

Well, there are a number of reasons for it, ignoring the fact that if you were to get hit by a bus then the team would be screwed! One of the more important ones being that by collaborating and communicating early on it ensures that everyone on the team has a shared understanding of what is being tested or what needs to be developed.

By involving everyone up front and as early as possible we are ensuring that everyone has the same understanding, it means that testers aren't playing catch up with developers who perhaps in some circumstances may have been involved at an earlier date, and so the divide starts to disappear, and we start to discourage the Dev & Test cycles.

By having relevant reviews as well we can ensure that test coverage is shaped smartly, it means that Developers have an idea of what Acceptance Tests have been written, and as I have spoken about before, we can look at covering Acceptance Tests with Integration Tests for instance (if possible), and it may be that we have Acceptance Tests that the developer hadn't necessarily thought about. So again having a continuous and early feedback loop is integral.

How can we get teams to do this?

There are a number of ways, one of which is pairing, and I'm not necessarily talking about just paired programming, but testers can pair too! Testers can pair with a dev to do some coding, Devs can pair with a Tester to do some testing, it's all about sharing the knowledge, and giving people insight into what everyone does, so people (hopefully) begin to appreciate their team mates more and also improve in their skillsets.

Also, when I talk about reviewing Tests or Code, I'm not a big fan of emails, all too often I see emails going round saying "These are my Tests can you please review them"... or something along them lines, if we are going to have reviews, they need to be Face to Face in order to get the full benefit of them. It's all too easy to skim read tests in an email and say "yep, they're fine" but by doing it Face to Face, we can start talking about how we're going to test them, you can much easier ask questions rather than in an email. Also one thing I have unfortunately noticed is that sarcasm does not travel well over email!  So to summarise, Face to Face beats E-Mail for this type of thing, but then everyone knows that! (Right?)

Whilst face to face is great, if that's not available (ie. people are offsite) then Google Hangouts, or Skype calls are a great alternative, whilst they are not as great as face to face, they're much easier than email! I was reading the other day that most communication is non verbal, ie. it's in facial expressions, body language! Oh and lets not forget Slack! for team communication! Again whilst it's still a form of written communcation, it's better than email as replies can be instantaneous and anyone from the team can respond.

Another way is involving everyone in the team in refining, now to many companies this is common practice, but I still think it's valuable to point out here. By involving everyone you get feedback from everyone, and everyone in an agile team has valuable and equally valid points and should be listened to. How can we listen? By creating an open forum for them in such a session as refinement or even just by having huddles after stand-ups when teams begin to tackle a story. How can you get people to refinements? Cakes/sweets often help!

Another thing I've seen employed in some teams is a notion of "Mob" testing There are various forms of mob testing, but it's not really what is shown here (this is just what comes to my mind when talking about Mob Testing):

One form (and whilst it's not strictly "Mob Testing", it is a mob of people testing...) of it might be where everyone picks a specific configuration and they test something as a team. I feel sorry in this instance for whoever had the configuration for IE8 back in the day, but as people say "It's a tough job, but someones gotta do it!".... But this really promoted collaboration & communication, it also was a good example of "Team Testing" everyone mucking in, getting their hands dirty and just getting s*** done! There's also Mob Testing in teams doing Exploratory Testing and everyone saying what should be done next etc. this leads to a truly imaginative experience, and one that would be fun and interesting for most people in the team.(For more information on Mob Testing view there's an excellent blog post here by Maaret Pyhäjärvi)

Finally and one that is perhaps often overlooked, is just to be friendly and open with the rest of the team. Ask them personal questions (not too personal) but things like "Did you see that program last night?" or just have some banter with them. Often if people get to know you on a personal level, then they're more willing to work with you. Also, I was just talking to someone now and they were talking about the above, and then they said... and I quote "and then slip in the test question!" So it's a way of just talking to them but why not throw in some work stuff!? And remember a team that lunches together, works well together is something that I've found in the past!

So, this is all great, but unless we have a way of implementing things like this in the team, then what's the use of it? It's just a blog post with ramblings on... One thing that I think might be a good exercise (one that I haven't tried out yet) is a Card Collection which would involve every Engineer (dev/tester) in a team to have some Cards of themselves, the goal would be at the end of the sprint to collect all the members in your teams card, it'd be down to the card holders themselves to give people cards, but typically it would be as a result of pairing with someone, or reviewing some code etc. It promotes that cross team collaboration, and gets people talking and working with people they might not necessarily work with on an every day basis.

Hopefully once they start doing the pairing, the reviewing together, lunching together, the mob testing and just generally communicating and working together as a team, the results will be enough for them to see that this is how things should be! If it doesn't work then mention it in the retro, again as part of a team! If teams are enjoying working together and work is fun, then the team becomes an amazing team to work in. I've been in a few and it's such an amazing feeling!

There are many ways that we can encourage teams to work together, and one method might not work, but hopefully there have been a few ideas that you have read here that you think might work in your company or that you'd like to experiment with. If you do, let me know how they go. Or if you have any other ideas about how to get teams to work closer together, then I'm all ears, it's one of the biggest challenges that we face.  It's all about ensuring that people communicate and collaborate together in order to confirm their understanding of what is being developed.