Team Agreements - Ideas for a new, shu team?


In the past, I’ve used a simple format for building a “good enough for now” set of team agreements:

Do’s and Don’ts
Divergent brainstorming:

  • List out the do’s and don’t’s of a great team - what is required both to become great and also to maintain that greatness.

Converge/Affinity grouping:

  • information, communication, collaboration
  • Process, Product, Platform, Purpose, People

I’m looking to up my game a bit.

Curious how others approach having a new, young team create a v1 of Team Agreements.


Andy can you share some example of the team agreements you have done based on the criteria you listed ?


I don’t see anything wrong with what you’re doing today… if it’s “good enough,” great! Especially for a new team, you’ll (hopefully) be inspecting/adapting frequently anyway.

You could try facilitating a conversation with a “focus on/off” chart (described in Esther and Diana’s book) or something similar… I’ve often found this simple exercise is a good enough for a “first draft” of working agreements.

The truth is that a new team might not yet have the knowledge of what their agreements could be! A lightweight, simple exercise is probably best… get something down, inspect & adapt.

You might consider your facilitation and listening skills as the next step to “up your game,” instead of a practice/technique :slight_smile:



  • Show respect. Don’t interrupt. Let people finish
  • Ok to disagree, debate the merit of ideas, not people.
  • Everyone has equal voice and valuable conribution
  • Be on time, end on time
  • No hidden agendas. Give direct feedback, receive feedback, act on feedback
  • Solve roadblocks within the team. If impediment can not be solved w/in team, give it to scrum master
  • we hold ourselves accountable to our commitments. We work as a team to deliver.
  • Incomplete stores are not good. Finish before staring.


Another example:


I spent the last few days kicking off new team agreements (not a brand new team but new to each other). We broke them out into the following categories: Environments, Dependencies, Workflow, Communication, Engineering. We also made and effort to phrase them all as “We will…xyz” to make sure they were actionable. For example “We will ‘stop the line’ if there is a defect by marking the story as blocked and notifying the dev pair to drop everything and fix it.”


Was explaining to a team why they needed to add the Andon cord to their working agreement today. Love the actionable context @Colleen


This is awesome thanks Andy!