Introduction

Every summer since June 2010 I have been working with teams of students, who are working with clients to build them a piece of software. They take everything they’ve learned about building software applications, and apply that to this project with a team of five or six students. This has had many ups and downs, and there is always something interesting happening.

Every year I do this I realise that there is something more that I could (should?) include in the week of workshops that we do together as preparation for this work. These bring together a number of topics so that the teams start from a similar baseline.

Every year I also see that these issues are more transferable to other places where they work as teams too. While it’s very obvious how regular meetings to check-in with your team members is useful for something as complex as software, it’s also crucial to all of the other team collaboration I see my students doing in other classes.

I saw the transferable aspect of team collaboration in our regretfully short-lived CityLab project, which brought students from two universities together to ideate on possible projects to improve the city. Our only requirement was that students were in either level 3 or 4 of their studies. We didn’t care which discipline they were studying until it came time for team formation, then we aimed to only have two students from the same discipline. There we had students joining us because they wanted the group experience, and might not otherwise have that opportunity, as one maths student explained.

What follows builds on this as I try to explain the options open to all people collaborating in a team. I think I’ve kept the software related examples to a minimum, so it should be clear to all readers how these ideas can be used in their domain.

Stages of collaboration

All of these students pass through various stages on their way to finishing their team collaboration. For each of these stages I find they end up on a range of options along a continuum of options. At one end is the ‘knowing’ option, where the team has feels it needs to ‘know’ what will happen. At the other end is the ‘learn by doing’ option, where the teams edges its’ way through the work and adjusts the work as it learns.

This continuum seems to be applicable for each of the stages they discuss:
1. Why bother to collaborate?
2. Who’s on the team?
3. How do we work together?
4. How do we talk to each other?
5. How do we stay in touch?
6. How do we know how much there is to do?
7. How do we decide what order to do the work?
8. How do remove risk from our work?
9. How do we pull the work together?
10. How do we review what we did?

Sometimes, as you can imagine, they rush through a stage without realising they have options. Some of them might have done some of this before in a different class, and therefore think they ‘know’ the topic already.

Do we have to?

Yes, there are many good academic and professional reasons for you to do some team collaboration. You possibly learn more from your fellow students, than you possibly do from anything staff can teach you. We teach you the ‘big ideas’, but it’s the one-to-one work you do with fellow students as you implement the ideas that stick with you later, because they are associated with the experience you share together.

Employers also say repeatedly that they want graduates to have team work experience, as that is how most work is now done. Having some interesting team collaborations to talk about in interviews has helped students gain jobs in the past.

Usually this starts with ‘do we have to do this as a group? Can’t I do it on my own?’ discussion. After some questioning it usually emerges that someone had a bad group experience in the past when someone didn’t contribute to the work and the other person now feels all group work is bad. This leads to a talk about working agreements, where the team members decide, and agree on what their goal is, and how to work together.

It is important that all team members know what they want to gain from the experience, because this keeps them motivated in their participation. Someone might see this as a chance to gain a new skill, or to have fun with their friends, while someone else sees this as a good opportunity to learn about group collaboration, and providing interesting stories for job interviews.

Can we pick our own teams?

The next stage is normally ‘can we pick our own teams?’. Many students feel that if they work with their friends this will be ‘best’. I’m never sure if ‘best’ relates to fun, grade, or combination of those. Again, they don’t think of options for what they might learn here.

I use ‘pick your own team’ for one course, and this has mixed results. Some teams mess about too much, and don’t do as much as they could. Others are too homogeneous with little inspiration to explore options; all male, all female, all one nationality, and all of them usually end up following one person’s lead.

I pick the teams for the summer project using a set of criteria, which does not include their grade on previous courses. Instead, I use gender, when did they start the degree (January or September), and their native language (English, Chinese, Arabic, etc). This year I also tried to include some of their preferences with a survey: name one person you want to work with this summer. If two students named each other, then I tried to keep them together. That worked for all pairs, and there were enough others to balance out the teams. The diversity this generates in teams seems to serve them well, as they often produce good results.

How do we work together?

Students sometimes forget about the social side of working as a team. They only think of the work, and forget that everyone is human. A key part of team collaboration is remembering we are all fallible, and that we need to have empathy for each other. I try to help them realise this by having them do some social activities as a team, whether that be playing a game, or doing a meal together, or working through questions from a deck of So Cards so that they learn more about each other, which makes the challenges later easier to resolve. They should do something like this at the start of their journey together, and continue with more activities over the term as it will help them later when they reach bigger challenges.

