Team Agreement in Software Engineering

Team Agreement is a Team constitution, so draft it carefully and follow it religiously

What is a Team Agreement?

To understand the concept in a better way, let's go into the past and look at the waterfall project delivery model. In waterfall methodology, teams are formed to deliver a particular software project, and post-project the delivery team members are dispersed into other projects. Fast forward to the current world where projects are delivered in an Agile framework, where a team is formed to support a set of applications, features and to deliver the enhancements. Most importantly, team members may stay in the same team for a longer time. The universal fact is every person is different and unique, and the same applies in the team. They’re going to have their unique style of development, their habit of delivering a task. However, for a team to be successful every team member should work together, coordinate, communicate, and adhere to some team-level statement that they have agreed to follow. This team-level statement that outlines team-level standards is called Team Agreement.

Why Team Agreement is important?

To understand its importance let's take a few examples:

1. Imagine a case where every engineer is using their code styling format when programming, an application is going to have multiple code styling formats and regular conflict to change code styling before review.
2. Another case where the team does not have a definition of done would result in a chaotic story demo and confusion for the product owner about whether or not to accept a story. I could go on with several more examples, but I guess you got my point, Team Agreement could help to reduce team friction, promote a standard work process, and helps new team member to understand what is team's way of working.

Crafting Team Agreement

As with any other process document no team can get team agreement perfect on their first attempt, hence it's going to be a continuous process and it should be visited regularly (at least quarterly) to make sure team agreement still make sense. A few tips to craft the best team agreement:

1. Never assume quite obvious things, as not everyone has the same level of understanding. Something that could be quite obvious to someone may not be intuitive to others.
2. Consider team agreement as the constitution of a team, so draft it carefully and follow it religiously
3. The Tech Lead or Product Owner or Scrum Master can take the lead in drafting the team agreement, however, every team member should contribute because it is for the complete team.

1. Daily Standup
 a. What time?
 b. What will be discuss?
 c. How to utilize remaining time?
2. Story Refinement
 a. Story template to use?
 b. Definition of ready?
3. Feature Refinement
 a. Feature template to use?
 b. Definition of feature ready?
4. Sprint Planning
 a. Team velocity?
5. Sprint Retrospective
 a. Who will run the retro?
6. Sprint Demo/Review
 a. Definition of Done?
7. Development Branching Strategy
 a. Git or GitHub or truck base?
8. Pull Request (PR) Agreement
 a. Use a PR template?
9. Coding Agreement
 a. Use properly linting/styling?

Team Agreement Sample

Here you go, a sample team agreement.

1. Standup
 - Daily at 8:00-8:30 AM
 - First 15 mins for update, next 15 mins for blocker, demo
 - Start with update, task for today and blocker
2. Story Refinement
 - Weekly on Monday at 10:00 AM
 - Use story template to create new story
 - Definition of ready
   - Story is estimated
   - No open question 
   - All dependencies and risk are resolved
   - Acceptance criteria is well defined
3. Feature Refinement
 - Biweekly on Tuesday at 10:00 AM
 - Definition of feature ready
   - feature acceptance criteria is well defined 
   - No open question 
   - All dependencies and risk are resolved
4. Sprint Planning
 - Consider average team velocity to take total story points 
 - Account any upcoming holidays 
5. Sprint Retrospective
 - Who will run the retro
 - Everyone should contribute 
 - Look at the last retro action items
 - Every action item has owner
6. Sprint Demo/Review
 - Definition of Done
   - Evidence is attached as proof for story completion 
   - Story is marked as completed
7. Development Branching Strategy
 - Git or GitHub or truck base
8. Pull Request (PR) Agreement
 - Use a PR template
 - Follow naming convention when opening PR
 - Address all review comments 
9. Coding Agreement
 - Use properly linting/styling

If you have reached here, then I did a satisfactory effort to keep you reading. Please be kind to leave any comments or ask for any corrections.

My Other Blogs:

• Avoid Spring RestTemplate Default Implementation to Prevent Performance Impact
• My firsthand experience with web component - learnings and limitations
• Streaming logs of all pods at once
• Certified Kubernetes Application Developer (CKAD) Exam Tips