Use the collaboration rules with your students

Enhance your students’ collaboration skills

Pick your textbook, and other teaching materials, and then layer in the collaboration rules to level up the team skills. The collaboration rules guide people in how to do the work together. The rules point out where and how to collaborate.

Without the collaboration rules students are unsure of how to do the work, and fall back on individual work, which is then gathered up later for integration. This is a poor option compared to doing the work together. Use the rules to guide them to a better collaboration.

These ten rules provide a way for you to know if something is helping or hindering your collaboration.

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

Enhance your teaching by adding in your stories, or the ones you’ve heard about to illustrate the poor outcomes of teams that didn’t follow these practices, with those that did. Over time you can also add more example of previous teams that did follow them, and improved their team outcomes.

Always be collaborating, instead of working on your own

There is almost always a team where one person fights against the team. The person, who rewrites everyone’s code, and plays the hero. This is the wrong way to work. This is being ‘in a team’. This is not collaborative.

It is always better to ‘do the work as a team‘. Pair on work, do everything together with everyone as an ensemble or mob. This is the way to collaborate.

Aim for diversity to improve your work

Doing the work on your own means you do it all yourself. There is only your perspective. This is not collaborative.

Pair and mob on the work to get more people looking at the work, and offering their perspectives too. This improves the work as differences arise from each person’s experience.

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

There is often a perfectionist, who gets hung up sharing their work before they’re ready. This slows down the team. By hiding their work no one can use it for their work either.

It is better to collaborate on the work in pairs, or as a mob so that everyone can see it sooner and offer feedback.

Be humble and ask for help and feedback

The hero will take criticism and questioning of their work poorly. They want to ‘save the team’, but only make everyone’s work slower.

A better option is to admit there are issues, and ask for feedback sooner. This lets issue get resolved more quickly, and others can learn from possible mistakes too.

Meet regularly with a suitable cadence for your context

Teams that meet irregularly do poorly, as their work is not coordinated for effectiveness.

Teams that set a regular schedule of meeting for decisions, and others for doing the work, do best.

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

Teams that take too long to start because they want to make all design decisions and work plans before they start the work find they run out of time. You can’t know everything up front, even if you have sketches for all of your screens.

There is always more to be discovered by doing the work than you expect, and you have to just start.

Build deployable small vertical slices to learn more quickly

Lots of teams want to build the horizontal layers, one on top of the other. This is very slow. The data people need to share their work with the other backend people, and so on. This is very slow.

Build thin vertical slices along functionality, show the catalogue on a screen, make log in/log out work. Then add to this growing stack of work, and you’ll find the app grows more smoothly.

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

Keep putting off the risky work, such as deployment, until later, and then you find it takes much longer than expected, and you might also run out of time. The longer you wait to do the risky parts, the more there is to keep track of, and the harder it is.

A better option is to address the risks sooner, while the pieces are smaller, and less complicated. This makes it easier to see the issues, and resolve the risks.

Shorten your feedback loops, so that you learn faster

The team that wants to only show perfect work will discover too late that they went in the wrong direction, or overlooked crucial aspects because they only found out about issues too late.

Show your ugly work while you know it is still ugly, so that it’s easier to accept criticism and feedback as well as confirmation that you’re going in the right direction.

Always be pausing to review your collaboration

The team that just keeps moving on without pausing for reflection will do plenty, and then realise that they could’ve done much more if they’d paused to rearrange their work process now and then.

Pause now and then to reconsider and reflect on how you do the work to find ways to do it more effectively.

Go over these rules with your people

Introduce the rules and tell them your examples and then let them talk about them in their teams.

Maybe have teams share their ideas of how they’ll use them too so they are more co-created by the teams. Share one year’s experience with the new year’s cohort and you’ll start to see improvements. If senior cohort students help with newer cohort students, then students are guiding students, which is even more effective.

The key issue to create opportunities for each team to decide for themselves how they want to use the collaboration rules in their team.

---