Team Collaboration and Project Kickoff

Every successful software project begins long before the first line of production code is written. It begins with people agreeing on how they will work together, what they are building, and who is accountable for what. This module establishes the social and operational infrastructure of your team: the roles you will play, the norms you will hold each other to, the problem you intend to solve, and the tooling that lets you collaborate without stepping on each other's work. The artifacts you produce here — a team charter, a role matrix, a scope statement, and a configured shared repository — are not busywork. They are living documents that you will consult, amend, and be evaluated against for the remainder of the course.

Teams that skip this stage rarely fail immediately. They fail three weeks later, when two people have independently built conflicting versions of the same feature, when a deadline passes because everyone assumed someone else was handling it, or when a quiet team member's excellent idea never surfaced because there was no channel for it. The investment you make now is insurance against those predictable failures.

Forming Effective Project Teams

A cross-functional team is one whose members collectively possess all the skills needed to deliver the product end to end — design, implementation, testing, documentation, and stakeholder communication — rather than a team of specialists who must hand work off across organizational boundaries. Research on team performance consistently shows that diverse teams outperform homogeneous ones on complex, non-routine problems, precisely because the work benefits from being examined through multiple lenses. A developer looks at a login screen and thinks about token storage and error states; a designer looks at the same screen and thinks about affordances, contrast ratios, and what happens on a 375-pixel-wide phone. Neither perspective alone produces a good login screen.

Diversity here means more than academic background. It includes prior industry experience, cultural context, accessibility needs, and simply how people prefer to think — some teammates reason best out loud in a whiteboard session, others need to read a written spec and sit with it overnight. The cost of diversity is that communication takes more effort; the benefit is that blind spots get caught. Your job as a team is to capture the benefit while deliberately managing the cost.

Begin with a structured skills inventory. Rather than asking "what are you good at?" — a question that invites both bragging and false modesty — ask each member to rate themselves on concrete capabilities and, crucially, to state what they want to learn. A simple shared spreadsheet or Markdown table works well:

Two things immediately become visible in a table like this. First, the team has a coverage gap: nobody rates themselves strong in backend except Devin, which is a single point of failure. Second, there are growth pairings available — Amara wants API integration experience and Devin wants presentation practice, so pairing them on a feature demo serves both goals. A skills inventory is therefore not just a staffing document; it is the raw material for a deliberate learning plan.

The final piece of team formation is establishing shared expectations before work begins. Psychologists describe this as reducing ambiguity, and it is the single cheapest intervention available to a new team. Hold an explicit conversation covering questions such as:

• Availability: What hours does each person realistically work? Who has a job, a commute, caregiving duties, or a time zone offset?
• Response time: If I message the team channel at 9 p.m., should I expect an answer tonight or tomorrow morning? (Agree on a number — "within 24 hours on weekdays" is a real commitment; "pretty fast" is not.)
• Quality bar: Are we aiming for a polished portfolio piece or the minimum that satisfies the rubric? Both are legitimate; a mismatch between members is corrosive.
• Working style: Does the team prefer long synchronous sessions or short check-ins plus independent work?
• Conflict: How will we raise it when someone is unhappy — directly, through a designated facilitator, or in a scheduled retrospective?

It helps to expect the classic stages of group development: forming (polite, tentative), storming (friction as real preferences surface), norming (agreements settle), and performing (fluid, productive work). Knowing that storming is normal — not evidence that your team is broken — makes it far easier to move through it quickly.

Defining Team Roles and Responsibilities

A role is a named bundle of responsibilities with a single accountable owner. The value of naming roles is not bureaucracy; it is the elimination of the diffusion of responsibility effect, in which a task everyone could do ends up done by no one. When the build breaks at 11 p.m. before a demo, "the Build/Release Lead decides whether we roll back or hotfix" is an answer. "Someone should probably look at that" is not.

For a typical four-to-six person course project, the following roles cover the necessary ground:

Note that holding a role does not mean doing all the work in that area. The Design Lead does not draw every screen; they ensure every screen gets drawn to a consistent standard. This distinction is often clarified with a RACI matrix, which separates who is Responsible (does the work), Accountable (owns the outcome — exactly one person), Consulted (gives input before the decision), and Informed (told after):

These assignments must be documented in the repository, not merely agreed verbally. Create a file such as docs/TEAM.md so that any member, and the instructor, can resolve an ownership question in ten seconds without asking anyone:

# Team Roles — Project Lumen (Section 04)

