knowledge-kitchen / scrum

Team Norms

• Definition of done
• Sprint cadence
• Daily standups
• Coding standards
• Honesty and accountability
• Dealing with problemmatic teammates
• Concluding thoughts

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

• Indicate the set of coding conventinons the team will follow.
• 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 single-line 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).

Honesty and accountability

All teams must include in their norms that team members agree to inform the entire team of any difficulty completing their work when answering the three questions in daily standup meetings. If a team member is blocked on a task, they must ask for help.

Dealing with problemmatic teammates

Your team must have an agreed-upon set of steps for dealing with conflict. Among other things, this must include what steps everyone agrees to take when a teammate is not participating in the project in any meaningful way and/or not showing up to meetings.

In other words, discuss as a team how you will deal with this. If someone isn’t showing up to two or more meetings in a row and not participating in any meaningful way, my suggestion is that you all agree as a team on the following, and document it in your Team Norms:

1. the team will first try to address the issue with the problematic teammate immediately…. a best effort will be made to get in touch with the problematic member, let them know that they are creating a problem for the rest, and resolve the issue internally.

2. if the situation is not resolved before the next standup meeting, the team agrees that…

   • this will be reported to the project management (i.e. us admins);

   • other teammates will take over the problematic teammates responsibilities;

   • a best effort will be made to keep the problematic teammate informed of what is going on in the project by posting regular standup notes and other updates to Discord.

   • if the problematic teammate attempts to become more involved with the project at a later date, the team will make a best effort to help him/her do so.

   • in no case will the team sit around and wait more than 2 standup meetings for a non-participating teammate to complete his/her tasks.

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.