Working agreements - a great tool for taking teams quickly from storming to norming

We've started using 'Working agreements' at iflix over the last few months. These team building tools have been around for ever, but for some reason I have never used them before. Working agreements are the working processes and standards/rules the team all agree to follow.
Simply these can be about how a team organise work or generally interact with each other. Working agreements can be set at any time in a teams formation and can consist of something as simple as "Stand - up is at 9.30 sharp". If you've worked with agile (or any teams) in the past, you probably have a set of norms already. The secret sauce here is being explicit and making the norms visible.
Working agreements should then end up becoming embedded as Team Norms. At iflix, we try to define these team norms at formation of teams, or when we move a team onto agile processes. The team gets together and comes up with a list of norms they all agree on. There is no predetermined list but typically norms can be:
  • Stand up time
  • Definition of done
  • Processes around handovers from one lane to the next
  • Punishments for breaking team rules
I've used a lot of different methods to help a team define the working agreements. The simplest is facilitate a session, explain the basics of a working agreement and gather ideas from the team on working agreements they'd like to propose. I've used post it notes and asked teams to group them on a board. We can then vote for the top 3 and start from there. These can of course be added to over time, but I find 3 is a good starting point.
The important part is that everyone on the team signs up to each agreement. Once these are agreed upon, they're written up somewhere and made visible. It's a good practice to stick them near the team board and review regularly.
Below are some examples of team norms here at iflix. As you can see they vary from team to team and can be quite simple.

As the team starts to gel, they review these norms, debate the value and keep or change them as needed. Team norms are a really effective retro topic too, bring the norms to a room and do a 'keep, change, add or cull' retro around them.
There are lots of blog posts on 'working agreements' or 'agile team norms' so I'd recommend doing a google search. We've found them to be an excellent team building and 'inspect and adapt' tool, and I thoroughly recommend them.
Here are some links that I found useful:

http://bilal.eltayara.net/blog/2016/11/05/working-agreements/

Comments

Post a Comment

Popular posts from this blog

Using an agile storyboard as a scale of certainty

Image
As per my previous post, In my current team we have started using a 'Just in Time' (see how I feel weird about saying Kanban, not sure why yet) approach to doing various activities around development. Mostly this is around planning, but in that sense, we are also doing as much Just inTime as possible in giving an estimate. Scene setting We are a team that does 2 week sprints, but we also don't do a major release at the end of each sprint. We tend to wait for 5 sprints to pass before we do releases, there are a number of organisational reasons for that, but suffice to say, thats the way we do it around these parts. Our story wall (in ugly table form) The table below is a basic representation of our Story wall. As you can see, for the story wall, we deliberately do not just focus on the current 2 week sprint. We also have columns heading beyond the current sprint to encapsulate the entire release timeline (in this case the team have already completed two sprints so their are
Read more

A survey on release processes with organisations that 'sef-identify' as folowing agile practises.

Image
Earlier this year I ran a survey around ‘release processes’ specifically with companies that follow agile practices. I promised that I would publish the results and apologies for the delay, I have collated the responses below. Thanks to everyone that participated, really appreciate your time and energy. At iflix we're always looking to improve our release processes so it was really great to get so many good responses. We learnt we're not that far apart from our peers out there. We've got a lot to learn of course, some of that comes from hearing from others and some from the mistakes we make. The trick is to make your mistakes small ones and learn fast with minimal disruption to your customers. This survey was run at least 5 months ago, so it’s a snapshot in time.  Most places I have worked change their processes (inspect and adapt!). I've reproduced the responses in their entirety, so it is a bit of a long read. I’ve anonymised the responses somewhat, retaining
Read more

Mission Orders, 6 military principles that can work for agile teams

Yesterday, I was watching a documentary on the "Battle of the bulge" A famous battle in World war 2. The docu makers were investigating German tactics during the battle. Specifically, tactics which had worked so well early in the war, over extended periods of time, towards the end of the war, fell apart after 3-5 days. Early in the war, German officers had Mission Command, that is, Hitler and high command had high trust in their teams. As the war went on, and things started to go wrong, mission command was gradually eroded as trust fell (especially when his officers tried to kill him). Mission command basically means, set the goal, let the teams be responsible for how they are carried out. Training is centred around this, discipline and training carry you through the unexpected, as long as you know the end goal. Effectively, the German high command no longer trusted the lower ranks, and only gave them enough information, goals etc for the immediate goals and set them
Read more