-
Notifications
You must be signed in to change notification settings - Fork 0
Team Agreement
Kyle Aleman, Johnny Backus, Xin Deng, Brendan Huddleston
Every person on your team is an asset. This is your chance to discover the hidden strengths and areas for growth for each team member.
- What are the key strengths of each person on the team?
- Johnny: Equally bad at all aspects of coding, but reasonably good at reading docs and learning API req’s.
- Kyle: Efficient reading of code and breaking down logic
- Brendan: CSS, Work ethic
- Xin: Turns in things, also equally bad at coding here, can help with syntax check
- How can you best utilize these strengths in the execution of your project?
- To optimize the team's performance in the project, Johnny's general coding skills can be used for tasks that require basic coding knowledge, while Brendan’s proficiency in CSS can be applied to front-end development, and his strong work ethic ensures commitment to tasks. Kyle’s ability to read code and breakdown logic would also be helpful in catching errors in our app functionality. Xin's reliability in meeting deadlines should be utilized for maintaining project timelines.
-
In which professional competencies do you each want to develop greater strength?
- Johnny: Craft Competency: Technical
- Kyle: Networking
- Brendan: Writing and Speaking clearly.
- Xin: The Teamwork Competency: Collaboration
-
Knowing that every person in your team needs to understand all aspects of the project, how do you plan to approach the day-to-day work?
- NOTE: Undoing, Redoing, Replacing, or otherwise steamrolling the project as an individual is considered to be unacceptable. Account for the inevitable divergence of ideas, execution tasks, and assignments of duties here.
- Clear Project Overview
- Document the project
- Regular team meetings
- Collaborative Tools and Documentation
- Use Project management tools
- Task Distribution
- Define roles and responsibilities
- Encourage Questions and Discussions
- Open communication on slack
- Constructive Feedback
Your team should agree on a process for handing disagreements, should they arise. It is better to have a plan in place ahead of time so you can all refer back to it when necessary.
-
What will be your group’s process to resolve conflict, when it arises?
- Open Communication: We will encourage open and honest communication within the team. Team members should feel comfortable expressing their concerns, ideas, and disagreements.
- Identify the Issue: When a conflict arises, we will work together to clearly identify the specific issue or disagreement. It's important to understand the root cause of the conflict.
- Discussion and Resolution: The team will engage in a constructive discussion to find a solution. All team members will have the opportunity to share their perspectives, and we will seek a resolution that takes into account everyone's input.
- Consensus or Compromise: We will strive to reach a consensus whenever possible. If a consensus is not achievable, we will consider compromise, making sure all team members are comfortable with the solution.
- Documentation: We will document the agreed-upon resolution and ensure that everyone understands their roles and responsibilities moving forward.
-
What will your team do if one person is taking over the project and not letting the other members contribute?
- If one team member is taking over the project and not allowing others to contribute, we will address this issue promptly.
- The team will hold a discussion, reminding everyone of the importance of equal contributions and collaboration.
- We will encourage the dominant member to listen actively to other team members' ideas and feedback.
- If the issue persists, we will involve a TA or course instructor to mediate and ensure fair participation.
-
How will you approach each other and the challenges of the project knowing that it is impossible for all members to be at the exact same place in understanding and skill level?
- We understand that team members may have different levels of understanding and skill. We will approach this diversity as an opportunity for learning and growth.
- We will promote a process by which more experienced members can assist those who may need additional support.
-
How will you raise concerns to members who are not adequately contributing?
- If a team member is not adequately contributing to the project, we will address the issue privately and respectfully.
- We will discuss expectations and workload distribution.
- If the issue persists, we will escalate the issue to a TA or course instructor.
-
How and when will you escalate the conflict if your resolution attempts are unsuccessful?
- If attempts to resolve conflicts internally are unsuccessful, we will escalate the matter to a TA or course instructor.
Before beginning to tackle the project, determine how your group will communicate with each other. This is not an individual effort. Make sure everyone feels comfortable with the identified methods of speaking up.
-
What hours will you be available to communicate?
- 9am-6pm(possibly later) PST
-
What platforms will you use to communicate (ie. Slack, phone …)?
- Slack
-
How often will you take breaks?
- As needed
-
What is your plan if you start to fall behind?
- The team is in agreement if extra hours are needed we will commit more time and not be afraid of asking for help.
-
How will you communicate after hours and on the weekend?
- In agreement that it’s fine to text after-hours/weekend but also accept the fact you might not receive a response until following business day/hours
-
What is your strategy for ensuring everyone’s voice is heard?
- Be respectful whenever a team member is speaking and do not talk over them.
-
How will you ensure that you are creating a safe environment where everyone feels comfortable speaking up?
- Be respectful, act professionally, and clearly communicate that this is a team effort and everyone’s opinion is essential to the success of this project.
Explain your work plan to track whether everyone is contributing equally to all parts of the project, and that each person is working on “meaty” problems. This should prevent “lone wolf” efforts and “siloed” efforts.
NOTE: While researching and experimentation is always encouraged, writing and/or committing code to the project on your own during non-working hours or over the weekend is never acceptable. This puts the entire project at risk. Be explicit in calling out your work hours and the distribution of tasks.
- How you will identify tasks, assign tasks, know when they are complete, and manage work in general?
- At the start of the week we will lay out the goal of the project and create a backlog of tasks, every morning we will assess the tasks in the backlog and consider adding more. From there the team will discuss what tasks to accomplish by EoD and who will work on what.
- What project management tool will be used?
- Trello: Kanban Board
Make a single copy of the Presentation Deck Template. Share your copy will all team members, so everyone is working from the same file.
Link to the shared doc in your project plan: Presentation Deck
Schedule your practice session
Work with your instructor to pre-schedule an date and time for your “practice run” of your presentation. This should either be an exact time, or a short window of time designated by your instructor. Plan for a 30-45 minute meeting during the class session before your actual presentation to allow time for both your practice run and feedback from the instructional team.
Reminder as you work on and practice your presentations:
Expressions of gratitude should be heartfelt. When not presenting, team members should make strong eye contact with the “audience” / camera. Be positive, no matter how tired or burned out you may feel … “Your smiles can be heard over the phone”
Plan out what your team’s Git workflow looks like for coding tasks.
-
What components of your project will live on GitHub?
- README - Team Agreement
- README - Project Description
- HTML
- JS
- Configs
- CSS
- Bootstrap
- React
-
How will you share the repository with your teammates?
- Clone
-
What is your Git flow?
- Branch
-
Will you be using a PR review workflow? If so, consider:
-
How many people must review a PR?
- At least one other person
-
Who merges PRs?
-Anyone can merge
-
How often will you merge?
- Whenever we get a working code.
-
How will you communicate that it’s time to merge?
- During project time in remo, if not in remo than slack
-