Team Workflow

In an article titled “The Discipline of Teams” published in the Harvard Business Review, authors Katzenbach and Smith say this:

Effective teams develop strong commitment to a common approach; that is, to how they will work together to accomplish their purpose. Team members must agree on who will do particular jobs, how schedules will be set and adhered to, what skills need to be developed, how continuing membership in the team is to be earned, and how the group will make and modify decisions.

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 be created in, be revised in, and live in the team’s Google Drive, which you have been invited to by the ENGRC instructor. 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 instructors will use the Google Drive folder for your team, along with code repositories, to check on your levels of consistent contribution throughout the semester.

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 your initial conversation together, each member should discuss with the team the grade each person desires, as well as your external commitments. You should also identify the external members and the number of credits hours that they plan to take (as less than 4 credits translates to less hours per week). This makes sure that everyone understands the commitment level from each team member. With the exception of credit hours for external members, 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 Game Design
• A bullet-point list of the member’s duties (which may change over the semester)

The first four bullets can be done individually, but the last two points should be discussed and shared with the whole team together. 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 guidelines 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.

As part of this process, you 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.

To help with deciding positions or leadership roles, you should have an informal discussion first about everyone’s strengths and goals for the course. 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

You should provide information about how the team is going to coordinate its actions all semester long. While you may think of other things 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 official office hours; we will come to you instead of you coming to us when teams request help.

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. You can use tools such as when2meet or lettucemeet for everyone to input their schedule to find a common time.

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 create a Discord channel? Will you use e-mail? Slack? Google Hangout? Something else? Whatever mode that is, the ENGRC instructor must be able to access it, and 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 Git to manage source code this semester. However, you do not need to use the official GitHub site for your repository (as that would force you to open-source your game). Cornell has a local Git server that you can use as you see fit.

However, GitHub is not ideal for the artists and designers. Art should be in a specific, consistent location like Dropbox and Google Drive. If they are going to use something else (e.g Onedrive, Box, Egnyte, ShareFile, etc.), 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: Team Accountability

Again, from “The Discipline of Teams” we have some pertinent words:

[T]eam accountability is about the sincere promises we make to ourselves and others, promises that underpin two critical aspects of effective teams: communication and trust.

As you know from the course introduction by the instructor, this course is very demanding. At times, it might become overwhelming, while other times you will feel every ounce of your creative and problem-solving self working at peak performance. To that end, it’s a good move to have early discussions about positive participation and also ways to address conflicts within the team.

Positive Participation

In a team discussion, when all of you are present at the same time, discuss the qualities that make for a strong cross-disciplinary teams. The team should agree on several common expectations that they have from themselves, the team, and the project leaders.

Self Expectations

Each member, in turn, should list here at least five positive practices that they will bring to the team’s common course goal. It is recommended that if you have a weakness identified by prior teamwork, you add that weak practice here as a commitment to work on it. For example, if you are a known procrastinator, you should list “having work done on time or in advance” as a positive practice you will bring to the group and work diligently towards meeting. Your positive practices should be quantifiable, as to easily verify if you are following through with them.

Team Expectations

The team should agree on at least five compelling and positive overall team attributes that they all agree on. Have you worked on a team in the past that had good collaboration? Consider adding that team’s practices here. Conversely, have you worked on a team with a particular weakness? Consider adding a practice here to address those concerns. Here are three examples:

Transparency: We will strive to have open conversations and discussions about the course deliverables.

Self and Other Care: Because this course and the semester can be stressful, we want to create a culture of support. If anyone feels overwhelmed or is actually sick, they will communicate with the team so we all can help each other.

Trust: We will trust that we will all participate equally, that we will communicate in a timely way if there are issues, and that we will not tolerate bad behavior from each other. This includes racist, sexist, or other comments; physical safety; and emotional safety.

The team should also craft a sentence or two about how they might acknowledge when a contributor goes above and beyond the call of duty. For example, this might be a recommendation on LinkedIn or comments directed to both instructors via CATME or email.

Project Leaders

The project leaders take on extra work to help keep the entire large team functioning. As such, their contributions should be recognized, and everyone on the team should help to define what those roles mean. See above for the list of standard leadership roles. For each leader, list out expectations that the team has agreed up that are decidedly project leader work and not regular team member work.

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.

Here are a few general tips to prevent major conflicts from developing in your team:

Establish a line of communication for team members to raise issues anonymously. This will allow you to address the conflict without laying blame, or immediately involving the instructors.

Acknowledge conflict directly and early, rather ignore it and hope it fixes itself. The sooner conflict is addressed, the less problems your team will experience. Left unchecked, the conflict may irreversibly damage your team’s morale, and is unlikely to resolve itself on its own.

Embrace different perspectives. Everyone on your team has different strengths, weaknesses, and experiences. When conflicts arise, make an effort to empathize with your team member’s experiences.

Understand that common teamwork behavior isn’t necessarily common. Again, everyone on your team comes from different backgrounds and experience levels, especially with project work.

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.

Missed Deadlines

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. You do not have to choose this option, but the specifics should be equally consequential for all members of your team.

For any consequences described, a solution is NOT “and we will contact the instructors,” as this 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.”

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. However, for large, chronic problems, like missing deadlines, team members are encouraged and expected to reach out to their project leaders and discover and resolve the root cause of their issues. If a resolution cannot be found and the issue remains unsolved, report this in the two-week reports.

Submission

Due: Sat, Jan 27 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, we will check your Google Drive to verify that you have made these changes in the document and the date that they take effect.