Review & update Working Agreement

[atxryan]

Type of PR

• Documentation changes
• Code changes
• Test changes
• CI-CD changes
• GitHub Template changes

PR Checklist

• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.
• My code follows the code style of this project.
• I ran lint checks locally prior to submission.
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Purpose of PR

Review and update Working Agreement.

Does this introduce a breaking change

• YES
• NO

Validation

• Unit tests updated and ran successfully
• Update documentation or issue referenced above

Issues Closed or Referenced

• Closes #issue_number (this will automatically close the issue when the PR closes)
• References #issue_number (this references the issue but does not close with PR)

[atxryan]

I think it makes sense to move the Engineering details to the EngineeringPractices.md file. I suggest keeping the Working Agreement broadly focused on people, culture, and communication while Engineering Practices can include details about team agreements on tech styles and policies.

[atxryan]

Do we want to rotate Scrum Master weekly?

[Zeriet]

Not sure on that, that could be a good discussion for the offsite meeting though.

[Zeriet]

Thanks @atxryan, some additional points that could be up for discussion:

Conflict resolution:
Defining a process for resolving conflicts within the team.

Inclusion and diversity:
Determining how the team can actively promote diversity and inclusion.

Customer Feedback:
Implementing a regular process for gathering and incorporating customer feedback into the development cycle.

[atxryan]

I also asked ChatGPT to analyze the Working Agreement and offer suggestions for improvement and additions. Let's discuss these at the offsite.

[TBunkley]

@atxryan I think it would be a good idea to comment on leveraging something like codespaces as a good engineering practice. Developers can lose alot of time on configuration / setup tasks and codespace can optimize it.

[TBunkley]

We also may want to add something about committing code frequently to our work branches. We can emphasize it's more about saving the current state of your code vs a meter for mgmt to check for progress.

[TBunkley]

Should we add something dev environment consistency? Here is a suggestion.

Suggested change

	### Development Environment Onboarding Consistency
	- To promote consistency and reduce onboarding time, Github Codespaces should be preferred.
	- The codespace should be maintained by the engineering team.