You need to make it easy for your work to work on other people’s machines too.
Some teams have members who race ahead of the team and return with a surprise solution prototype. This is presented with great flourish and sometimes includes a puppy-dog approach of waiting for a pat on the head. When a team member does this, it leads to lots of problems.
There are now two versions of the app. One version is the surprise version, just presented by the team member, who has everything working on their machine. The other version is what the rest of the team were working on. The team needs to decide how to deal with this surprise version that is now available.
Usually when this situation arises the team is still trying to unity itself on tools, platforms, languages and other issues. There is usually an agreement on version control, but sometimes that is as far as the team have gotten.
As a result the surprise version might be well ahead of topics the team has discussed. This poses challenges such as:
- How to integrate the new version into the old version the new code, and teach people new frameworks, libraries and other possible issues
- How to handle previous decisions about the requirements and related tasks
- Plus all of the issues around communication, trust, working agreements, and other team issues
Let’s address these one at a time.
Integrating the surprise version into the old version
If the team had not made many decisions, then this could be simple. If not, then people might need to learn new libraries, and other issues in order to implement the new version into the codebase of the old version.
The wrong way to do this is for the person to say ‘it works on my machine’ and leave it at that. In this scenario the person feels they did their part for the team, and can stop contributing. This is the path to conflict.
The better path is for the person to teach the others what they found, and to slowly integrate the new work into the main codebase. Ideally this would be a mob session so everyone can learn together, pairing with different people would also help to spread the knowledge through the team too.
Validating the requirements against the surprise version
Often the surprise version is a partial solution to the requirements for the app being developed by the team. It resolves an issue the team was facing, but is incomplete. The team now need to explore how this new possible solution compares to what was discussed. Yes, it might solve a number of issues, but often only supports a part of the solution.
This surprise version usually arises when someone follows the thread of an idea. This is usually something that interests them, and they keep working on it, as they discover fast progress given their previous experience. This means they might have found a partial solution. While meeting some requirements, it might pose issues for others.
The less useful version of this scenario is when the person has quietly worked on their version, and not told the others, who have resolved this issue already. Due to focus on their own work, the person didn’t realise that their solution is no longer needed.
A better version is that the person and the team know what is happening. Now the new version might present more work for the unmet needs than the previous plan. More discussion and exploration is needed, but everyone is aware of the issues.
Team issues raised by the new version
This new version is sometimes a surprise to the rest of the team. The person often does it without communicating their progress, or intentions to the team. They might have also gone off-track from their intended work agreements too. This might raise trust issues with the team, who might wonder if the person will regularly go off-track, and not tell the team what they’re doing.
In transactional terms this appears as coordination instead of collaboration. The person did their work, and wants to hand it off to the rest of the team to use. The person might feel they did their ‘bit’ for the team, and can now sit back and do less. This is an unhelpful approach, which only leads to conflict with the team.
A collaborative approach would see the person pitching in to show others how this solution helps everyone. They would pair with others to integrate it in small vertical slices with the rest of the code, and adding tests as required to validate the quality of the work.
Avoid these surprises by teaching students the collaboration rules
These situations can be avoided when you introduce the collaboration rules early team projects. The rules guide students so that they know these sort of surprises break a number of rules.
These surprises break a number of rules. Always be collaborating. Work in the open so the team can see your work. Build deployable thin vertical slices. Others are broken by implication of doing too much on your own.
Since I started teaching students these rules, I’ve not experienced these surprise solutions anymore. Instead, people bring their ideas to the team to explore, and discuss. This means the team keeps following the rules while seeking to apply the solution as a team.
Save your students from the surprise ‘works on my machine’ solution, and teach them the collaboration rules.
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.