Bootstrapping a Working Agreement for the Agile Team

I suspect that running a session with a team to help them bootstrap a Working Agreement, is the single most common workshop I’ve been facilitating the last couple of years. And I’ve learned a lot of what works for me (and what doesn’t work). In my experience, this approach works equally well for the agile team, the department management group and the steering board team. This blog is me documenting how I ended up facilitating these sessions.

For me, a Working Agreement captures the expectations we have on each other within the team when we collaborate and communicate. I’ve seen teams call it “Code of Conduct” or “Ways of Working”. I call it Working Agreement. You call it whatever makes sense for you.

Running a Working Agreement workshop as early as possible is crucial for setting the team up for success. Preferably it’s done during the team’s two-day kick-off offsite, or at least within the first few weeks as a planned structured workshop.

Preparations

If possible, I try to be a few minutes early into the meeting room to be able to prepare the whiteboard (as in the illustration above), and to make sure there are enough Post-its and Sharpies to go around.

Proposal under discussion is put in the bubble. Agreements are then then moved to the “Working Agreement” area. Parked proposals are moved to “Maybe later…”

.

Summary

I’ve found that a 90 min session is lengthy enough to create a good first version of a Working Agreement, and not too long for people to lose interest and energy. I usually structure it like this:

  • Check-in (5 min) – A check-in round to get people talking and engaged
  • Opening (5 min) – Welcome and presentation of why and how
  • Write proposals (10 min) – Individual writing of proposal statements for the working agreement on Post-its
  • Agreeing on the Working Agreement (60 min) – Presentation of proposed statements, voting and discussion
  • Summary (5 min) – Summary of the Working Agreement
  • Check-out (5min) – A check-out round to create closure and reinforce the agreement

.

Check-in

I usually open the workshop with just welcoming everyone to the meeting and then jump straight into a Check-in round. I do this to get everyone a chance to say something as early as possible and to create a relaxed atmosphere.

You can ask any question you want to, and feel is appropriate, but I tend to default to “What is your personal expectations on this upcoming workshop” or “What state of mind were you in as you came into the room and sat down on that chair?”

Once I’ve posed the question, I ask someone to start, and then continue clockwise around the room until everyone has shared. (If someone goes on for too long, I tend to say something like “Thank you for sharing, but could we try to keep the check-in answers shorter moving on?”)

.

Opening

I then continue to explain that we now will create our first version of our Working Agreement together. It will establish a baseline of what behaviours we want to see, captures our expectations on each other and defines what we should be able to hold one another accountable for. By creating a working agreement, we create an understanding of what is important for us in order to be able to work well together as a team.

I then explain that we soon will get 10 minutes to write down bullets we would like to see in the Working Agreement. These will be proposals that you get a chance to explain and that we will vote on together. I then give them a few pointers and guidelines:

  • When writing, think of situations when you communicate, interact and collaborate, both directly face to face such as in planning meetings, daily stand-ups and retrospectives, but also indirectly through tools such as Jira or a chat.
  • You may write down things that you think are working well today and you want to clearly anchor in the agreement, or things that you would like to see more of or addresses aspects you don’t feel work that well today.
  • On the Post-it, write down an OBSERVABLE POSITIVE BEHAVIOUR you want to see.
    • Good example: We’re on time to meetings. If late, we alert the team in our chat.
    • Bad example: We shouldn’t come late to meetings
  • Think of the statement as a proposal for a principle. Some principles are specific (like the example above), others are more general – but still useful.
    • Good example: We celebrate our achievements (Doesn’t specify how and when, but clearly states an ambition)
    • Bad example: We have fun (Too vague. Fun means different things for different people)
  • What you write should be self-explanatory and don’t need further explanation. You don’t have to write why you think it should be in the Working Agreement, you will get a chance to explain that verbally. A keyword is probably never enough so try to write a comprehensible but short sentence. Use a sharpie and write nice and readable.
  • I as a facilitator might reject proposals in the form of “We treat each other with respect” or “We have fun” since the words respect, and fun can mean vastly different things for different people. Instead try to capture what’s important for you. For example: We give everyone a chance to participate in the dialog. We listen and don’t interrupt.
  • Write as many proposals as you want, but please be mindful that we probably only will have time to cover two to three of each person’s proposals today due to time restrictions. The ones we don’t have time to discuss today we’ll save for a future session.

These seem like a lot of things to explain, but I don’t say much more than what’s written above. I’ve learned that being clear on the instructions is crucial for helping the team successfully bootstrapping a Working Agreement and helping the team have valuable, useful and concrete discussions around the proposals.

.

Write Proposals

Then I shut up for ten minutes to give people time to formulate their proposals for the Working Agreement. If everyone seems to finish early, I ask if they feel happy with what they’ve got and want to continue, or if someone would like a few more minutes. I’ve noticed that some people only manage to write one or two Post-its, while others have a stack of twelve in front of them. That’s totally ok. It’s can be tricky to formulate observable positive behaviours, especially if this is the first time doing it.

.

Agreeing on the Working Agreement

And then it’s time to go through the proposals and vote on them. I choose a person by random, usually by spinning a pen on the table. I ask that person to start by picking ONE of his/her proposals, stand up, and bring that one proposal and put in inside the thought bubble I’ve drawn on the whiteboard.

Present the proposal

First, I ask the person to read out what the Post-it reads – load and clear. Then I ask him/her to briefly explain why this is important to him/her. And then I turn to the rest of the group asking them if they have any questions of clarification, if there’s something in the proposal they don’t understand. I ask them to not reveal their opinion about the proposal just yet, we will do that through the voting, but to make sure they understand the expectation or behaviour formulated on the Post-it by asking questions.

