Teach your teams the collaboration rules

Collaboration speeds your product development more than software practices on their own.

Software practices are insufficient to achieve good outcomes. We need to teach our teams to also collaborate in how they do their work together. By doing this they work more effectively together.

Teaching students or team member the process of software development from a textbook covers only the basics. It will tell them about version control, requirements gathering, architecture, and how to build and test the code too. This is a start. It is not enough. These textbooks say very little about how to work as a team. It might tell you to coordinate activities with team members and your client. These books don’t tell students how to collaborate.

Software engineering textbooks leave out the collaboration details. Students need details about how to organise their work, how to stay in touch with the team, and many other aspects before they can do the work. They also need to be taught how they should organise themselves to do the work. Yes, the textbooks discuss options for version control, for example, but leave out details such as how frequently to merge their code, and how often to commit their code, how often to meet, and many other questions.

The teams that excel at software development collaborate. The best teams move beyond coordination of their work. These teams look for opportunities to improve the speed of feedback on what they do. They ensure everyone knows what is happening, and how to get help.

The collaboration rules below guide you, and help your teams move from coordination to collaboration. Use them with your teams.

The Collaboration rules guide your goals and practices

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

These rules will guide teams in their collaboration. If they start where they are, and then simply begin to improve in each of the areas as they move forward, then their collaboration will deepen; quality of their work will improve, and they should also find their work speeds up too.

As you read these you’ll see some places where this fits into the scrum process. You’ll also see that the XP practices fit into collaboration too.

Always be collaborating, instead of working on your own

Working on your own sucks. You have no one to turn to and ask a question.

Teach students that collaboration wins. Work with a partner or two so you have instant feedback. You will discuss what to do, do it, and discuss your work as you proceed. You can start by having students pair program together. Maybe you want to run a code retreat exercise, as a way to bring in people from industry.

Aim for diversity to improve your work

Homogeneity means more of the same. We need different perspectives to improve what we’re doing.

Put students together into diverse teams. Do this for some small exercises, and students will learn the benefits of diversity. Then do it for their larger team projects too.

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

When you hide your work, no one knows what you’re doing. They can’t say that you’re going in the wrong direction.

Students should only work in the main branch. Show them the problems with coding being hidden in feature branches. Trunk-based development looks complicated to them, so set up some exercises to show them how they benefit from small, frequent merges of everyone’s code. Show them too, that the easiest way to do this is with mob or ensemble programming.

Be humble and ask for help and feedback

None of us know everything. We all make mistakes.

Teach students that as they are learning, they will have questions. Teach them that it’s ok to ask questions. Help them set up team rules about how and when to ask for help. Illustrate the frustration and issues that teams encounter when work doesn’t appear as expected, and that it is better to ask for help earlier rather than later.

Meet regularly with a suitable cadence for your context

Yes, meetings can be dull and unhelpful. We do need to keep in touch with where we’re at, and in-person speeds up communication too.

Teach students they need different types of meetings in their work. Tell them about decision-making meetings, and working meetings where they do the work. Help them set up schedules for both types in their team charters.

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

Students are doing these things for the first time so it’s all new.

Point out to students that estimating work is hard, and might be pointless. Show them with small exercises that it is easier to slice work down to about a day of work, and just start. Illustrate that if they are wrong at this scale, then that is fine. Create exercises to show them that they should keep the work to small chunks, as this is easier to focus on.

Build deployable small vertical slices to learn more quickly

Your client wants to know where you’re at with the thing you’re building for them. Show it to them early and often.

Software is there to aid a business. Teach students to work in small, vertical slices so they can show a working slice to their client. Yes, teach them about the layers of an application, but tell them, show them, that we build apps in thin vertical slices. Teach them how to widen functionality with successive slices. Make it clear that by deploying early, they learn faster where the client wants to go with the application.

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

Risks need to be addressed or they will not be reduced. Assumptions are just as bad.

Guide students in the risks of their work. Teach them to confirm assumptions as they build their apps. Point out that deploying early confirms assumptions too, as does letting the client use it too. Show them the benefits of early surprises, which leave time to fix issues and change plans.

Shorten your feedback loops, so that you learn faster

Without feedback we don’t know if we’re doing the right thing.

Teach students the benefits of early feedback. Try a thought experiment. Do they like many smaller assessments so they know where they are with grades in a course, or fewer larger ones? Then point out options and possibilities for them to gain feedback in their team’s collaboration. Feedback in the code, in the application, and how they are doing their work.

Always be pausing to review your collaboration

Retrospectives help us improve on our work.

We never know everything. There is always more to learn. Teach students to pause and reflect on their collaboration so that they can experiment with improvements.

Share the collaboration rules with your students

These ten guiding points will keep your software engineering student teams on track in their work. They will always know what to do in any situation in the team.

Go over each rule in your classroom. If possible introduce them before their larger team projects. If not, then doing it then works too. This is what I’ve mostly done. Sometimes I can introduce ideas sooner, but not always.

You can get a one-page version of the rules to use with your students.

Sign up for the mail list below for a more detailed version of of the rules as a PDF from the book.

---