| Member | Primary Role        | Secondary Role       | GitHub       | Preferred Contact |
|--------|---------------------|----------------------|--------------|-------------------|
| Amara  | Design Lead         | Documentation        | @amara-k     | Slack #lumen      |
| Devin  | Tech Lead           | Backend dev          | @dnwankwo    | Slack DM          |
| Priya  | Research Lead       | Project Manager      | @priya-s     | Slack #lumen      |
| Luis   | Build/Release + QA  | Frontend dev         | @luisr-dev   | Slack #lumen      |

## Rotation Schedule
- Project Manager role rotates each sprint (2 weeks):
  Sprint 1 Priya -> Sprint 2 Luis -> Sprint 3 Devin -> Sprint 4 Amara
- Every member must author at least one ADR and review at least six pull requests.

## Escalation Path
1. Raise in #lumen channel.
2. If unresolved in 24h, the role owner decides (see RACI in docs/RACI.md).
3. If the team is split on a scope question, escalate to the instructor at
   the weekly check-in.

Last updated: 2024-09-18 (PR #12)

Storing roles in the repository rather than a chat message means the document is version-controlled: you can see when roles changed and why, and updates go through the same pull request review as code. It also prevents the common failure in which the role assignment lives in a Google Doc that only two people can find.

Finally, consider which responsibilities should be shared or rotated. In a course setting, the learning objective competes with efficiency: the fastest path is to let the strongest coder write all the code, but that leaves three students without coding experience and one student exhausted. Effective compromises include rotating the Project Manager role each sprint (as above), requiring that every member authors at least one component and reviews a quota of pull requests, and using pair rotation so that the Design Lead pairs with a developer on implementation while a developer pairs with the Design Lead on a Figma component. Make the rotation explicit and calendared, or it will quietly not happen.

Creating the Team Charter

A team charter is a short written agreement — typically one to three pages — that records how the team will operate. Its real function is assumption surfacing. Every member arrives with an internal model of what "we'll meet regularly" or "we'll get it done on time" means, and those models differ far more than people expect. One student's "done" is a merged pull request with tests; another's is code that runs on their laptop. Writing the charter forces these private definitions into the open at a moment when disagreement is cheap, rather than at 2 a.m. before a deadline when it is expensive.

A workable charter covers at minimum:

• Purpose and success criteria: what the team is building and what "a good outcome" means for this group (a strong grade, a portfolio piece, a specific skill gained).
• Communication channels: which tool is used for what, and what the expected response time is for each.
• Meeting cadence: when the team meets synchronously, who runs the meeting, and what happens if someone cannot attend.
• Decision-making rules: consensus by default, with a named tie-breaker or a majority vote after a fixed time box.
• Definition of done and deadline norms: internal deadlines that sit before external ones, and what counts as complete work.
• Accountability and escalation: the agreed sequence of steps when a commitment is missed.
• Inclusion norms: explicit practices that ensure quieter members are heard.

Documenting communication channels deserves particular attention, because the most common way a team member gets excluded from a decision is not malice but channel fragmentation. Two teammates make a design decision over lunch, a third sees it in a pull request, and a fourth never hears about it at all. Prevent this by assigning a purpose to each channel and declaring one of them authoritative:

The last row encodes a rule worth stating outright: a decision made in a DM is not a decision until it is written in a public channel. This single norm eliminates most "I never heard about that" conflicts.

Norms around deadlines and accountability work best when they are specific and pre-agreed, because they then feel like applying a shared rule rather than a personal attack. A charter excerpt might read:

# Team Charter — Project Lumen

## 3. Deadlines
- Every task has an owner and a due date in the GitHub Project board.
- Internal deadlines are set 48 hours before any instructor deadline.
- "Done" means: merged to `main`, reviewed by one other member, passing CI,
  and the acceptance criteria in the issue are checked off.

## 4. Accountability Ladder
1. If you will miss a deadline, post in #lumen-general BEFORE the deadline
   with a new committed date. No penalty for an early heads-up.
2. Missed with no notice: the PM checks in privately within 24 hours.
3. Second missed deadline: raised at the retrospective; team reallocates work.
4. Third: the team notifies the instructor together, with a written record
   of steps 1-3.

## 5. Decision Making
- Default: consensus after everyone has spoken.
- Time box: 20 minutes of discussion. If unresolved, the role owner
  (see docs/TEAM.md) decides and records an ADR explaining the trade-off.
- Any member may request a re-vote once if new evidence appears.

## 6. Inclusion Norms
- Round-robin check-in at the start of each meeting; everyone speaks first
  before open discussion begins.
- Asynchronous written feedback window of 24 hours after every major decision,
  so members who think best in writing are not disadvantaged.
- No design or architecture decision is final until it appears in writing.

Signed: Amara, Devin, Priya, Luis — 2024-09-18

Two details make a charter effective in practice. First, everyone signs it — literally adding their name in the commit — which converts a document into a commitment. Second, it is revisited. Add "Does the charter still match how we actually work?" as a standing retrospective question; a charter that no longer describes reality is worse than none, because it teaches the team that written agreements are decorative.

Scoping the Course Project

Scope is the boundary around what you will and will not build. Student teams fail far more often from over-scoping than under-scoping: an ambitious idea consumes the entire term in design and arrives at the demo as a half-working prototype. Disciplined scoping is therefore a survival skill, and it starts with a problem statement.

A good problem statement describes a situation in the world that is unsatisfactory, for identifiable people, with evidence — and conspicuously avoids naming a solution. It anchors everything downstream: when someone proposes a feature, you test it by asking whether it moves the needle on the stated problem. A useful template is: [User group] needs a way to [accomplish goal] because [constraint or pain point], but currently [what goes wrong]. We know this matters because [evidence].

• Weak: "We're building a mobile app with a calendar and push notifications for students." (This is a solution and a feature list; it names no problem and no evidence.)
• Strong: "Commuter students at our university need a way to find unreserved quiet study space between classes, because they cannot return home during gaps and the library's open seating is fully occupied from 11 a.m. to 3 p.m. Today they wander between buildings, losing an average of 18 minutes per gap. In a survey of 42 commuters, 31 reported this happening at least three times a week."

The strong version is testable, bounded, and immediately suggests how you would measure success (reduce the time spent searching). It also leaves the solution space open — the answer might be an app, a sensor-driven occupancy map, a scheduling policy, or a simple shared spreadsheet.

Next, articulate user goals, which describe what a person is trying to achieve in their own life — not what your software does. This distinction is the difference between designing for outcomes and designing for features. A user goal is stated from the user's perspective, in the user's vocabulary, and would still be true if your product did not exist.

Expressing goals this way keeps multiple solutions on the table and gives you acceptance criteria that are meaningful to real people. The user-story format As a <role>, I want <capability>, so that <benefit> is a convenient scaffolding — but only if the "so that" clause names a genuine human benefit rather than restating the capability.

With a problem and goals in hand, bound the scope explicitly. The most effective technique is a two-column in scope / out of scope list plus a MoSCoW prioritization (Must, Should, Could, Won't). The "Won't have — this term" column is the most valuable one in the entire document, because it is what you point to when a teammate or stakeholder proposes an exciting new feature in week nine.

Scope should also be expressed in terms of constraints and assumptions, because these are the hidden drivers of feasibility: the number of weeks available, the total person-hours per week the team can realistically commit (be honest — four students at eight hours each is thirty-two hours, not a full-time engineering team), the technologies the course requires, the data you can legally obtain, and the accessibility standard you intend to meet. Writing "we assume the facilities office will share the room list as a CSV" exposes a risk you can validate in week two rather than discover in week eight.

Finally, review the scope with your instructor before investing in design. This is not a formality. The instructor sees every team's plan and knows from experience which ideas collapse under their own weight, which require data that will never be approved, and which fail to exercise the skills the course is assessing. A twenty-minute conversation at this stage can save two weeks of wasted wireframing. Come to that review with a one-page scope statement containing the problem statement, three to five user goals, the MoSCoW table, constraints and assumptions, and a list of open questions. Leave with written notes recorded in the repository — for example as docs/SCOPE.md with a changelog entry — so that any later scope change is visible as a diff rather than a vague memory of what was approved.

# Project Scope Statement — Project Lumen

## Problem
Commuter students need a way to find unreserved quiet study space between
classes, because they cannot return home during gaps and open seating is
full 11:00-15:00. Survey of 42 commuters: 31 report this 3+ times/week.

## Primary Users
Commuter undergraduates with 60-180 minute gaps between classes.

## User Goals
1. Find a quiet, free space within a 5-minute walk, right now.
2. Trust that the space will still be free on arrival.
3. Avoid walking into an occupied room.

## Success Measures
- Median search time drops from 18 min to under 5 min in usability testing.
- 8 of 10 test participants locate a usable room on the first attempt.

## Constraints
- 10 weeks; ~32 team-hours/week; React + Node required by course.
- No access to card-swipe data (privacy review not feasible this term).
- Must meet WCAG 2.1 AA.

## Assumptions (to validate by Week 2)
- Facilities will provide a room list as CSV.  [Owner: Priya]
- Crowd-sourced check-ins will reach useful density with ~30 pilot users.

## Open Questions for Instructor
- Is a seeded/simulated dataset acceptable if facilities data is delayed?

Reviewed with instructor: 2024-09-20. Approved with note: seeded data OK
for Sprint 1; must document the simulation clearly in the final report.

End-of-Module Readiness Checklist

The module concludes with a verification pass. The point of a readiness checklist is that each item is demonstrably true for every member — not "probably fine." The most common way a team loses a week is discovering in sprint one that one teammate's environment never worked, or that the Figma file is owned by a personal account nobody else can edit. Verify by producing an artifact, not by asking "everyone good?"

GitHub accounts and repository access. Each member needs an account added as a collaborator (or added to the organization team) with at least write permission, and each must prove access by pushing something. A reliable smoke test: every member creates a branch, adds their name and role to docs/TEAM.md, opens a pull request, and has it reviewed and merged by a teammate. That single exercise verifies account access, write permission, branch creation, the pull request workflow, review permissions, and merge rights all at once. Members should also confirm their authentication method works for the long term — an SSH key or a personal access token rather than a password — and that their commit email matches their GitHub account so contributions are attributed correctly.

# Verify identity and remote access
git config user.name            # should match your display name
git config user.email           # must match a verified GitHub email
ssh -T git@github.com           # "Hi username! You've successfully authenticated..."

# Smoke-test the collaboration workflow
git checkout -b chore/add-me-to-team-doc
# ...edit docs/TEAM.md...
git add docs/TEAM.md
git commit -m "docs: add Luis to team roles table"
git push -u origin chore/add-me-to-team-doc
# then open a PR on GitHub and request a review

While you are there, have the Build/Release Lead configure the repository itself: a branch protection rule on main requiring one approving review, a .gitignore appropriate to the stack, a README.md with setup instructions, a CONTRIBUTING.md describing branch naming and commit conventions, and issue/PR templates. A docs/ folder should hold TEAM.md, CHARTER.md, SCOPE.md, and a meetings/ directory.

Figma Education workspace. Each student should apply for the free Figma Education plan using their institutional email; approval can take time, so start early. The Design Lead creates a team (not a personal draft) named for the project, creates project files inside it, and invites every member by email with at least "can edit" rights. Verification is behavioral: every member opens the file, creates a frame or leaves a comment, and confirms it appears for the others. The critical failure to avoid is designing in a personal "Drafts" space — files there are not shared with the team, cannot be recovered by teammates if the owner's access lapses, and will not appear in the team's version history. Agree now on a file structure (for example, separate pages for Research, Wireframes, Components, and High-Fidelity screens) and link the Figma URL from the repository README so there is one discoverable source of truth.

Local development environments. "It works on my machine" is a project-management failure, not a joke. Every member must install the required runtime and tooling at the pinned versions, clone the repository, install dependencies, run the application, and run the test suite successfully. Pin versions explicitly — an .nvmrc file, an engines field in package.json, or a containerized dev environment removes an entire class of mysterious bugs. The smoke test is that each member pastes their version output into the team channel or a checklist issue:

git clone git@github.com:lumen-team/lumen.git
cd lumen
nvm use                 # reads .nvmrc -> v20.11.0
npm ci                  # install exact locked dependency versions
npm run dev             # app serves at http://localhost:5173
npm test                # all tests pass

# Paste this output into issue #3 "Environment smoke test"
node -v && npm -v && git --version

Record any platform-specific gotchas (Windows line endings, missing build tools, Apple Silicon differences) in the README as you hit them — the next person to set up, including a future teammate or the instructor, will need them.

Charter and scope documented in the repository. Both documents must be committed to the repo, merged into main via pull request, linked from the README, and signed or acknowledged by all members. Storing them alongside the code means they are version-controlled, diffable, reviewable, and impossible to lose in a chat history.

A compact team-level checklist makes the state of readiness visible at a glance:

When every row reads complete, the team has more than paperwork: it has a shared vision of the problem, named owners for every decision, agreed rules for how disagreements get resolved, and infrastructure that lets four people change the same codebase and the same design file without destroying each other's work. That is the real deliverable of this module — and every subsequent module assumes it is in place.