Team Norms

Logistical/ Behavioral Team Norms

POD MISSION : A simple statement of values and principles

• Who are we?
• What is the purpose of the POD?
• Achievable Goals

TEAM WORKING AGREEMENT aka TEAM NORMS :To establish expectations we have of each other and eliminate assumptions

• To treat each other with respect
• Team location and timezone - this is beneficial to understand where each team member works from (Core Team Hours)
• Flexibility among each other - work/life balance, change, etc
• Use team calendar to share PTO/ Time off, etc for visiblity - ensure invite says "Free" for team members' calendars
• To allow others to have a voice - to keep an open mind with each other
• To allow ourselves to have accountability – committing to stories/work each sprint,
• Allow ourselves to learn from mistakes - understand the why's and be open to constructive feedback and share wins and losses together as a team
• For new members, how are we onboarding the new hire? Buddy system? Tech scrum? KT sessions?
• To have fun together as a team – it’s essential to take time and get to know each other outside of work to further build a stronger relationship as a team
• We say that no idea is a bad idea; bring it up to the team and we can discuss the idea further (not just during a meeting)
  • Do we see any anti-patterns within the team?
• We will use the scouting rule = leave the code cleaner than you found it! If you don’t have time to fix it, add a comment in our General channel within Teams to create visibility into what was found.
  • If a story or bug is needed, create the work item in the backlog and communicate it out to the team via the general channel that a story has been added. It will get picked up and refined (via our development process)

COMMUNICATION TEAM NORMS :What are some tools, response timelines, channels used, preferred method to communicate amongst the team

• Please refer to your respective Teams channels for any communications with each other
• We will use email as a secondary preference for external stakeholders
• Don't forget to include team in emails, threads, etc! (even if it's just for visibility)
• How do we prefer receiving and eliciting feedback? Sharing information?
• Where is our main source of truth? (Wiki) - As a team, do we document findings, diagrams, steps for remediations, steps for completion for a particular body of work, etc?
• If contributing teams reach out, what is our SLA?

ROLES AND RESPONSIBILITIES :Do you understand each team member's role and responsibility?

• Product:
• Scrum Master:
• Tech Lead:
• Developers:
• QA:
• Additional Stakeholders:

---

Technical Team Norms :To align with team on all things technical: continuous improvement, escalation process, deployment/release process

RELEASE PROCESS :To agree with team on what steps are needed is order to push code into production

• Similar to Definition of Done, what is critical for releases?
• Standard release procedure?
• Align on time/day
  • Also consider, what happens if a release is unsuccessful? What would be needed to remediate? (Don't forget to document!)
• Would it have to wait and be pushed to another date? Who will be needing to approve the release? Validators needed? Any code freezes?
• Is PR added to ticket? - Has it been reviewed?
• As it goes through the steps, has it gone to QA? - Is everything working as it should?
• How the team communicate to our stakeholders/leads of a successful release?

ESCALATION PROCESS

• If an issue arises, what steps will the team do?
• Who are we reaching out to for assistance on risks or impediments?
• How high in senior leadership should it go?
• What is the communication process like?

CONTINUOUS IMPROVEMENT :We learn from experiences, shared best practices, and documentation. - How do we want this to look like?

---

Partner Engagement Checklist :To align with each Pod on how to each would like to engage with partners. Template provided below.

Pod contract agreement example 

How we engage with partners  :Our team builds simple user experiences, so we look for working APIs and to engage prior to the API begins development to drive the best value. 

Workback schedule example 

Below is an example of milestones expected throughout an engagement with our pod. If a feature ask is logged on our pod, this workback schedule can be completed to give partner pods an idea of how we work. This example assumes 4 weeks of development for a feature ask. 

 

Line Item	Time Estimate	Date Complete	Notes
Go - Live	0 weeks	June 1, 2023
Roll to Prod	1 week	May 23, 2023
Bug Bash	1 week	May 16, 2023
Time until Development Completion	4 weeks	May 9, 2023
API available in test environment, dev start		April 9, 2023
Engage with us for design, feature, API refinement			Engage with us 2+ weeks prior to API development begins

Readiness tasks 

For us to be effective at collaborating with your pod, below are a list of common items we expect from partner pods. If you can provide us with target dates to provide the below information, it will help us plan our work. 

• List of API being built is provided and availability of each endpoint with dates are provided. 
• API is available in test environment a minimum of 1 week prior to scheduled development. 
• Swagger has been shared with and is signed off by our pod PM. 
• GET, PUT, POST calls return correct data promised in Swagger and has been tested / demoed to pod PM and pod lead. 
• P95 perf number has been agreed upon and validated by partner team. 
• Sample working script with example code (REST calls, CLI needed, etc.) is provided. 
• Provide list of restrictions to any input fields (e.g. runtime restrictions, scenario restrictions, cross feature dependencies/exclusions, character length restrictions, whether a field is mandatory, etc.) and the appropriate regex. 
• Access to test environment has been provided. 
• Communicate timelines for availability of feature to all customers.