These collaboration rules will guide your student teams
Students always ask me what to do next, or how they should approach a situation in their software engineering team. You probably have similar experiences. These are also the parts that are infrequently covered in the textbooks.
You can use these 10 guiding points for your software engineering student teams so that they always know what to do. These are basic rules that work in any collaboration.
The collaboration rules are:
- Always be collaborating, instead of working on your own
- Aim for diversity to improve your work
- Work in the open so the team can see your work sooner
- Be humble and ask for help and feedback
- Meet regularly with a suitable cadence for your context
- Accept that it’s all guesswork and start small to learn more
- Build deployable small vertical slices to learn more quickly
- Keep doing the next riskiest item in order to reduce risks quickly
- Shorten your feedback loops, so that you learn faster
- Always be pausing to review your collaboration
These cover all that they need to do both within the team, and with their client, or customer. As you can see the goal is to have short feedback loops, and build quality into their work, in an incremental and iterative manner. This is all agile, both in action and mindset. It is also a learning experience as the team learns about each other, and the product they are building together.
You might notice that these align with the ten phases of collaboration, that I’ve also identified. These rules seemed an easier way to share the concepts with students.
Introduce these 10 guiding points to your software engineering student teams so that they always know what to do.
Always be collaborating, instead of working on your own
You should work with others so that you gain faster feedback, and have someone you can talk to discuss the work. Pair or mob with the team on everything. This improves the work you produce.
Aim for diversity to improve your work
Form diverse teams to gain more perspectives. Everyone has their own journey to this place and time, so let everyone’s perspective come through in the work you do together.
Work in the open so the team can see your work sooner
The sooner the team see’s the work, the sooner it can be integrated and validated against the rest of the work. This means team members should know what each other is working on, and they should be merging their code regularly into the main branch.
Be humble and ask for help and feedback
We all make mistakes. No one has all of the answers. The sooner we accept this, the easier it is to ask for help from others. This also means asking for feedback from your client on a regular basis, and asking well before you think you might be ‘done’.
Meet regularly with a suitable cadence for your context
Set up regular meetings to do the work, and to check in with each other on tasks. Set the schedule based upon your deadline, and work backwards. Give yourselves time to do what you need to do.
Accept that it’s all guesswork and start small to learn more
You are inexperienced, and estimation takes more time than you have in any case. Just do enough design to understand the basics you need to know to start, and then identify small pieces to build in the current time box and start. This is a learning experience, and you’ll know more for the next time box.
Build deployable small vertical slices to learn more quickly
Decide upon the skeleton of the application, the simplest thing you can do to deploy something. This should be a bit of the persistence layer, something from the business layer, and something visual. For example, a static web page, or the welcome screen of a mobile app. Now add some functionality in the next slice of work. Rinse and repeat. This gives you something to show, and something people can give you feedback on from the start.
Keep doing the next riskiest item in order to reduce risks quickly
There are lots of risks when building new products, so remove them regularly. Does the tech work together? Build something to check. Can you deploy where you hope to? Deploy and find out. Keep doing this so any surprises can be dealt with before your deadline.
Shorten your feedback loops, so that you learn faster
Try to never work too long on anything without getting feedback. Feedback will confirm you’re doing the right thing at the right time. This also reassures your team members, and helps your own confidence too.
Always be pausing to review your collaboration
Teams fall into habits, and routines. Pause now and then to confirm with each other that you’re working in a good manner. Consider if you can smooth out any messy parts in your process, or ease your communications with each other. End the meeting with one new experiment to try to see if it improves your work.
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. As a bonus, they will also be able to apply them to life in general. They will thank you later.
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.
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.