Team Workflow Document
Due: Saturday, February 4th at 11:59 pm
The team workflow is a document that outlines the your group roles. It also gives us
information about organizational issues, like your group meeting time. 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 to fall back on should
everything fall apart. As a general rule, groups work pretty well in this course.
However, there is always one group that falls into problems, and this will give you
some protection if you are unfortunate enough to be that group.
As part of our attempt to make the charter more formal, we ask that you format
your charter as a official looking memo. Memos are popular in industry, and you
can find ready made templates for them in Word
and LaTeX. Most importantly,
a memo has a date, so you can change the date whenever the charter
must be changed.
We have made a sample document for you so that you can
see what we are looking for. The memo should be addressed to the course staff, and
from the entire group. When you are completing the From: field, you should include
both your group name, and the names of everyone on the team. The team name should also
be in the Subject: field. Finally, the date of the memo should be whenever you
finalized this version of the charter.
This document should be in either Google Docs
or Share LaTeX so that everyone on the team
can work collaboratively. Remmeber to turn on Track Features in order to get credit for
this assignment. Invite the both instructors to be part of the of the online group so
that we can see the Track Changes.
It is very important that your entire team agrees to the document before you submit.
Reread it carefully once you are finished. Indeed, one of the first things that we
want in the document is an affirmation that every has read the document and agrees
In addition, each member should discuss with the team the grade the she/he desires.
This makes sure that everyone understands the commitment of each team member.
This should not be reported to the instructor. However, the charter should
state that this has been discussed and understood by all.
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
- The member's preferred contact e-mail
- The member's role on the team
- A short, positive-sounding paragraph on the member's skills
- A bullet-point list of the member's duties
You can see how we formatted this in the sample document.
For the list of bullet points, please pay attention to the
writing guidelines for
the course. While this document will not be revised in the same
way that other documents are, we will reject extremely disorganized workflow documents.
As a reminder, you must fill at least three roles on your team:
- Project Leader
This person is in charge of assigning tasks and keeping the group 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.
Any other roles (Audio Lead, Junior Programmer) are up to you. No matter what the roles
are, all students will present and write equally during the term.
You 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;
you 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 okay if someone
has a single responsibility like "Will complete any programming task assigned to him."
The next section should give us some information about how your team is going to
coordinate its actions all semester long. While you may think of other things that
you want to specify, we expect the following information at a minimum.
Your group is expected to have at least one official meeting one hour a week. This is
your "office hours;" we will come to you instead of you coming to us. For that reason,
we need both the time and the location so that we can find you if necessary. We prefer
prefer times before 8pm, and close to central campus.
If you are going to meet more than once a week that is okay. Please add this to the
charter as well. However, you should only write down the times for regular weekly
meetings. Do not include ad-hoc meetings.
During the official meetings, someone needs to 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 or ShareLaTex doc that both instructors
have access to. Be sure that "Track Changes" or the equivalent is turned on.
Tell us what you plan to use as your main mode of group communication. E-mail? Slack?
Google Hangout? More importantly, what is 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
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.
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 to him or her.
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
you do this, your 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.
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. 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 "punishment," 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. For minor problems, you might find
that this is enough, and that you do not need to report the issue in the two-week
Due: Saturday, February 4th at 11:59 pm
You should submit a PDF file called charter.pdf
containing all of the information above. We ask that the file be a PDF so that we can
annotate should we need to return it to you for revision.
In the case of later documents like the concept document,
you will be accepted to resubmit the document multiple times (with the final submission
part of the Final Document Portfolio). For this document, we only ask that you submit it
once. 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
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.