Always be collaborating and consider how this impacts your work
When I started thinking about team collaboration more I realised that teams need to do a lot of things before they start doing the work. From this I noticed that none of the software engineering textbooks I saw covered these issues.
As a team forms it has to make lots of decisions. There are questions about who’s on the team, and how you stay connected with team members, and decide how much work there is and other things too. Then there is the work itself, and how you decide to do the work. If you put it into a diagram you end up with something like this:
My key revelation was that the majority of these phases are not about the work itself. They are about how the team decides to organise themselves in order to do the collaborative work together.
Each of these is discussed in more detail in the Teaching Team Collaboration book mentioned below. For now, I just want to point out how useful these are for your student teams. Each team can consider them, and how they want to organise their collaboration around them.
These phases can also be turned into collaboration rules to follow to keep the team guided too. This is the key part to pass onto your students, and to consider in meetings with fellow staff members too.
The collaboration rules
1. Always be collaborating, instead of working on your own.
You go further if you have people supporting you than if you work on your own. Students should always be pairing or mobbing on tasks. By collaborating on tasks feedback happens sooner, the team levels up each other’s skills, and they have more fun.
2. Aim for diversity to improve your work.
Homogenous groups miss out on other perspectives. Rotate pairs regularly for the work on tasks too, and include everyone in team discussions. Have a chat with the quiet one, to see they are ok, and to co-create a way to ensure they contribute more regularly to discussions.
3. Work in the open so that the team can see your work sooner.
Be visible and available to your team. Let them know which task you’re working on. Push your work frequently, so that others can use your work sooner rather than later. Keeping your work secret means others worry whether you’re doing the work, and the quality of your work.
4. Be humble and ask for help and feedback so that you learn more.
Everyone gets stuck sometimes, so ask for help. The feedback here applies to both the work being done, as well as asking for feedback from your team members too about how you are as a team member. Be kind and helpful to each other.
5. Meet regularly with a suitable cadence for your context.
Find the right cadence for your team meetings, and for doing the work. Sometimes this means weekly meetings, other times more frequently depending upon deadlines. This is something that you adjust as you learn more about your collaboration.
6. Accept that it’s all guesswork and, start small to learn more.
You won’t know how much work there is until you start building your product. Just start prototyping and exploring the application context and options, in order to gain perspective on what’s possible in the time you have available.
7. Build deployable, small vertical slices to learn more quickly.
Building the product in small, thin slices will help you gain perspective on what’s possible in the available time. Small slices will help you build a testable app, and provide frequent feedback from your client too, while also reducing risk with each slice as you add more work.
8. Keep doing the next riskiest item in order to reduce risks quickly.
By doing risky things early you remove them, or find ways to mitigate them sooner. This reduces stress in the team, and for your clients, who then know that risk has been resolved.
9. Shorten your feedback loops, so that you learn faster.
Smaller sprints or time boxes mean the client sees the work more frequently. Thin deployable slices also provide more feedback too, as does working in the open within the team and the client. By pairing and mobbing you are also gaining feedback from each other quickly too.
10. Always be pausing to review your collaboration.
This is also known as always be learning, always be pausing to reflect on how you do your work. Pause to reflect on how you might improve your work. Always aim to see learning opportunities when they arise.
This is just a list for now. Looking back over the previous posts you’ll find that all of them have been covered at one point or another. These are the themes that I’ll keep returning to as there is so much more to discuss on all of them.
Use this in your classroom
Introduce the collaboration rules to your students. You can use this one-page version of the rules with your students.
When they regularly consider the rules, then they will start to see its impact on their work. Their work will improve and be more fun to do.
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.