If no one has any questions I usually inject some of the following questions, giving the person standing up by the whiteboard a chance to answer them one at a time.

  • If we vote for this and honour it, can you give me examples of what that would look like? What would I be able to see with my eyes?
  • If we fail to honour this, what would that look like?
  • If we evaluate our ability to honour this working agreement two months from now, would we be able to evaluate whether we are respecting this bullet? How would we do that?

I ask these questions to ensure that everyone gets a better and deeper understanding of what it would mean to have the bullet as part of the working agreement.

Once I feel the group understands the proposal I continue to the voting. Sometimes no follow up questions are needed at all, the proposal is super clear and obvious.

Voting

I explain that we will vote with our thumbs. “On a count to three, you reveal your vote. Not earlier. We don’t want to prime each other.”

Thumb up means: Yes, I like it AND I believe I will be capable of honouring it.
Thumb down means: No, I believe this would be bad for us as a team – or – No, I don’t believe I’m capable of honouring this at all.
Thumb sideways means: Sure, if there are no thumbs down, I will accept this being in our Working Agreement. I would however like to share a thought or concern.
Closed fist means: This specific principle doesn’t apply to me or my work, so I abstain. I will let the others decide. I’m okay with their decision and will respect it.

Once I’ve explained the voting, I count down from three “Three, Two, One, Vote”.

No thumbs down

If there are now thumbs down, I proclaim “Great! We have added our first bullet to our Working Agreement. Let’s applaud this decision with a one-clap-applaud!”

Doing a synchronized one-clap-applaud is tricky, but always gives raise to a few laughs and giggles. Groups usually gets better at this after some practice.

I then move the Post-it to the Working Agreement section of the whiteboard. If there are thumbs sideways or closed fist, I now ask them to share why they voted sideways or had their fist closed. I clarify that the bullet has been decided but that it would be valuable if they would share why they voted the way they did. I ask them to keep it short and that this is not the moment to reopen a debate. If you don’t want it in the Working Agreement, you vote thumbs down.

Then I ask the next person to pick one of his/her proposals and approach the whiteboard, repeating the process.

Thumbs down

If there are one or more thumbs down the proposal didn’t go through. I ask the people to share their perspective on why this would be a bad thing for the team to have in the Working Agreement. This usually trigger some great discussions and many times the team reaches a shared understanding, finding a way to reformulate the proposal so that everyone is happy with the formulation. However, if the group fails to decide on a new phrasing within 4-5 minutes, I do a time-out, stopping the discussion. I state something in the lines of “Even though several members in this team want this bullet in the Working Agreement, we also have some friends who don’t want it there. I don’t see us being able to agree upon this one within the next few minutes. I propose that we park this one for a future discussion and continue with the next proposal. The game for today is to find as many bullets that we agree upon as possible in order to have a stable ground to build further discussions on.” And then I move the Post-it to the “Maybe later…” section of the whiteboard.

Repeat

This continues until the timebox is up. I try to close this part of the exercise so that I have 10 minutes left for the last two topics of the agenda. I make sure that the group is aware of the time that is left so that the ending doesn’t come as a surprise. I might even try to estimate how many more proposals we’ll have time to cover when being halfway through the timebox.

.

Summary

First, I ask the group to applaud their own effort of bootstrapping their first Working Agreement with a proper applaud. Then I read the agreed upon bullets out loud, high and clear. I do this to reinforce the decisions made and to remind the group of what they’ve decided upon.

Before moving on to the Check-out I ask the team how they will capture and document their Working Agreement. Will they move the Post-its to their Team Room? Document in Google Docs? Who will do it?

.

Check-out

And to wrap up the meeting and the exercise I do a Check-out round, asking the team to take turns answering the question “Which bullet in the Working Agreement do you think will make the biggest difference? Which one is your personal favourite?”

.

Follow up

A Working Agreement is a living document and deserves continuous attention, love and care. Make it visible in the team area. Make sure to share it to new team members. Bring it to the Retrospective so that you can extend upon it. A retrospective is a great time to bring up proposals that didn’t make it, or that we didn’t have time to cover. You could also dedicate a whole retrospective to discuss and evaluate how good you are at honouring the different bullets. Perhaps some deserve to be rephrased. Some might even feel obsolete and maybe should be removed.

Good luck! Hope you found this lengthy blog inspirational or useful 🙂

18 responses on “Bootstrapping a Working Agreement for the Agile Team

  1. Great blog Jimmy, very good process to set the guidelines and get the whole team to have the same expectations to each other

  2. Great post! Creating a team charter together first thing in the “forming” stage is vital to create team alignment and the best way to prepare the team for the coming journey.

  3. So glad to see this written up after our great conversation!
    Now everyone can try it out and reap the benefits 🙂

  4. Thanks so much, I intend to use this as a guideline for facilitating a team charter/working agreement workshop with my scrum teams. I like that the output is driven entirely by collaboration with an emphasis on positive behavior and reinforcement.

  5. Great post! I especially liked how you make sure everyones prio one is included, as the time-box might exclude some notes. Thanks for sharing!

  6. Wonderful idea! Can’t wait to try it with my team. Thanks for the excellent post.

  7. Nice! Will use this as an inspiration for these sessions. Thinking about combining with liberating structures and maybe the consent model for decision making.

  8. Jimmy, thanks for your wonderful post! I am going to try it soon! The flow you illustrated for conducting the activity is good.

  9. Great post, Jimmy!
    Could you perhaps share an example of the working agreements that you helped your teams establishing? 🙂

    Kind thanks,
    Jimmy

Leave a Reply to Lori Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.