Working with teams I sometimes feel that teamwork is similar to the weather: everybody talks about it but not much is done. When I talk about teamwork I mean doing the work together, as a team. Advising with each other is good, planning together is necessary, going to lunch as a group is fun and like the other activities, is probably a good way to get nearer to team work. However , as said above, I’m talking about doing the work together. And here are 3 steps that will help you get nearer to that worthy cause.

First step: no personal assignments. Most electronic boards (e.g. Jira, TFS, Gitlab etc.) have an “assigned” field on stories. Don’t use it. As simply as that. Let it be empty. During planning meetings don’t talk about who’s going to do a story, leave it to later. When is later? Later is when we need to start working on the story, when it is next in priority. And then also don’t assign a person. Talk about who will start working on it today. Who in plural, I mean. Then tomorrow, in your daily meeting or during the day, agree who should work on it then. This is a team thing. There is no specific one developer responsible for the story, it is the team.

Some people will say: but how will we know who is working on what? The answer is simple: if you are working on many stories in parallel it might indeed be difficult to know that. So work on less stories in parallel and then everyone knows who’s working on what.

Second step: Weekly mob programming sessions. Mob programming is the activity where the entire team is developing together. Set a meeting room with a big screen, one computer and one keyboard. The keyboard moves every 5 minutes from one person to the next. The team decides what the driver (the person on the keyboard) does. Now work on your ongoing tasks. People who hear about this for the first time find it hard to understand this but you need to try it out. It works like magic. This is an activity that brings the team together. Spend every week 1.5-2 hours on this, going on some of the ongoing tasks and good things will start to happen. Llewellyn Falco wrote a book about this.

Third step: Pairing. Pairing is when two developers develop on the same workstation. Remember that most of what you do during development is thinking, not writing, so one keyboard is not a problem. In workshops, I’ve led people who always say it’s more fun to work together and they think of more creative solutions. Alistair Cockburn and Laurie Williams show pairing is 15% more effort (e.g. while one person will do the job in 2 days, two will do it together in 1.15 days) but other benefits make it a thing you must do.  Arlo Belshee wrote an essay about promiscuous pairing, a must-read.

The daily meeting is a good place to think about who will pair with whom today.

To summarize, the main problem with teamwork is that it doesn’t look good on a spreadsheet: you see plainly more people on the same job and you don’t see that magic that it does. Don’t let this stop you. Start by not assigning specific people to tasks, move on to mob programming and then find opportunities to pair. You will see results quite quickly.