Teams and Groups in CS 304¶

A lot of your work in CS 304 will not be solo work, but the group/team work comes in different varieties.

Announcements¶

• Grading Status

Highlights of the reading:¶

• two dimensions: performance vs learning and heterogeneous versus homogeneous
• two combinations for CS 304
  • pair programming on some assignments
  • heterogeneous groups for project work
• Take-away:
  • on pair assignments, I'd like you to work together,
  • on the project, I encourage you to divide-and-conquer

Why Group Work?¶

• better projects
• group skills

Ambitious Projects versus MVP¶

• Students can differ on how ambitious they want to be.
  • Some want to go "above and beyond"
  • Others want a "minimum viable product"
• Either is okay.
  • An MVP project can get an A. It doesn't mean you are aiming for a C and it doesn't mean you are a slacker. You just have other priorities.
  • But the project is often exciting and engaging, and groups often want to make it really great.

Some notes:

• It's helpful when the group is "on the same page" with respect to ambition. Not required, but helpful.
• An ambitious subset of the group (or a single ambitious person) can add an extra feature or do an exceptional job on the ones they have.
• You might discuss this with your teammates

Team / Group Norms¶

It's a good idea to establish some group norms:

• How will you discuss things? Turn-taking or everyone chiming in?
• How will you decide things? Unanimous consent? Vote? Benevolent dictatorship?
• How will you handle disagreement?

I took a workshop this summer on improving the inclusivity of organizations (among other worthy goals). They had a bunch of norms and protocols that can be a little cumbersome, but have some good effects.

• Chiming in, versus giving everyone a chance to speak, can inadvertently silence people.
• Don't interrupt, even with a friendly question; let people finish.

They actually used a formal "talking token" that was passed around, and each person had a minimum amount of time (e.g. 1-2 minutes).

I'm not saying you have to do that.

Their suggested norms

• Listen with the possibility of being changed and speak with the promise of being heard.
• Be present and be your best self
• Everyone has something to learn
• Everyone has expertise to offer
• We need each other
• You have a duty to assist
• Be willing to experience discomfort
• Expect and accept non-closure

I hope the last two won't be relevant, but the others will

Team Norms¶

For the pair programming, it's often the case that one person is a bit ahead of the other. Sometimes a lot, usually a little. Indeed, it would be quite a coincidence if two people were exactly at the same level with the material.

Nevertheless:

• Everyone has something to learn
• Everyone has expertise to offer

I'm honestly not worried about this, but it's good to be reminded.

Project Group Norms¶

Please think about the norms you want and discuss with your group.

Project Team Discussion¶

• how will we make decisions?
• when will we meet?
• what are our expectations of attendance, punctuality, etc?
• what kind of app do we want to build as a team?
• how ambitious do we want to be?
• start drafting a P1 Proposal