Team Norms

Teams are often advised to negotiate and 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 team size is debatable. Some say 7 members +/- 2… But 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

Definition of done

What does it mean for a task to be considered truly done? Document the answer to ensure all teammates have an agreed-upon understanding of what is expected of them when completing work.

Typically, these would include ensuring that…

all code is written according to th team’s coding conventions and standards
unit tests have been written for all new code
all code has been thoroughly tested
all code has been peer-reviewed
all code has been merged into the main branch
all documentation has been updated

Not all of these will be relevant to all teams. Do not document things that you do not plan to do.

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.