This year, as we were doing more work at a distance due to Covid-19 I made more aspects of team collaboration explicit earlier, than in the past. This worked much better. In the past, students would become side-tracked (maybe it was the Lego used in the workshop), but this year they stayed focused. Each team filled in a template working agreement. They clarified what each team member wanted to learn (how to use a task board, javascript, python, etc), their vision of the team goal, (they all want A grades), how they would work (solo, in pairs and as a whole), how they would communicate (WhatsApp, MS Teams, etc), and resolve issues if someone wasn’t pulling their weight as agreed, because they were all in different situations.

How do we talk to each other about difficult topics?

Some parts of team collaboration only work if the members know how to have challenging conversations. I suspect that some people shy away from teamwork for this reason. Yes, they want to be successful, but they don’t know how to discuss problems. They worry about shouting matches. A key part of this is having students listen to each other before they start to answer. I cover this aspect with some exercises and cheat sheets based on the ‘Crucial Conversations‘ book so that students know how to introduce these topics in a successful manner, to avoid the shouting.

The STATE approach works well, once you follow the basic rules: stay focused on what you want to gain from the conversation, and pay attention for when people go quiet, or start verbally attacking others, so that you can deal with this. In order to do this you need to listen empathetically to each other.

STATE goes like this: share what you see, tell your story of what you think this means, ask the other person for their perspective, talk tentatively, encouraging testing of interpretations, all the while being open to the other person’s views.

If you don’t feel confident enough to do this, then you should always know who you can reach out to for help. I always make it clear to my students that they can speak to me if there’s an issue in their team, and that I am willing to facilitate these conversations.

With all of the groundwork in place the team can start to explore what they doing together; the object of their collaboration. They can set its boundaries, estimate how much work their is to do, and then prioritise the work with a plan of action. This is where everything can start to go wrong.

How do we stay in touch?

Doing the work as a team means that the members must ‘sync’ up so everyone can take part in the staple of office life: ‘progress’ or ‘status’ reports. Some people think that meeting once a week, or every other week is enough. Others think that a shorter time frame is better. The ‘right answer’ depends upon context, and can be determined by the answer to the question: how important is it to correct someone’s actions if they’re going in the wrong direction with their work? The more important it is to correct them, then the shorter the time span should be between meetings where you’d find these discrepancies.

When students are building software together over the summer, then they should spend some time together as the whole team everyday ‘syncing’ and doing the work before they go off to do more work in pairs before coming together again the next day.

If the work is less demanding, then a weekly session together usually suffices. During this session the team can work through topics on a task board to see what’s done, what’s stuck, and reprioritise items in the current backlog.

How do estimate the work?

Teams vary in their collaboration. It also depends upon how much background and context, or requirements gathering needs to be done for the work. When the work in tightly constrained already, then it is easier to start when the outcome is less prescribed.

Some teams try to plan everything in advance, and estimate work before they even know what is required. Other teams only plan for the next week or two, and aim to find out more in this time with small ‘research’, or ‘experiments’ so that they can plan other work based on the results.

Students are beginners, so have no experience to fall back on for estimating work. This means they have lots to review in how to do something, and what might be required. It also means they will follow up wrong solutions, which all take time.

I encourage students to keep breaking their work down to tasks that might take a day to complete. This means they see progress on tasks, which fit into either a week or two weeks of work for that stage. That means they keep slicing up ideas until they get them do ‘about a day of work’ in size. Working in small batches makes it easier to keep an overview of everything that needs to come together for this phase of work. This incremental and iterative approach works well for team collaboration.

How do we prioritise the work?

After they know what work should be done, and how long it might take, then they can start to prioritise the order of the work. For some work this is clear, other times less so. If the output is a report, then I can start doing lots simultaneously. If it’s software, then there is probably some order of development, which needs to be followed. Part of this is tied to concepts of how much work can be done in parallel.

Teams deal with the work differently too. Some think that everyone needs to have individual tasks, while others are more open to members picking the work they do, and might even do it with a partner. Usually this is tied to some notion of ‘experts’, responsible for certain domains. This is partly tied to the notion of parallel tasks: if I have four people, then four ‘things’ can be done at the same time. This is a mistake.

I encourage them to do everything in pairs so that they all have someone to ask questions about the work, and get a second opinion when doing the work. With time students discover that individual work is often lower quality. I also encourage them to do some work as a ‘mob’ or the whole team, especially if they are working out bigger issues because then everyone can contribute, and everyone knows the result too. When working in pairs, then people should work with different partners and rotate around the team to spread knowledge within the team. By working in pairs and as a mob, they spread knowledge within the team as people learn new skills, and everyone becomes a generalist. That means when someone leaves after winning the lottery, or becomes infected with a virus, that the impact will be less on the team, as they weren’t the only person who knew about that skill.

