Guidelines for Team Standards

Overview

The key to effective teamwork is shared agreement on the expectations of teammates concerning how the team will function. Standards may range from assigning specific roles to each team member, to establishing protocols for conduct and communication, to agreeing on what tools (version control, word processor, etc.) the team will use. Team standards — of all these kinds — establish a common understanding of expectations, and facilitate efficient and effective collaboration. Without these norms teams have difficulty communicating and cooperating since each individual may have a different interpretation of how things should be done.

The assignment

For this assignment, your team is to prepare a Team Standards specification document, with the following sections: with the following sections:

The wrapper

A nice professional cover page; this and all cover pages for subsequent documents should have the title of the document, the date, the team name, the project sponsor, the team's faculty mentor, and list of team members. A team logo is nice, once you have developed one. Make a good cover page, and you can re-use is all year.

The Intro

Always start with a short introduction paragraph that briefly outlines the purpose and content for the the reader. This way the reader knows what this document is, and what content to expect in upcoming sections.

Team members and roles:

This section should introduce each team member and the role(s) you envision (based on your internal discussion of skills and desires) for that team member, as well as a clear description of the duties involved in fulfilling each identified role. Keep in mind that these roles outline lead responsibilities, but not exclusive ones -- it is expected that all team members will be deeply involved in every aspect of your project. Roles may include, but are not limited to (feel free to identify and discuss other roles you think would be helpful -- the following are meant to be helpful examples):

• Team Leader: The team member that coordinates task assignments and ensures work is progressing, runs meetings, and makes initial efforts to resolve conflicts.
• Customer Communicator: The team member that coordinates and conducts customer communications.
• Recorder: This team member maintains detailed meeting minutes.
• Architect: This team member is primarily responsible for ensuring that core architectural decisions are followed during implementation.
• Release Manager: This team member coordinates project versioning and branching, reviews and cleans up commit logs for accuracy, readability, and understandability, and ensures that any build tools can quickly generate a working release.
• Coder: It is expected that everyone will have a role in producing code. If possible at this early stage, you might specify *what parts* of the coding (backend, front-end, node.js, MSP430 programming, etc.) that individuals will lead on.

Team Meeting Expectations

This section discusses your agreed upon plan for team meetings, and should include such things as:

• Meeting Times: A set time for meetings that every team member commits to. A standard weekly meeting time is suggested, plus a mechanism for calling impromptu meetings on demand.
• Agenda Structure: A structure for organizing your meeting time; for example, all meetings begin with a 2 minute update report from each member on their activities since the last meeting, or every team member must submit a written one-page progress report to the team leader.
• Minutes: Processes regarding meeting minutes, such as format of weekly meeting minutes and distribution methods.
• Decision-Making Process: In cases of disagreements on design choices, it may be helpful to set a concrete process for resolving them. Be realistic: "we will make decisions by unanimous agreement" sounds nice, but a "2/3 majority" may be more helpful in moving along.
• Attendance: Rules governing each team member's attendance, and rules for handling missed meetings or tardiness. For example, how many meetings is each member allowed to miss? What will be the consequences for (a) one missed meeting (b) additional missed meetings? How will the team deal with members who show up late for meetings? Essentially this establishes the basis for disciplinary action in case someone isn't doing their part.
• Conduct: Specify rules that govern your conduct during meetings, such as rules of order organizing your meetings and preventing non-constructive interactions. How will the team handle interpersonal disputes, divided team, nonparticipating members, team members who change the design without team consent, etc? Try to agree on a *constructive* process that you'll follow, beginning with a polite heads-up, maybe followed by a formal discussion in meeting, and ending in a team discussion with the CS Capstone Organizer.

Tools and Document Standards

In this section, you'll cover all of the tools you'll use, expectations for how they will be used, and related processes. Some examples include:

• Version Control: What mechanism will you use to share/maintain/manage your codebase. Be specific: what are the standards for commits, forking, and so on. We strongly recommend keeping things in a single place (issues, code, etc.)
• Issue tracking: Even long before you start coding, there will be many tasks to do in this project. What will you use to document open tasks, assign them to team members, and monitor their completion? This is typically done with an issue tracking tool during the actual coding/dev process. But why not start using this tool for all tasks doled out within the team?
• Word Processing and Presentation: There will be plenty of technical communication in the next year, ranging from document deliverables to design review presentations. Outline what tools you will use for word processing, presentation, graphical design, or any other task on which the whole team must be coordinated.
• Composition and Review: For larger document deliverables, the team will often assign sections to be written by individual members. Without some planning, this can lead to a horrible mess! In particular, the team has to establish a process for integrating the pieces. This includes specifying a lead editor for that deliverable (can be different every time), deadlines (e.g. 24 hours before due date) for when contributed sections must be presented to the editor (a) as a rough draft and (b) as a final version; these should be well ahead of the due date for the document, allowing the editor to seam the pieces together into a nice coherent document with consistent flow, styles, and level of detail.

Team Self Review

Although we will have regular peer evaluations at the class level, generally associated with major deliverables, it is also important for the team to do its own internal "self reviews". Your Team Standards document should capture how often these get done, and what form they take. For instance, you could decide to do these reviews once a month as part of a regular team meeting. The form could be as formal or informal as you like. For example, you could decide that everyone has to write up a little self-assessment: things I've done well, things I need to work on, plan for improvement and send these to the team leader. A more casual (and perhaps productive) idea might be to have everyone sketch these items out, then go around at a team meeting and have everyone present their items...with ensuing discussion by all. The idea is simply to build in a time for people to give their impressions of their performance (self review), and provide space for others to chime in with agreement, comments, or other productive feedback.

Deliverables

Professionally presented document, in hardcopy or digital as specified by your mentor, at the due date specified on the course schedule. Please submit a version on Canvas by the deadline set by your mentor.