Spread knowledge within the team to raise your bus quotient
When the team starts to develop their new application together many things might be new to them. They might have done a web application before, but maybe not in this language, or framework. Maybe they did some javascript before, but not drawing on JSON objects where they need to write a RESTful API. This time the circumstances present something new to the team. Maybe too, the team has not worked together before. This too is a risk.
This makes the whole project risky in a basic sense. The application is new. The team is new. They need to develop a shared understanding both of the application to build, and how they will do the work together.
The team can prioritise its approach to the development work. As mentioned previously, resolve the basics, and then start to add more functionality. This works as a general rule. If the team discovers the need to add something new, then that becomes the ‘new risky thing’ until it’s been explored and applied.
Spread knowledge in the team to reduce risk
The team should also prioritise how it will do the work together so that the members build shared understanding of each other. Knowing your team members, and their strengths and weaknesses is also important. This is why we spend time on team charters and team canvases.
The team also need to spread understanding of the application within the team. This means that more than one person should know how the different parts work, If only one person knows the database details, then when they win the lottery, and leave, nobody knows how to take this further. In the sad version, they get hit by a bus, and traumatise the bus driver. The result is the same. The team is left without a database person,
By spreading knowledge the team also have people who can help each other with smaller tasks. No longer is one person the bottleneck on development. Now, more people can help.
This needs to be planned in from the start so that everyone can help out on all parts of the application as required. This means rotating pairing for programming, and doing some ensemble, or mob programming too. Everyone should be doing the work to learn the ins and outs of different parts of the application.
Guide your students in this area with gentle questions
I mention this in some lectures. When I’m talking to individual teams. I ask them how they’re breaking up the work. I. also ask them when they pair, or do ensemble work. If I find that only one person is doing a part, then I ask what happens when that person leaves the team as they won the lottery. Yes, they smile, but I also point out they could have an accident commuting, or at work.
Do what you can to get them to think of these issues.
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.