Team norms, working agreement – Scaled…

Agile Scrum teams that I have interacted with have their team norms or working agreements in place. This is in place either at the start, or within a few sprints.


Typically, it starts with an attempt to address some aspect of collaboration within the team. The team gets together and works out an approach by consensus and documents them as team norms or the working agreement. It helps for the coach to nudge them to put these up as the team norms.

Many of the teams that I have coached, initiate this for the Daily Scrum or the daily stand up, when there is a drop in its effectiveness. The Daily Scrum starts off well, when the team adopts Scrum, with all participating with enthusiasm. After a while, if someone is on leave the update is missed. This if left unchecked, typically results in updates missing from team members who may be at work, but busy with something urgent. Slowly this can get worse and the Daily Scrum attendance may fluctuate unduly.

The team then gets together, spells out the expectations from the Daily Scrum and work out how that can be met in different situations – like the team member is absent, stuck in traffic, attending to some critical issues and the like. The agreed approach becomes the team norm.

Now, in situations where there are multiple teams working, I find there is no equivalent of this at an inter team level. If team members need team norms/ working agreement to work together well, then it is pretty obvious, that if two or more teams are working together they need to have a inter-team working agreement. More often than not, this need is not recognized.

Often lack of the working agreement surface as issues in the retrospectives and the Scrum Masters try to resolve this as transactions in the Scrum of Scrums or other forums. This approach works at times, often it doesn’t. It depends on the rapport between the two teams, Scrum Masters and how the Scrum values are practiced. Retrospective notes are shared across teams, but by the time that happens, they are busy with their work for the next sprint.

I have encountered this situation many a time and here is what I have tried with good outcomes.

  • Ensure that all the teams have team norms, working agreements. At times one of the teams may not be having this, typically, when the teams are not co-located.
  • Have them share the team norms with each other. This often triggers discussions on how something needs to be tweaked to make it work across teams. In the process, evolution of inter team working agreement gets naturally kicked off.
  • Let the teams understand expectations of each other as well as what they are willing to offer on their part. The very act of offering always results in a reciprocated gesture. This results in a good set of inter team working agreement and these are specific to the context of the set of the teams, that are working together.

I would like to share a specific instance here, the team I was working with used to get annoyed at the broken build, they encountered at the start of their work day. This would be a result of changes done by another team working in a different time zone. The two teams worked out the norm as below:

  1. The team leaving a broken build, will leave pointers on how to correct it. Note that this would be an exception and not a norm.
  2. Designate a person that can be contacted in their non-work hours, if need be, to resolve the issue.

Interestingly, once these norms were in place, the option of calling the designated contact person was never used. The team managed to resolve the issue by themselves. It was the assurance that the other party is there to help/ correct their mistake, that set the right mood in the team.

I hope more and more teams will work out the team norms and the inter team working agreement formally. I would like to share another simple but highly effective practice that emerged, after the inter team norms were rolled out in one of the projects. One of the Scrum Masters suggested that each team share their Sprint Goalswith other and have it displayed along with their own Sprint Goals. This worked wonders as mutual dependencies were transparent to all the teams, The “other” team Sprint Goals up on Task boards that was visible to the team during their Daily Scrum.

Would love to hear from you all on your comments and experiences in evolving inter-team norms.

What do you think?

Leave a Reply

What to read next