Team Workflow

The team workflow is a document that outlines team roles. It also gives us information about organizational issues, like team meeting times. This helps us send course staff to aid you and helps us to follow your progress.

The main purpose of this document is to give you some rules for team process, management, tracking, and goal setting. As a general rule, groups work pretty well in this course.
However, any good working group will have some measurements in place if something goes awry.

Table of Contents

• Team Folders
• Document Format
• Submission

Team Folders

All written work will live in the team’s Google Drive. This includes slides and deck docs, too. It is expected that all students will write, edit, and present equally. Before anyone starts writing, review the writing guidelines. Everyone is expected to know and follow them from the first day. The ENGRC instructor has created a Google Drive for your team. Use that folder for all documents, revising, and slide files.

Document Format

The Team Workflow should be the first document created in your Google Drive. Format the workflow as a memo. Memo formats are popular in industry, and you can find templates online. Most importantly, a memo has a date, so you can change the date whenever the workflow document must be changed.

Note: It is very important that your entire team agrees to the document before it is submitted. Reread it carefully before submitting it. One of the first things that we want in the document is an affirmation that everyone has read the document and agrees with it.

We have included a sample document for you so that everyone can see what we are looking for. This memo is annotated to show off the important parts. The team’s memo should start with the following header:

To:   Course staff, and from the entire group
From: Include both your group name, number, and the names of all members
Re:   Team name and number and "Workflow"
Date: Whenever you finalized the most recent version of the workflow

After this header, you break your document into several sections.

Section 1: Preamble

In a private conversation, each member should discuss with the team that grade each person desires. This makes sure that everyone understands the commitment level from each team member. This should not be reported to the instructors. However, the workflow document should state that this has been discussed and understood by all team members.

The second item for the preamble is a statement that everyone on the team has read and understood the writing guidelines for the class and will apply them to all communication pieces for the course.

Section 2: Team Roles

The first major section of the document should list all of the team members and their roles. For each team member we want the following:

• The member’s preferred name and how to pronounce it
• The member’s pronouns
• The member’s preferred contact e-mail
• The member’s role on the team
• A short, positive-sounding paragraph on the member’s skills as related to Games Design
• A bullet-point list of the member’s duties (which may change over the semester)

You can see how we formatted this in the sample document. The sample we have provided does not include a Task Table, but your team will be asked to provide one. Read on for more information.

For the list of bullet points, please pay attention to the writing guideline for the course. We will reject extremely disorganized workflow documents.

Note: It is usual business practice to use people’s LAST NAMES in documentation, out of both tradition and respect. Please follow that protocol.

Team must determine at least three roles on the team:

Project Lead

This person is in charge of assigning tasks and keeping the team on top of deadlines. They are also responsible for gathering together the information for the bi-weekly reports (though everyone is expected to contribute). This should be someone who can get along with everyone on the team.

Software Lead

This person is in charge of the architecture decisions on the project. They lead the design of the architecture specification and have final say on all class interfaces. They also assign programming tasks to the other members of the team. This should not be the same person as the Project Leader.

Design Lead

In the case of multiple designers, this is the person who sets the visual aesthetic of the game. They have final say on the artistic style of the game, and the other designers are expected to conform to this style.

 
Other roles that the team wishes to use are allowed, such as Audio Lead or Junior Programmer. No matter what the roles are, all students will present, write, and edit equally during the term.

This early, teams might not be sure about all of the responsibilities that everyone should have. The sample workflow document reads like one that has been written half-way through the course, once everyone has figured out the best way that they can serve the team.
This is okay. Teams are allowed (and expected) to make changes to the document later on.
Right now, just make a good-faith attempt to assign roles to everyone on the team. It is acceptable at this early stage if someone has a single responsibility like “Will complete any programming task assigned each week.”

Section 3: Team Coordination

Provide information about how the team is going to coordinate its actions all semester long. While you may think of other things that to specify, we expect the following information at a minimum.

Meeting Times

Your team is expected to have at least one official meeting one hour a week. These are the team’s offical office hours; we will come to you instead of you coming to us when teams request help. This semester, we will not attend any in-person meetings unless it is an emergency. We ask that you meet virtually in Discord so that we can find you.

If you are going to meet more than once a week that is acceptable. Please add this to the documentation, as well. However, only write down the times for regular weekly meetings. Do not include ad-hoc meetings.

Minutes

