Teach students to work in the open to improve collaboration

Working in the open should be a default position in a team

Twice a year I guide our MSc software engineering group project teams, who are building prototype applications for clients. Each team has about six team members, and they all have separate clients. The course is twelve weeks long, with a one-week series of workshops that happens the week before the course starts.

The students know each other in a general way, as they’ve all been in the same course for the previous two terms. None of them have done much team work prior to this, so longer collaboration on a project is new to them. I put them into diverse teams based on gender, language and culture, with the proviso they can specify one person they’d like to work with. When two students name each other on a form, they are on the same team. This seems to work well without too much administrative overhead.

What normally happens

During the workshop week I tell them why and provide experiential sessions to cover collaborative approaches I detail elsewhere in my writings. Some people in some teams try them when they start their work too. Most, however, continue with their preconceptions on how to do the work.

The preconceptions mean they meet once a week to discuss what should be done, and then go their separate ways to do the work. They gather the work together at the next meeting, and then meet with their client to discuss the next steps. This is slow work as I’ve mentioned previously as it means weeks might pass, before work is completed. People might not know that a student is stuck, or the quality is poor until the next meeting.

Even if people work on their own, despite all the benefits of pairing or mobbing, there are still ways for them to let others know what they’re doing. When people know what others are doing, and can offer feedback, then the collaboration goes smoother and faster.

Work in the open to speed up collaboration

As illustrated above, the team and its members can follow a range of practices to work in the open. Starting with any of them, they can improve their collaboration.

At the individual level teach students to share their scrappy version of what they’re working on, instead of waiting until it’s perfect. It is unlikely to ever be perfect, and it will be part of a team effort in any case, so the sooner they share it, the sooner the team can move on with their collaboration. This applies to code as much as it does to reports, and documentation too.

The team needs to share its collective work with each team member. Each team member should have access to all of the team’s workspaces. This means they can look up information, and see the current state of work and contribute to this work.

Students are always reluctant to write tests for their code. They prefer to write print statements instead, and to manually test the application. Eventually, they do realise that writing tests is a better use of their time. When they get to that point, then pushing untested code to the repo is painful for the others. This leads to them realising that pushing code frequently only works if they push clean code.

When they start their work, they often create a branch per feature. There could be three branches to seven branches if they each take a feature: one each, plus a main branch. There will be merge conflicts, and ages before the code in all branches is merged. A much better approach, as I’ve mentioned elsewhere, is for them to use trunk-based development.

Go share these ideas with your students

Start talking about these general ideas in with your students. Each of them can be talked about, and tried out by teams. You can also create practical lab sessions where these are explored and tried before they do them in group projects too. That’s going to be my next step.

---