Meet with a regular rhythm to synch your work together.
I regularly guide student teams in software engineering at both undergraduate and postgraduate level. The courses are similar, but their output is more intense for the postgraduates. This is the postgraduates only course at the time, so they are expected to spend 40 hours a week developing their product. The undergraduates should be spending ten hours a week on this.
The cadence for the undergraduates should be slower than for the postgraduates. Both courses run for eleven weeks, but I would expect the two to work differently. The photo below shows you the type of things that a professional team would include in their time box. I’m not expecting this level of detail, but I do expect each team to consider what their rhythm of meetings, and work should be.
The undergraduate experience
The undergraduates are doing the software engineering course alongside three other ones. The expectation is that they will work steadily, but at a slower pace given their ten hours a week norm. They meet with their staff mentor/guide once a week, and spend two hours in a practical session with me each week. Hopefully, they also see their client once a week too.
From discussions with teams I know some meet more frequently outside of class than others. Some meet one more time a week, and others twice more a week. Most do their ‘tasks’ individually, even though I encourage pairing. I’ll have to try more ideas to get the benefits of this to sink in with them.
With this series of meetings in place, the work will progress at a steady pace. The key factor is how often they ‘synch’ with each other and share knowledge between team members, and do the work. As they are not moving too fast, finding out something is not happening, might take five or six days, might be the outer edge. There is also enough other meetings in place, that it might happen sooner.
The postgraduate experience
The postgraduates are only doing this course. The expectation is that they will work daily on this product given their forty hours a week norm. They meet with me, their staff mentor/guide once a week. They tend to see their client once a week too.
From discussions with the teams I know some meet more frequently than others. They all check-in online every day they are not meeting in person. Most teams meet three days a week in person too. As they are meeting more frequently, a number of teams mob some of their work, and do more pairing too. Some tasks are still done individually.
With this many meetings in place, they work at a faster pace. They ‘synch’ their work more frequently. As they are moving faster, finding out something is not happening, might take only a day or two.
Other factors affecting cadence
The meetings mentioned are not the only factors affecting how teams meet with a regular rhythm to synch their work together. There are other factors too.
There is the frequency and manner of code integration, as I’ve discussed elsewhere. The more frequently the code is integrated, the sooner other people can use it, and point out issues. It’s hard to go faster, or to build in quality, if you’re unable to see what others are doing in the team.
There is also often one person on a team, who is the driving force. This person will revise the code, and spend more time on the work than the others. This creates surprises for the rest of the team. I try to discourage this person from doing this, and ask that they find a partner to pull into this work, so that they don’t become ‘the expert’.
Interruptions, check-ins all provide reflective waypoints for the team. This is what the weekly mentor/guide meetings provide. The students might find them an extra burden, but they are helpful pause. These are opportunities to reflect on what’s needed, and what can be ignored. They provide opportunities for each team to pause and reflect on what their goal should be.
The counter example
As a counterpoint to this I’ll offer a hack-weekend example. I also organise hack weekend events four times a year. We stopped having regular ‘update’ sessions with the teams, for a while. The ‘update’ was a chance for each team to update the others on what they’ve now done, and where they were going next. These were like the ‘guide/mentor’ sessions for students. Other teams would offer suggestions, and ask questions about their goals, and outcomes.
When we didn’t use them, the teams would go off on tangents, and achieve less. They forgot what their goal was as they dived deep. The ‘update’ sessions helped pull them out of the dive, and remind them of their purpose.
What you can do
What cadence do your students have in their software engineering teams? Are they thinking about time until a mistake is uncovered?
Ask them when they meet, and when/if they meet for ‘working sessions’, or only for coordination meetings. This will tell you a lot about their assumptions of ‘how’ they do the work. From there you can ask questions to clarify their cadence and rhythm of work so you can help them see improvement opportunities.
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.
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.
If you’d like to be notified of future posts, then please sign up for more using the adjacent form, or follow me on LinkedIn