• Project Management Tool
• Futbol Repo
• DTR
• Retro Board
• Presentation

List each group member’s name and link to their LinkedIn and Github profiles.

• Quin Nordmark
  • Github
  • LinkedIn
• Meg Roth
  • Github
  • LinkedIn
• Stephen Nash
  • Github
  • LinkedIn
• Logan Finnegan
  • Github
  • LinkedIn

• We will meet again on Thursday and Sunday.

• We will have daily Slack communication.
• Daily check-ins during class time

• Project Management Tool
• We will make sure to write the excel sheet first, followed by the test methods, followed by the code, followed by merging.
• If we follow this process, our code should not impact/block each other's code because we'll be all on the same page without having to directly compare non-spec code.
• Co-author commiting (note: we later decided against doing this after our first check-in with Kat)

• Meg proposed a format in excel that the team liked.
• Filling in the Excel before working on code will prevent overlap.
• No one had experience with the alternative project management tools that were suggested in iteration 1.
• Decided to go with Excel for ease of use, quick setup (no configuration required), full flexibility, and ability to view the status of everything on one page.

• Red -> Green -> Refractor (test then code then improve)
• Start with main class and then branch and refactor as appropriate
• Use the excel sheet to track overall code design, with variables and methods documented in each class. Start with what we know and update as we go.

Retro Board

• Despite initial difficult team dynamics, we were able to pull it together and work more closely as a team in the end. This required compromise, patience, and understanding from everyone on the team.
• Documentation of next steps, team goals, decisions, deadlines, meeting recaps, etc. were helpful in keeping the team aligned and in agreement. Posting these to slack allowed us to keep a record of everything internally.
• We did a great job of communicating scheduling constraints and coordinating around each other's schedules. Our team is located in 3 different time zones, so we proactively communicated about this, which allowed it to flow seamlessly.

• Implement a code review process earlier on and have clearer chunks of functionality for PRs.
• Send calendar invites in advance with scheduled meeting times to ensure we're all on the same page for when we're meeting (especially with being in different time zones).
• At the beginning we could have gotten a stronger base of code before breaking out individually. It was more difficult to align after we had already taken different directions.
• Also, using TDD more effectively and in pairs would have reduced misunderstandings.