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.
Describe at least:
What are the key strengths of each person on the team?
-
Benjamin Carter
- Conceptualizing and project organization, project management, and Kitten Management
-
Bishal Khanal
- Critical Thinking and research
-
Katrina 'Lil Hurr' Hill
- Research and time management
-
Roger Wells
- Conceptualizing and project organization, Collaboration and team cohesion
-
Matt Rangel
- Project management, problem solving, and time management.
How can you best utilize these strengths in the execution of your project?
Assign responsibilities with the goal of mutual improvement and promotes excitement. We will pair partners strength with partners weakness for strong learning opportunities.
In which professional competencies do you each want to develop greater strength?
- Benjamin Carter
- Get better at decisiveness and putting forth motion in ideas to solidify said ideas.
- Bishal Khanal
- Get better at UI development and time management
- Katrina 'Lil Hurr' Hill
- Conceptualizing and implementing code with front-end specifically.
- Roger Wells
- Get better at time boxing. Account for breaks. Improving react performance
- Matt Rangel
- Getting faster in developing frameworks
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?
- Morning, afternoon, and evening stand ups
- Pull and merge at those moments
- Make it open to help people get unstuck
- check for understanding and reassign priorities
- Peer program or mob program as necessary
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.
Describe at least:
What will be your group’s process to resolve conflict, when it arises?
Everyone is an adult, if there is a conflict that usually means that something is lacking in understanding of scope. So we will work to identify the root cause of the conflict and resolve it in good faith. If it doesn't get resolved within the group, then we will reach out to JB.
What will your team do if one person is taking over the project and not letting the other members contribute?
Tell Ben to take a break.(kidding, not kidding)
Do a lot of pair programming, and switch often. If someone is not contributing enough, we will acknowledge it and make moves to help contributions.
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?
If someone is not understanding the portion of the project, as a team we all try to bring that person on board, and make sure that person has a good understanding of the scope at hand.
How will you raise concerns to members who are not adequately contributing?
Look at the PRs at the stand ups and work to keep all the contributions leveled.
How and when will you escalate the conflict if your resolution attempts are unsuccessful?
If all resolution attempts are unsuccessful, bring in third party (TA or JB) This will be brought up if we spent more than a reasonable amount of time in trying to pull vision together.
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.
Describe at least:
What hours will you be available to communicate?
Tue-Fri 9 a.m. - 6 p.m.
-
Ben: Available anytime on Slack from 9 - 6
-
Bishal: Available anytime on Slack from 9 - 6
-
Katrina: Available anytime on Slack from 9 - 6
-
Roger: Available anytime on Slack from 9 - 6
-
Matt: Available anytime on Slack from 9 - 6
-
Within standard working hours expect to respond within 30 minutes maximum. We will tell the group if any one of us needs additional time away from the project.
-
Outside of standard working hours, no communication is required
What platforms will you use to communicate (ie. Slack, phone …)?
- Slack, Remo, and Zoom as necessary
How often will you take breaks?
- 10 minute break every 1 hour, but this can be flexible: break as needed
- Flexible lunch hour at noon - 1 PM
What is your plan if you start to fall behind?
- Regroup and reassess features, possibly narrow scope
How will you communicate after hours and on the weekend?
- Slack, as needed
- Response not required
What is your strategy for ensuring everyone’s voice is heard?
- Morning, afternoon, Evening stand ups, touch with everyone
- Start with something unrelated to loosen up and create an open space, fostering an environment where everyone feels comfortable.
- Be sure to ask questions
How will you ensure that you are creating a safe environment where everyone feels comfortable speaking up?
- By fostering an environment where everyone feels comfortable, doing this by starting the morning stand up with something unrelated to the 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.
- Reference organization contributions charts, and base driver and navigator off of that. This will ensure leveling contributions across the team.
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.
Describe at least:
How you will identify tasks, assign tasks, know when they are complete, and manage work in general?
- We will start off with those who want more experience in creating frameworks quicker and then switch often to get equal contributions in github.
What project management tool will be used?
- Use Jira as a project management tool.
Make a single copy of the Presentation Deck Template. Share your copy will all team members, so everyone is working from the same file.
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.
Do a presentation run-through Thursday night and Friday before presentations
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.
Describe at least:
- Each feature gets its own branch
- Each branch named feature-driver initials
- Make sure to pull before ever touching code, whoever is pushing the other pair pulls
- Don't merge your own pull request
- Two people need to sign off on push
- Have a Dev branch for staging
- Once we have MVP we push to main
What components of your project will live on GitHub?
- Everything: Documents, Wireframe, Front-End, Back-End
How will you share the repository with your teammates?
- Organization on GitHub with projects board
What is your Git flow?
- Features get branches
- Pull every morning
- Push on consensus to staging branch
- Majority consensus is acceptable
- Merges done as a group
Will you be using a PR review workflow? If so, consider: How many people must review a PR?
- 2
Who merges PRs?
- The other pair that did not create feature
How often will you merge?
- At least twice per day per pair, as necessary
How will you communicate that it’s time to merge?
- Slack, Remo or Zoom