The app they’re building together is less important than learning how to work collaboratively in a team.
My students on the year-long software engineering course always started thinking their goal is to build as much of the app as possible in the time available. They assume this is how we mark the team’s work: the team that does the most wins. It takes me a while to show them this assumption is wrong.
This is the first course where the skills which got them to this point in their degree are less important than learning new ones on how to collaborate in a team. Collaboration skills are what are important in the team mark this time. These skills are all of the ones mentioned in the collaboration rules. I’ll leave it to you to read/re-read them and focus on why it’s about the journey.
The collective collaboration journey is the thing
Students know that the app they are building as a team is important, and interesting. Hopefully, you can also arrange the teams to have real clients too. Real clients add an extra dimension of learning for the team. Students tend to think the key part of their learning in software engineering is the technical side. They think it is about design patterns, technical skills in different languages, and in working with the clouds. These are important.
These are not the only key issues they need to learn on the course. They need to learn collaboration skills too; specially if they want to work in industry.
The hard part of software development is not the coding or technical issues. The hard part of software development is coordinating the activities of people to produce one working piece of software. In industry this might mean coordinating the work of hundreds of teams. Our students only even need to coordinate their own six or seven team members.
Coordinating the collaboration of the team members is harder than it sounds. Any way you look at this it also involves soft, squishy things: student emotions. This is often new territory for computing science students. They all have them, they don’t all like acknowledging them. This is the key to the journey they all need to make.
As mentioned elsewhere, the skills that helped students get to where they are now, will not help them with collaboration. They need to learn the collaboration rules skills in this space. Now they need to talk to each other, they need to spend time doing the work together. They also, importantly, need to pause regularly and reflect on how they’re doing the work, so that they can identify ways to improve how they do the work.
The team needs to come together in order to succeed
Students slowly realise that they can’t do this with a lone ‘hero’ pulling things together. That leads to burnout. They also realise that they might have a team member, who raises other issues. For example, this person doesn’t turn up for meetings, and is uncommunicative. You might need to intervene and offer suggestions about how to reach the student, or find out yourself. I know from my experience, this is often students who (a) are having a lot of other issues, and are already known to the department, (b) are slow to realise that they DO need to take part in order to pass the course, or (c) other issues are building up, and they just need a bit of time to sort things out.
After the realisation kicks in students tend to change their work processes: they meet more frequently in person, they do more pairing/mobbing, they reduce the number of branches in their code, and integrate everything more frequently. They also start to have more fun as they seeing their efforts paying off more smoothly as the different collaboration skills come together in the team.
Teach your students to collaborate in your classroom
You can apply this in your classroom in a few different ways. I find that I’m often asking questions when talking to individual teams. I use a coaching approach: ask open ended questions such as ‘how often do you merge your code?’, or ‘what happens if people don’t turn up for meetings?’ That soft of thing.
This usually means the teams are thinking through the issues on their own. I’m not telling them to do something, I’m making them aware of aspects they hadn’t considered.
I do also, naturally cover these topics in the lectures, but they don’t always think of how those apply to their own work. They don’t want to be the one asking personal things. Eventually they do find out about each other and their work schedules, and family issues with mature students who have child care issues that impose on the team.
Tell students everything is about the team. Yes, it is private that a student might have childcare or work. Yes, it is also true that it impacts the team. This is the part that is slow to sink in, and be acknowledged as part of the squishy, emotional side of software development. Use your experience to point out that teams might need to bring these issues into the open in the team to improve their collaboration.
Tell them to explain their team’s journey in the report and evidence what they learned along the way: tell us why they made the decisions they did given the various options available. By doing this they will explain their journey and why the completed what they did in the application.
This post is part of a project pulling together my materials and ideas about Teaching Team Collaboration: the Human-Side of Software Development for software development to students.
If you’d like to be notified of future posts, then please sign up for more using the adjacent form. When you sign up, then I’ll send you a free copy of the collaboration rules as a PDF from the book. You can also follow me on LinkedIn
The ideas above are from my book 101+ Ideas to Improve Team Collaboration, which covers all of these little things that students can do to improve their collaboration.