proj02_mentors : Mentor Duties for proj02
num | ready? | description | assigned | due |
---|---|---|---|---|
proj02_mentors | true | Mentor Duties for proj02 | Thu 11/15 05:00PM | Thu 11/15 07:50PM |
Checklist before lab
Here’s a checklist of things that should have been done by either you, or your team, based on the instructions from the proj01 and proj01_mentors:
- Is there a repo under the organization ucsb-cs56-webapps for your team’s project?
- Did your team fork that repo to ucsb-cs56-f18?
- Did they create a Kanban board for their project in the forked repo under ucsb-cs56-f18?
- Is every single member of the team listed by their github id as a collaborator on the forked repo under ucsb-cs56-f18?
- Are there at least one user story on the Kanban board?
- Are there at least a few issues under the user stories?
- Are those issues approved by you, and estimated with points?
- If you have questions or doubts about approving the issues or estimating the points, please speak up on the Slack, or come in person to one of the TAs or the instructor, or to a mentor with more experience in the course.
- Is each member of the team assigned to at least one story?
During lab on Thu, Nov 15, 18
Step 1: Agile Standup
The group should hold an Agile Standup.
Record who was present for the start of the Standup (for now on a piece of paper; I’ll tell you in a minute where to record this online).
Your role in the standup is only to help guide making sure that it happens; the students should self-organize and run the standup. You can gently guide them though, and remind them of what a standup is supposed to accomplish (this list comes from an article by Martin Fowler)
Here’s what a standup is for:
- Share understanding of goals. Even if we thought we understood each other at the start (which we probably didn’t), our understanding drifts, as does the context within which we’re operating. A “team” where each team member is working toward different goals tends to be ineffective.
- Coordinate efforts If the work doesn’t need to be coordinated, you don’t need a team. Conversely, if you have a team, I assume the work requires coordination. Poor coordination amongst team members tends to lead to poor outcomes.
- Share problems and improvements. One of the primary benefits of a team versus working alone, is that team members can help each other when someone encounters a problem or discovers a better way of doing something. A “team” where team members are not comfortable sharing problems and/or do not help each other tends to be ineffective
- Identify as a team It is very difficult to psychologically identify with a group if you don’t regularly engage with the group. You will not develop a strong sense of relatedness even if you believe them to be capable and pursuing the same goals.