Use Collaboration Phases with Your Team

The collaboration phases also provide rules for your work as a team

We can help people make better choices in their teams, if we guide them on the options they often overlook.

When we set out to do something as a team, we have already made a number of decisions. We turned up to the event that led to this team being created. We also decided that these were the right people to work with and now is the time to start the process.

Maybe we didn’t have a choice about some of these things. We might be a team in a class. Someone else might have put us into a team.

Teams produce outputs through their collaboration

The purpose of the team is also immaterial. We could be organising a party, writing a term paper for a course, or developing a software product. The details will differ, but the phases we step through as we make decisions are the same.

We now make decisions about how we do the work together. We also need to decide how we make decisions, and how frequently we meet, and other issues that impact our collaboration. These are often overlooked, or ignored as team members go with what others are deciding.

The better option is to be aware of these decisions so that they can be leveraged to improve the collaboration.

Collaborations go through phases

I group these options under questions, or phrases, as can be seen in the diagram below. Notice that the blue, yellow and orange ones outnumber the red and green ones. Six of the ten are about how the team decides who’s a member, how the team communicates with each other, and how they work on improving their work with retrospectives.

Each one of these phases is important to the outcome of the collaboration. There are many of these, but a few that illustrate the range of them are: Who’s on the team determines the capabilities, and potential for learning new skills. How often the team meets to do the work speaks to the speed of decision making, and how the team communicates determines part of the support and feedback loops in the team.

As I see it, these types of issues are just as important as learning about software engineering, and build processes. Sadly, they are not addressed as well as they might be in the classroom.

By addressing these issues we can help students improve their collaboration outcomes. By adding them clearly in your work, you’ll be spreading knowledge of these phases to others, who will use them too.

Much of the work teams do happens before the work starts. By consciously making the decisions you’ll have fewer surprises later.

The collaboration rules map to the phases of collaboration

Each phase of collaboration maps to one collaboration rule. Some of phases happen once as you start, while others happen repeatedly in each iteration of your work. Some of them would be repeated if or when you brought new people into the team.

1. Always be collaborating, instead of working on your own – Why collaborate?

At university and some employers, people are expected to mostly work on their own. This makes it harder for students to learn to collaborate with others. People need to know why they might want to collaborate.

Create opportunities for students to do something on their own, and something similar with a team. Ask them to write up, or discuss the contrast between the two options. What surprised them?

2. Aim for diversity to improve your work – Who’s on the team?

Students like to work with friends, or people they already know. This often means homogeneous teams. This makes it hard for the team to gain different perspectives on what they’re doing. This means their collaboration might not be as successful as it could be with a more diverse team.

We should make more diverse teams the norm. You can write rules for creating teams. Then either apply them yourself to create teams, or let your students follow the rules to create teams.

3. Work in the open so that the team can see your work sooner – How do we work together?

Students each graduate individually. Most of their courses are assessed based on individual assessments and work. They don’t always know how to work as part of a team, or they have bad experiences, which they will seek to mitigate.

You should seek to break these patterns and provide opportunities for them to have a good collaborative experience. The goal should be helping students to learn to share their work frequently and regularly so that other team members can see it and build on what they’ve done.

Show them how to share their work, and create exercises to illustrate why sharing early is more useful. This could be with Git, but could also be doing a report together with a Google doc too. The principle is the same. Doing everything individually, and combining it at the end is messier, than if we start to share the work early. This is true with Git and with Google docs.

4. Be humble and ask for help and feedback so that you learn more – How do we talk to each other?

Students have different opinions about their abilities. Some feel experts in some parts, and others feel unsure of their abilities. Others, know they are so-so, and look for opportunities to improve their skills.

Students also often lack empathy for their team members. This sometimes means they tend to see everything from their own perspective, and ignore other possibilities.

Guide them in making them aware of the many different situations students encounter. Ideally, this can be done in-situ in each team, or perhaps from some university statistics: how many have part-time jobs, how many commute, how many are also carers, or have kids? If they are aware that the context for each student is different, then they might have more empathy for their team members.

This is also why it is important for teams to also build social activities into their work. if they know more about each other, the it is easier for empathy to grow between them. It also becomes easier to ask for help.

5. Meet regularly with a suitable cadence for your context – How do we stay in touch?

Students all have preferences for sharing and exchanging messages. Let them choose the options for their teams. They need two versions for communication: one for longer, threaded discussions, and one for short, urgent messages. The discussion about deployment, and ‘the meeting started, where are you?’ type of messages.

The team should also work out when people are free to meet, and find those reliable meeting times, sooner rather than later. They need sessions to discuss, and plan their work, and also sessions to do the work together. Even if they don’t do all of the work together, they do need to have some for integration work.

Provide time for them to organise some of these meetings. Illustrate how this might work with longer, or shorter time boxes, and that there is a rhythm, or cadence to scrum, and xp.

6. Accept that it’s all guesswork and, start small to learn more – How much work is there?

Most work that students do for assessment is new to them. They can only guess how long a task might take to do. They can spend too long trying to estimate their potential work. This would be a waste of their time.

By all means run some estimation exercises, but also show them how to slice work into small pieces. Teach them how to prototype small parts to learn more about the work they’re doing.

7. Build deployable, small vertical slices to learn more quickly – What order do we do the work?

Students might be unsure where to start with larger assessments. This is as true for reports, as for software products. People tend to break the work into parts, and assign these to people, or small teams. Later the team members discover the issues around this approach.

Point out to them the benefits of vertical slices for their work. Whether it a report, or a software project, thin, vertical slices work well. You can start with chapter headings, then add notes for each chapter, and keep adding more detail. You can start with skeleton code to build a rudimentary app, and then add more detail slice, by slice.

Also show how slice-by-slice means faster feedback too.

8. Keep doing the next riskiest item in order to reduce risks quickly – Let’s remove the risks.

Students often prefer to leave the risky things until later. Later means ‘near the end’, when time is short, and the impact of failure is greater.

Point out to them with some exercises the benefits of doing the unknown parts early while they have time. Especially, point out that this is less stressful, than doing things later, when the deadline approaches.

9. Shorten your feedback loops, so that you learn faster – How do we pull the work together?

Assignments are learning exercises. At the end students want feedback on the whole. They don’t always appreciate that it might have interim points where they get feedback on ‘doing’ various things along the way.

Point out to them that some habits might slow down their learning. Maybe this is talking to each team, or a group discussion of topics. Things to discuss could be these: The way they work might delay the validation of assumptions. This could be that they are not sharing their work frequently, or that they don’t meet enough with team members to discuss their work, or that their vertical slices are too thick, and take longer.

10. Always be pausing to review your collaboration – Review the process.

Students tend to ‘do, do, do’. Only a few pause and reflect. They want to do the work, submit, and move onto the next thing.

Show them how pausing and reflecting, can improve their work. This is possibly the most important rule, for collaboration, and life in general.

Use this in your classroom 

Introduce the collaboration phases and the rules to your students. You can use this one-page version of the rules with your students.

Hopefully the discussion in each section is enough to point where you can introduce this in your classroom.

Do leave any feedback, or comments on LinkedIn via the link below.

---