Sometimes teams need something solid, something real to discuss. I have seen and participated in a fair amount of, what felt like, endless conversations about values. I’ve seen teams struggle with implementing a coding standard. Even things as simple as deciding whether to choose spaces over tabs as spacing or where to put the curly braces. Everyone knows they belong on the same line, not on the line below. Correct?! Yeah, I thought so.

Discussing values

Does it help starting discussing values at a point when there is little or no trust present in a team. Maybe. Maybe not. I’ve seen that fail and I’ve seen it work to some extent in certain cases. One thing is for certain however. Building trust takes time. Otherwise it wouldn’t have been called building trust. It would have been called adding trust, buying trust or both. That would have been a sight. Imagine someone standing up during a meeting, proclaiming to the group: ‘I know what’s missing here, TRUST, I’ll just buy some and then we’ll add it … I’ll be back in a jiffy’. Only to sprint out of the room and then return after 30 minutes with ‘Canned Trust (TM)’.

Something to build upon

In the beginning of a relation between people I find it easy to discuss ‘hard facts’. Like, where to put the curly braces or when to check in code. I can even do more philosophical discussions as well. While others want to do either or. I like the idea of going back and forth in discussions, between values and practice. I believe most of us evolve ideas and learn in that fashion. Going back and forth between thinking and trying the thoughts out.

Enter ‘Working Agreements’

The Working Agreements of a team is the manifesto of its principles and intentions. Working agreements are also a basis for discussions and will thus evolve over time. Below is an excerpt of the working agreements from a team I spent some time with. The top most two are sort of meta agreements.

  • Everyone agrees about these working agreements
  • Anyone can remove an agreement at any time
  • When checking in code we use a check-in token.
  • We do our best to document our code with JavaDoc
Very simple example of working agreements

Very simple example of working agreements

This is just voodoo-nonsense

I see ‘Working agreements’ as a way to start discussing. I’d be surprised if anyone, in any team could put up a list of 5-7 ways of how the work works without getting into a discussion. Now, that is a good sign. Discussions and conflict is a sign of a healthy team in my opinion. That isn’t what I’m getting at though. Working agreements can be used to improve the relations between team members in teams that aren’t agreeing or are struggling with trust and need something ‘real’ to talk about.

OK, How do I begin

You could start a discussion over lunch. Usually a time when people are able to listen more carefully to what you are saying. With questions like the ones below you can arrive at things people agree upon.

  • Say something that is really important for us to do each day?
  • What can’t we do without in our code base?
  • I would sure like to be able to check in more often, how do I do that?

The next step, which is rather important, is to write the agreements down in a place where they can be easily seen by everyone. And ‘edited’. A flipchart or a whiteboard would work equally well. It is important that it’s visible so one is reminded of the agreements. And the fact that someone writes them down, by hand, also adds to the feeling of owning them. More so than printing them out on a printer.

Bringing in new team members

When new members join the team you get a natural discussion around the agreements. Questions like ‘What’s that … working agreements … ‘ have to be answered and new views are added to how the work works. I think ‘Working agreements’ is worth a try if you are struggling in any way with relations and trust in your team. I would like to add that this isn’t limited to software teams, it will work within any team in any organization.

Conclusion

Even if you think you have the best team ever, I believe that you will not be able to create a list of 10 different things that everybody agrees upon without any discussions arising. And that is my point. Every team will benefit from the actions and conversations that arise when you are trying to create your own ‘Team Working Agreements’.

Good luck and please tell me about your own experiences.

Advertisements

About Ola Ellnestam

Agile Coach, Systems developer, Agile Practitioner and father of three.

2 responses »

  1. Jocke Holm says:

    Nice post, Ola! It was a coincidence, but my team had a nice starting discussion about pair programming the same week this post came out. So I can just add to your insights that it is fine to start with some theme within all possible agreements that a team may have. Like you say, it takes trust to do it, and in the beginning it may be easier just to focus on one practice or aspect of teamwork. Cheers!

  2. Ola Ellnestam says:

    Thank you!

    I have never thought about themed working agreements. Brilliant! I’ll keep that in mind.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s