Working effectively in a group is a critical skill in modern software engineering, both in the startup context and generally. Group work can be hard, and not all teams succeed, and in fact a major contributing factor to startup failure is team breakdown. The educational context adds its own complexities: team members sometimes cannot prepare for or attend group sessions because of other responsibilities, and conflicts can result from personalities, differing skill levels, work ethics, working styles.
We encourage the following practices to ensure successful group work:
- Agree on a protocol for meeting and communication. Some, but not all, of these decisions will be technical (Slack? Trello?) that arise naturally over startup development.
- In the startup context, engineers must be flexible and capable of filling many technical roles. In an educational context, however, group work is most successful when groups designate clear roles, such as coordinator, scribe, monitor, and checker for each assignment. Agree on roles at the beginning of each assignment. Rotate these roles for each assignment to ensure fairness.
- Agree on meeting times and what each member should have done before the meeting (readings, development, writing, taking the first cut at some or all of the assigned work, etc.). The scribe documents the agreed tasks and deadlines and communicates them to everybody. Not objecting to the communicated protocol constitutes acceptance. Make agreements visible to every team member, with transparent history of the log.
- The coordinator checks with other team members before the meeting to remind them of when and where they will meet and what they are supposed to do. Team members notify the coordinator in advance if they cannot attend a meeting or are in danger of not making a deadline.
- All individuals perform the required individual preparation before the meeting.
- During meetings/work times, the coordinator sets the agenda, and keeps everyone on task; the monitor ensures everyone understands both the solution and the strategy used to get it, and watches the time to ensure meetings stays within the agreed timeslot; and the checker double-checks the result before it is handed in, and submits it (or clearly delegates its submission, if the checker is unable to do so on time).
- At the end of each meeting, agree on the next meeting time and responsibilities.
- Review returned assignments together. Make sure everyone understands why points were lost and how to correct errors.
Preventing and dealing with problems
We encourage you to communicate openly with your teammates, which is often enough to help resolve many types of team challenges. Clearly documenting agreed-upon tasks and deadlines (see scribe role above) and tracking invested time helps in identifying issues. Renegotiate agreements when estimated time does not align with actually required time and imbalances arise. Document where agreements were not honored (what and when, and possibly why). Identify a fallback strategy, ideally in agreement with the team member who failed the agreement. In severe cases, identify how other team members can take over those tasks.
If a team member does not contribute to an assignment solution, their name should not be included on the completed work.
If the problem persists and cannot be solved within the team, the team should meet with the instructors so that the problem can be resolved, if possible. If problems continue, the cooperating team members may notify the uncooperative member in writing that he/she is in danger of being fired, sending a copy of the memo to the instructor. If there is no subsequent improvement, they should notify the individual in writing (copy to the instructor) that he/she is no longer with the team. The fired student should meet with the instructors to discuss options, such as finding another team willing to add them as a member, completing the work alone, or getting zeroes for the remaining assignments.
Consult with your instructors if a conflict arises that can't be worked through by the team.