Student Resources

Resources to help students achieve better outcomes in their team collaborations

A lot of the posts help academics teaching students in software engineering and similar subjects. Much of it can be used by students directly too.

The collaboration rules are:

1. Always be collaborating, instead of working on your own
2. Aim for diversity to improve your work
3. Work in the open so the team can see your work sooner
4. Be humble and ask for help and feedback
5. Meet regularly with a suitable cadence for your context
6. Accept that it’s all guesswork and start small to learn more
7. Build deployable small vertical slices to learn more quickly
8. Keep doing the next riskiest item in order to reduce risks quickly
9. Shorten your feedback loops, so that you learn faster
10. Always be pausing to review your collaboration

Use those to align your work. Further below we’ll point to links to help you in each section.

Always be collaborating, instead of working on your own

Why you should collaborate from Forbes

Aim for diversity to improve your work

Belbin roles – who does what in the team

https://www.belbin.com/resources/session-ideas-handouts/

Basadur profile – do you prefer to generate ideas, develop them, optimise them, or get them done?

https://media1-production.mightynetworks.com/asset/2451528/en-us_profile_booklet.pdf

Work in the open so the team can see your work sooner

Use a work agreement such as this template I use with my students.

Agile charterering template

Do something social together to build trust and empathy. You can use So Cards https://www.socards.org work well for connecting people, or just share a meal or coffee together.

Coordinate across time zones https://www.timeanddate.com/worldclock/meeting.html

Be humble and ask for help and feedback

Crucial conversation exercise

dialogue for teamwork and exercises

Meet regularly with a suitable cadence for your context

Use whatever most people are already familiar with, and find comfortable to use. You might need two different methods depending upon your circumstances.

Set up calendar entries for meetings (send invites even) so that the dates are known in advance.

Use google translate as required if team members are more comfortable in different languages. Use this in meetings as required.

For written communication you might create a WhatsApp, or Messenger group, but could also be a team on Microsoft Teams, or Slack. The goal is to have something simple to use which everyone will see on a regular basis, for those times when an urgent decision needs to be made. Create one channel per topic so that conversations are easier to follow.

Accept that it’s all guesswork and start small to learn more

Visualise the work you think that you need to do. Use Trello https://trello.com or Jira https://www.atlassian.com/software/jira to create task boards to detail the work to be done. Start by just listing the tasks, or pieces of work that need to be done.

You could also use a Miro whiteboard https://miro.com to dump ideas out using virtual sticky notes. This would let you put ideas into groups, and other organise them to better understand what needs doing.

Slice items down to ‘about a day’s worth of work’ so that it is easier to envision how much work is required.

If you’re timeboxing the work in chunks, then ensure that no item is bigger than a timebox.

Build deployable small vertical slices to learn more quickly

Prioritise the work so that you eliminate risks first.

Organise the work into workable chunks so that at the end of a timebox you have something workable. If this is a report, then a poor first draft, a better draft after that, etc. If this is software, then a skeleton feature should be done first, then add more functionality with each successive slice until you have a complete cake.

Keep doing the next riskiest item in order to reduce risks quickly

Suprises happen in all work. The goal is to have them happen sooner rather than later.

You should identify the riskiest parts of the work and do those as early as possible. Then remove the next riskiest part and so one. Sometimes you can do this through mitigation, or avoidance, but not always. This is why you do them early and remove them so that you know they are resolved and don’t hold you up later in your work. The goal is to remove the likelyhood of surprises, which slow down, or endanger the work you’re doing. If surprises, happen, then it is better to have them appear as soon as possible in the work, so that the team vision is still possible.

Shorten your feedback loops, so that you learn faster

Any team where one person is late, or the work is to the wrong standard (plagiarised), or where the team works in big slices makes integration hard. The team works best when people are present to do the work, communicate regularly, and do the work (integrate their work) in small slices.

During each round integrate everyone’s work. There are a number of ways to do this, and different aspects that you need to consider.

First, you need to be able to show your work to your team members. At the very least you should be able to share your screen so that others can see your work. This way you can pair and mob on the work with a ‘driver’ sharing their screen, and a ’navigator’ telling the driver what to type, with others (the mob) offering up ideas to the navigator. When you rotate roles, send the file to everyone and the work continues. At any one point, however, only one person has the ‘current’ version.

Second, you should be able to work together on the same document at the same time. For this you can use any number of online options from MS Office 365, Google Docs, Miro, etc. Working in the cloud safeguards your work against loss of any one persons device too. With this option you can all work simultaneously on the same document, and consistently revise each others work.  You could also use the same pairing and mobbing approach mentioned above without having to send the file from person to person.

Always be pausing to review your collaboration

The team is always learning during their collaboration. At the end of each timebox take the time to review how you did the work so that you can improve its processes. Each of these is a format for a team discussion on how they might improve the way they work. Some ideas will work, others will not work. That is ok. This is a learning process, that will improve how the team works.

Use Easy Retro for adaptable retros.

---