During the official meetings, rotate a “scribe” who should write down what was discussed at the meeting and what (general) tasks were assigned to each person. All meeting minutes should be compiled into an ever-growing Google Doc in the Drive.

Communication

Describe in good detail the team’s planned main mode of group communication. Will you limit yourself to the course Discord? Will you use e-mail? Slack? Google Hangout? Something else? Whatever mode that is, the ENGRC instructor must be able to access it, and she should be invited into that modality.

More importantly, outline the expected etiquette for this communication. For example, in the sample workflow document, we spell out some basic rules for using e-mail. We specify whether everyone is expected to respond, and when they must respond by. This gives us an official way to determine when someone has “stopped communicating” with the rest of the group and should be reported to the instructors.

File Sharing

For code, everyone is expected to use GitHub to manage source code this semester. If you do not have a GitHub repository, we will assign you one. However, GitHub is not ideal for the artists and designers. If they are going to use something else (e.g. DropBox, Google Drive), tell us here.

For all documents and slides, Google Drive/Suite will be your only working platform.

Task Table

Create a similar version of this table. Fill in the last three columns (Writing Leaders, Editors, and Rewrite Leads) with specific people, taking care to rotate responsibilities equally. If this changes during the semester, update the Workflow document. This task table will be checked by the instructors all semester to sync up with documents, talks, writing, editing, etc. It will be compared to the work shown in Google Drive and GitHub.

Section 4: Conflict Resolution

The last section is where you spell out how you will deal with conflicts in the group. If you are unsure of what to write here, we strongly recommend that you contact Traci Nathans-Kelly, as she has experience with this particular issue. Historically, there are two types of conflicts in this course. There are creative conflicts, where team members cannot agree how the game should be designed.
There are also problems when a team member misses a deadline or cannot complete the tasks assigned.

Creative Conflicts

In dealing with creative conflicts, there are two popular choices. One is to assign each team member “ownership” of a specific part of the game, and give that person final say for any decisions that have to do with that part. This is what we have done in the sample workflow document. This choice makes decision making very efficient. However, it can make it so that other team members feel like they do not have a real voice in the game design.

The other option is to go full democratic and vote on decisions. This is fine, but if the team does this, the workflow document must spell out the rules for putting something up for a vote, for counting the votes, and for recording the votes. We find that the groups that run into trouble are always those that take a democratic approach but do not have established rules for voting.

Actionable Consequences to Participation

Missed deadlines are very serious. If someone on the group is regularly missing deadlines without an excuse, we want to hear about it in the two-week reports and in the CATME surveys. This is exactly the information that we will use to adjust individual grades at the end of the semester.

However, we find that unless there is some immediate consequence, the team member is unlikely to improve in the future. The individual grade is not assigned until the end of the semester, and the two-week reports can feel very abstract. That is why the example in the sample document includes a rule for treating the rest of the team to CTB as a consequence for missing meetings.
For minor problems, teams might find that a minor consequence is enough to reset behaviors and that you do not need to report the issue in the two-week reports.

Teams are also heavily advised to outline consequences for missed course deadlines, which are more serious than internal deadlines. For any consequences described, a solution is NOT “and we will contact the instructors,” which is too vague. Of course, contacting the instructors is welcomed, but that consequence needs to be very specific in how it plays out.

Example: “If a member misses input for a course deadline, the project leader will collect evidence from our Slack Channel, our e-mails, and our GitHub.
Those items will be packaged for the instructor and sent as a PDF, along with a recommendation that the person should receive a 15 point deduction for that major deadline.”

On a brighter note, each team should also outline the ways in which they can acknowledge when a contributor goes above and beyond the call of duty.

Submission

Due: Wed, Feb 10 at 11:59 PM

One person on the team should submit a PDF file called workflow.pdf containing all of the information above. The file should be a PDF so that the instructors can annotate and provide feedback for revisions.

In the case of later documents like the concept document, teams will revise and resubmit the document multiple times (with the final submission part of the Final Document Portfolio). For this Workflow document, we only ask that you submit it once and revisit it often in Google Drive. If we think that it requires revision, we will let you know. Later in the term, we will have other documents (Milestones and 2-week reports) that will impact the Team Workflow document.

However, you will probably find that you need to revise your workflow as the semester goes on. Someone might need to gain new responsibilities, or shift current responsibilities to another team member. You might need to change the Software Lead. You might need to change your rules for handling conflicts. At the end of each two-week report, you will be asked if you have made any changes to your workflow. If so, you will resubmit this memo with the changes and the date that they take effect.