Team Norms

Teams are well-advised to agree upon a written set of norms and rules upon team formation. These are commitments team members make to each other. Some common types of norms are outlined below.

Teams are ideally co-located in the same room or space while they work for fast interactions and rapid team building

…or work harder to make sure collaboration takes place with dedicated chat rooms, video conferencing, lots of conference calls
ideal size is debatable. Some say 7 members +/- 2… who are these people and what do they know?
build a team that has broad knowledge across several areas and deep knowledge in specific areas
establish Team Norms early

Team values

Important agreements so that everyone knows what is expected of them in terms of responsibility.

how the team will work together.
how members who need help will solicit it from the others.
how the team will resolve conflicts.
- how they’ll reach consensus when there are disagreements on direction.
- what to do when a member is failing to deliver on their obligations to the team.
- how quickly team members are expected to respond to messages directed at them.

Sprint cadence

how much time should a sprint take?
usually anywhere from 1-4 weeks long, preferably on the shorter side.
too short sprints create panic and stress.
too long creates overly relaxed mood.
just right is in the middle… in our case 2 weeks.

Daily standups

what days/times will standups occur and how long do they last.
members expected to be present synchronously.
agreement that members will not cover for other members who do not participate.
agreement that a member who makes no progress on a task for two standups or more in a row will be reported to management.

Coding standards

Designate a code editor and code linter all team members will use to standardize code formatting.
Don’t over-engineer. Write minimum code to get things working end to end, only then iterate to improve.
Code for each task and spike must be peer-reviewed and pass tests before merging into the main/master branch of code.
Always push working code, if you break the pipeline/build then fix it.
Make granular and small commits, per feature or per bug fix.
Provide descriptive commit messages.
Write self documenting code. Use descriptive variable and function names. Avoid unnecessary name shortening.
Don’t leave dead/commented out code behind. If you see such code, delete it.
Write automated tests to cover critical integration points and functionality (once you learn how to do that).

Concluding thoughts

Keep this document practical and real - make it yours, not someone else’s. Please don’t write in things you know your team is not going to do or care about just because you see other people doing that online. Team norms reflect your team’s personality and values.