How to we manage risk?

Every team effort has risks to manage. Some teams don’t notice this, while others take the time to identify them and determine how they might be mitigated or avoided. In both cases the team usually resolves risks as they need to be done according to their plan. That means that some risks hang over the project until near the end. A better option, which I remind them of, is to resolve these risks as soon as possible. If you’re not sure how you will do something for the presentation, then do a few experiments earlier on to find out, instead of waiting until a few days before.

Even though we live in the age of cloud computing and applications like Google documents, Dropbox and other free solutions, it still surprises me that most teams have their team projects on individual laptops. That means if their computer dies, then the work dies. This risk is almost never addressed. The realisation that it needs to live on a remote device to be safe usually only sinks in after a disaster, or repeated reminders. If they addressed this risk early, then they would also resolve the other key issue of integrating the work of everyone. What other assumptions are being made, which can be fixed as easily?

How do we pull the work together?

How the team resolves the process of integrating everyone’s work ties back to many of the other issues mentioned above. If the team vision points to shared working, then this will happen more regularly at least in pairs. If the team plans and works in shorter cycles, then small parts are done on a regular basis, and can be combined sooner, which means mistakes can be found sooner. If team meetings are more frequent, then the ‘syncing’ of direction for work will be aligned regularly when people do their updates. If the team works as a mob sometimes too, then everyone can confirm that they share the same understanding of the work to be done. Each of these steps provides some feedback on what the team is doing, and how its’ members are collaborating.

The guiding principle in pulling the work together is to remove risks as soon as possible by combining work as soon as possible, in order to confirm assumptions, and remove doubt. Combining your work together provides feedback: if something doesn’t combine as expected, then this needs examination so that you can fix it, and possibly prevent it from happening in the future too. If everything combines smoothly, then you know that work is going well.

How do we review what we did?

At the end of each round of work the team has one more crucial step to take. They need to consider how they did the work, and what steps they should consider taking in order to improve how they doe the work. For example, they might realise that they didn’t sync their work as well as they could’ve and should therefore meet more often. Or, that their survey didn’t reach enough people, so that they’ll research how to find a wider audience for the next one. There is always something, which can be improved upon, and it’s important to take the time to explore this on a regular basis.

Conclusion

I’ve been fortunate to see some teams working wonderfully together, and been part of some great collaborations too. It can be magical when it all comes together nicely. It can also be frustrating and aggravating, as I also know from experience, when it doesn’t work.

I’ve noticed lately that we don’t seem to be covering team collaboration in many classes. Sometimes a few parts are mentioned in ‘project management’, but that is always treated as a ‘special case’ instead of being an everyday way of working as a team.

The goal is still the same for all of these scenarios: do something together, which we couldn’t do on our own. In all of them there is also the issue that some people feel more capable than others with the skills they bring to the team.

From my experience, it doesn’t matter what your skill level is in the domain you’re working in. What matters is how you work with your team members. You need to approach the challenge from a similar perspective to have the best chance of succeeding.

My goal in writing this is to change things. This is the start of something bigger.

This sounds useful. How do I start?

If you want to use these ideas, then that’s good. If you’re at the start of something new, fine. If you’re in a team collaboration already, then you can start at any time by asking questions in your team about any of these topics. The sooner you start, the sooner things improve.

1. Know why you’re collaborating in your team. Know what’s in it for you.
2. Create a diverse team when possible.
3. Produce a team working agreement to clarify the team vision of your collaboration, and specify how you’ll work together, and resolve conflicts.
4. Be aware of how you’ll do those difficult conversations if you need to have them. If it isn’t someone in the team, then know who you can call on for help if it’s required.
5. Do the work in small batches based on prioritised tasks.
6. Work in pairs or as a mob to share understanding across team members.
7. Meet regularly to combine your work to confirm that you’re working smoothly.
8. Remove risks as soon as possible in the work to avoid bad surprises later.
9. Review your work together regularly so that you can improve upon it.

What I plan to do now is to keep writing up on each of the topics as blog posts, and to then pull them together into something bigger. Each post should be similar to this: have something about context, the issues and tensions involved, a review of the options you can apply, and then proposals about what you should try, and end with something that you can use in practice if you’re in person, or working remotely.

What I could use from you readers are comments on this. What do you think? What would be most useful for you? Use the comments below, or get in touch some other way.

UPDATE (3 August 2020):

Thanks to some comments and feedback I’ve added a ‘Team Collaboration‘ page, which pulls these ideas together and includes a page of links to resources you can use with your teams.