The 10 Phases of Team Collaboration

When you know the phases of team collaboration, then you can leverage them to improve your collaboration.

Most computing science degrees have a large team component focusing on a term long, or year long software engineering project. Given these always have a fixed start and end date, and the students are expected to produce milestones to show people along the way, these are always projects. I still try to have them think of the work as ‘products’, which could continue after they finish, but that is another post.

This probably sounds familiar to you if you’ve been working with these student teams. The team agree on what they’re building, and then disappear to do the work. You might see them weekly in practical lab sessions, or as their guide/mentor. You ask them questions about how they’re getting on, and they might tell you technical things such as the language, or framework their using. They might ask you technical questions too about how to deploy to a remote server. They might also tell you that they had a team meeting earlier that week, and can you tell them more about what percentage the report and code count for in the final mark?

You’ll notice that they don’t normally talk about the collaboration part of the work. There are no discussions about how often they should meet to do the work together. Nor do they determine how and when someone should ask for help when they are stuck. Eventually they realise that they need to discuss these things, but sometimes this only happens after arguments and disagreements. There is a better way.

Introduce your students to the collaboration phases

You’ll notice that I say ‘phases’, and the image below has ‘stages’. I suspect phases works best because these can be visited in each time box. Stages sounds more defined too, so I think phases works better in that sense as one dissipates as another starts to build.

As you introduce these phases to software development as a team, guide them through them so they can discuss these issues up front. This enables them to talk through concepts and options before there is the stress of deadlines and disagreements. By doing this now you give them the tools to help themselves later.

You’ll notice too, that many of these topics are left out of the software engineering textbooks. This seems strange given that many developers, scrum masters, agile coaches, that I talk to tell me the hard part of software development is not the coding. The hard part is the people management side, which makes it challenging. And fun. This should be hard, and fun because of the people you work with, share meals with, and build experiences together. Students should see this too.

As you can see from this image showing the phases of collaboration, a happens before the team starts their work. They should talk about who’s on the team, how to communicate with each other, plus what they agree to do in the team. They should also agree on their shared understanding of the risks, timescales for work, and the order they need of items in the work, plus how to decide all of these things. Only then do they get to talk about how to use version control, or other means to bring their work together. So many of these topics are left until later, or ‘assumed’ by team members without discussion.

Phase one: Why bother to collaborate?

Students don’t normally get to choose this option. Staff decide what should be done solo, and what should be done in groups. If they do get to choose, then tell them to look for ways to learn from others, and how they might enhance their collaboration skills.

Phase two: Who’s on the team?

For low-stakes work it doesn’t matter who people collaborate with on a project. For bigger projects, you want to consider how you build your teams so that everyone gets the most out of the experience. When I do this, then I make them as diverse as I can, and pair people so each person has someone similar to them on the team.

Phase three: How do we work together?

This is where the work happens. How will the team develop a shared understanding of what they want to build? This is where the team decides which tools and resources they are using for their work, and deciding how to use them, as well as when and where they will meet to do collaborative work.

Phase four: How do we talk to each other?

The team need to be able to talk to each other in order to build a shared understanding of their common goal. Team members need to be able to divulge issues that affect the person’s contribution to the team, and team members need to be able to approach people, who are not contributing to find out what issues are holding back that person. This is where many student teams have a hard time, as how to approach difficult conversations is not covered in software development textbooks, or university courses.

Phase five: How do we stay in touch with each other?

Team members need to communicate with each other to share what they’re doing, as well as to let each other know of updates and issues. While many quickly start a social media group chat, they also need to consider slower methods too, such as task boards, and other tools that might help them be aware of who’s working on which issue.

Phase six: How do we know how much work there is to do?

Estimation is hard for people, who are being asked to decide things that are new to them. This makes estimating how much they might be able to achieve in the time available hard, even if everything goes smoothly, which is unlikely.

Phase seven: How do we decide what order to do the work?

This is where the planning happens for the work. If the team is using timeboxes, then they need to decide which things need to be done sooner than others, and how their work can be shown to their client too. Most clients are unimpressed by a database schema on its own, but they might like to see a web page displaying something from the database. Teach them to build in vertical slices, and they’ll always be able to show people their work.

Phase eight: How do we remove risk from our work?

Surprises can be fun, so we want to ensure that we only have good ones, and that bad ones happen earlier in the work. That means identifying and mitigating the riskiest things as early as possible, so that they don’t impact the work so late in the process that there is no recovery time. 

Phase nine: How do we pull the work together?

For most software applications this will come down to a strategy for using git and a remote team repository in GitHub or GitLab. The key consideration is to make students realise that until their code is in the remote repository no one else can see their work, and make use of it. Until someone shares their work no one can discover their mistakes, or build on what they’ve done. Most seriously, as CS students they should know their code is vulnerable as long as it’s on only one device, and that cups of coffee, beer, etc are lurking on every desk waiting to spill their contents at the ‘best/worst’ moment.

Phase ten: How do we review what we did?

This is the retrospective, where the team consider how they did the work in the timebox, and look for an improvement that they can try to make their work more effective in the next one. Students often ignore this phase, and immediately start the next timebox. You should encourage them to pause and reflect for an hour on what they’ve done, and find a way to make their collaboration more effective.

The team needs to discuss each of the options in these team collaboration phases. There is no ‘best’ option that always works for every situation, or collaboration. This means each team needs to talk about the options in order to select an option to start. As long as the team uses a retrospective, then they can always make changes later if the option isn’t as good as the team hoped it would be.

Given team collaboration phases come around each iteration, they are also circular in nature. The team has many opportunities to learn as they do their work together. They are a system, they can make changes if they find a choice was wrong, or no longer works as well as it did previously.

Make them aware of choices so they can leverage their options

If you introduce your students to these team collaboration options, then they can pause and think through what would work best for them. Introduce these options early, so that students don’t make poor choices made in the rush to get started. By helping them realise that if they go slow now, to make some initial decisions, then they will be able to go faster later, and will have mitigated, and maybe avoided some issues later.

---