- The team owns the project. There are many kinds of work to be done, and any
work can be done by any team member. You are authorized to contribute in any
way to the project. Some people will tend to work on particular aspects of
the game, but that is by choice, not as a rule.
- We foster T-shaped
skills, such that all team
members share core competencies, and individual team members provide depth
in particular areas.
- Each team formulates a mission statement. This is one or two sentences that
describe the goal of the project.
- The primary purpose of the mission statement is to allow the team to say
“no” to good ideas.
- Use Slack for studio and team communication.
- The
#general and #random channels are available for studio-wide communication.
- Each team sets up its own channels as needed, giving each a recognizable
prefix corresponding to the project.
- We start each production day with a 4PM “daily standup” meeting,
during which each member reports on the following to their team:
- What did you contribute since last time?
- What do you plan to accomplish before next time?
- Are there any impediments?
Note that impediments are obstacles that stand in the way of your goals
but that can be removed or worked around. They are never excuses for failing
to meet commitments.
If a team member is unable to attend a meeting, they must post to the
#general channel on Slack.
- Each team designates one team member as producer.
- The producer role may change at any time by majority vote of the team,
although it is preferable to keep the role for an entire iteration.
- The producer’s primary role is to remove impediments to the team’s progress.
- The producer’s secondary role is to communicate progress to the project
mentor in his capacity as executive producer.
- The producer or their designate gives an informal update to the executive
producer on each production day.
-
The team will track its plan on HacknPlan.
- Each board will have the following top-level lists:
- Not Yet Started for work items that are part of the sprint but have not yet been started;
- In Progress for work items that are currently being completed;
- Needs Validation for work that is complete to the best ability of those working on it, but which has not yet been reviewed by the team or corresponding lead;
- Done for work that is done.
- Optionally, a Backlog, which contains work items that are not part
of the current sprint but may be picked up in the future.
- Each card in a list represents a “work item”, most of which are features expressed
from the player’s perspective.
- Include, clearly and consistenly on each card, the total number of
hours estimated remaining to complete it.
- Non-atomic work items use named checklists to track the tasks necessary
to complete a feature.
- Team members are assigned to features when they commit to working on them.
- These team members are responsible for ensuring that the feature is
completed. This does not mean that they have to be the ones to do all
the work, but it does mean that they should always know the state of
the feature.
- After every work session, each team member updates the number of hours
estimated remaining on the features they have touched. Note that estimates
may increase, decrease, or remain the same.
- A feature that is complete to the working group’s satisfaction is moved
to Needs Validation, with its estimate updated to be the time for
validation. The nature of validation is task-dependent, but
frequently-used methods include code review and playtesting.
- A feature that has been validated and has no hours remaining on it
should be moved to Done.
- The producer maintains a burndown chart, which plots time against the
estimated hours of work remaining. The chart is updated after each planning
and standup meeting.
- The burndown chart may be kept on paper or digitally.
- It should be referenced during or before stand-up meetings in order to
provide feedback to the team about what they have learned and accomplished
during the iteration.
- The burndown chart, if maintained on Google Sheets, can be
integrated into HacknPlan.
- All team members maintain effort only on tasks that are part of the current
release.
- Corollary: Solve the problems you have, not the problems you might have later.
-
Every team member has Stop Work Authority. This means that if you witness
something that impacts the safety of the team, you may signal for the team to
stop work. The team then redirects their attention to the safety issue.
-
If a team member has a conflict with another team member, he or she should
talk to that individual about it privately first, face-to-face. If a
resolution is not met, the issue should be brought to the project mentor.
- When faced with a design conflict (including software architecture,
implementation details, user interface design, and game design) where two or
more team members disagree, monitor the amount of time spent on the
discussion. If a resolution is not found within five minutes, take one of the
following options:
- Invite the project mentor for a consultation.
- Get a volunteer for each side. Schedule a follow-up meeting, with all
relevant stakeholders, at which time each volunteer will be expected to
demonstrate prototypes to defend their positions. After this, the
stakeholders vote on which direction to pursue.
-
Prefer working in pairs whenever possible, particularly on technical and
integration tasks. Rotate pairs at least once a week to ensure that knowledge
is distributed across the team.
- Each team chooses a version control system and follows the conventions for that
system.