If your team is facing difficulties due to differences in skill/motivation/availability among team members,
First, do not expect everyone to have the same skill/motivation level as you. It is fine if someone wants to do less and have low expectations from the module. That doesn't mean that person is a bad person. Everyone is entitled to have their own priorities.
Second, don't give up. It is unfortunate that your team ended up in this situation, but you can turn it into a good learning opportunity. You don't get an opportunity to save a sinking team every day 😃
Third, if you care about your grade and willing to work for it, you need to take initiative to turn the situation around or else the whole team is going to suffer. Don't hesitate to take charge if the situation calls for it. By doing so, you'll be doing a favor for your team. Be professional, kind, and courteous to the team members, but also be firm and assertive. It is your grade that is at stake. Don't worry about making a bad situation worse. You won't know until you try.
Finally, don't feel angry or 'wronged'. Teamwork problems are not uncommon in this module and we know how to grade so that you will not be penalized for others' low contribution. We can use Git to find exactly what others did. It's not your responsibility to get others to contribute. Some folks have genuine problems that prevent them from contributing more although they may not be able tell you the reasons. Just do your best for the project and assume everyone else is doing their best too, although their best may be lower than yours.
Given below are some suggestions you can adopt if the project work is not going smooth due to team issues. Note that the below measures can result in some team members doing more work than others and earning better project grades than others. It is still better than sinking the whole team together.
Adjust targets:
- Ask how much each person is planning to contribute (e.g., how many hours per week can be dedicated to the tP), especially from those who seem to be contributing less. In addition, you can use past conduct to estimate how much you can expect from each person in the future.
- Get some idea about how value each person is able to produce. Time doesn't always equal value.
- Based on the above, estimate how much 'real' manpower you have and and adjust your targets accordingly.
Redistribute the work:
- Stronger programmers in the team can take over the critical parts of the code.
- Also note that in real software projects, it is not unusual to have less-than-100% members because some people need to divide their time between multiple projects. Treat this as a similar case and adapt accordingly.
Enforce stricter integration workflow: If the problem involves low-quality work, appoint an integrator (typically, the strongest programmer). His/her job is to maintain the integrated version of the code. He/she should not accept any code that breaks the existing product or is not up to the acceptable quality standard. It is up to others to submit acceptable code to the integrator.
If you have very unreliable or totally disengaged team members :
- Re-allocate to others any mission-critical work allocated to that person so that such team members cannot bring down the entire team.
- However, do not leave out such team members from project communications. Always keep them in the loop so that they can contribute any time they wish to.
- If such a member indicates they want to contribute late in the project (by which time you may have redistributed the work to other members), there is no need to disrupt your current plan. Instead, you can suggest (or let the person figure out) ways to contribute without affecting the current project plan. For example, the person can add an additional nice-to-have feature that will not require changes to other features.
- If such a member offers some code that you believe to be detrimental to the project, you may refuse to merge that code. In that case, that person may contact the teaching team so that the unmerged code can be factored into his/her grading.
- Furthermore, evaluate them sincerely and fairly during peer evaluations so that they do get the grade their work deserves, no more, no less.
- Keep the teaching team informed about such members so that it can be factored into your own grading. If appropriate, we'll exclude such team members when calculating your team size, although the team size does not affect most of the tP grade components.
- Keep copies of your communications with team members, in case we might need to verify exact details of those communications later.
If you are a 'low contributor' yourself:
- It goes without saying that the best policy is to keep your team members informed about how much you can contribute, during which periods, (and possibly, the reason for your low contribution).
- Promise only what you can do, and do what you promised, on time, and up to the expected quality. Sloppy work or late work is worse than no work.
- If the team refused to accept your work, you can still earn marks for that code. You are allowed to submit such 'rejected' code for grading.