Roy van de Water, Jade Meskill, Derek Neighbors and Clayton Lengel-Zigich discuss:

• Confusing Working Agreements
• Working Agreements as Policies
• Values and Principles over Working Agreements

Transcript

Clayton Lengel‑Zigich:  Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich.

Derek Neighbors:  I’m Derek Neighbors.

Roy van de Water:  I’m Roy van de Water.

Jade Meskill:  I’m Jade Meskill.

Clayton:  I’d like to start out by asking everyone if you could please go to iTunes and rate this podcast if you get it from iTunes. We would appreciate that. We like the feedback. We did see one comment. Someone mentioned that we sound inexperienced. We’re going to take a look at the equipment and see if we can get that fixed.

[laughter]

Derek:  What do you mean “sound”?

Clayton:  I assume it’s something wrong with the border.

[laughter]

Clayton:  We’re going to start talking about “working agreements.” Here’s right off the bat. Roy, you work on a team where you have a working agreement with the team that says, “No production code will be siloed, so you’re going to pair all the time.” But, the rub is that you have an odd number of people.

How does that work?

Jade:  …and then odd group of people. [laughs]

Roy:  Yeah, we have an odd group of people.

Clayton:  It’s the second area of problem. [laughs]

Roy:  For us, that currently works by, “If you can’t silo, and we always pair, that means that if we have an odd number of people, we have three people in front of a computer.” We talked about that last time, “stooging”?

[laughter]

Derek:  Is that three keyboards? Three mice?

Jade:  This isn’t XP, my friend.

Roy:  It’s two keyboards and two mice, you can’t really sit all across, because then you’re at too extreme of an angle to the screen, you can’t see anything.

Jade:  Let’s talk about what happens when you’re in this “stooging” set up, just to set the stage real quick.

Roy:  What happens when I’m in it? Or ideally what happens? Ideally, in this case, usually what happens is, there are two people that are pairing and one person that just sits behind and peers over both of their shoulders.

Jade:  Has your team discussed this working agreement and the consequences of it?

Roy:  Yeah, we discussed it this morning.

Jade:  OK, how’d that go?

Roy:  I got shot down with an absolute “no,” when I proposed abolishing it.

Clayton:  Was the reason it got shot down was because they feel very strongly about not having silos?

Roy:  Yes, the reason I got shot down which is a legitimate reason and a legitimate problem, was they don’t want silos and the reason they don’t want silos is because, if someone is working alone, they can make decisions that the team is not privy to.

They’re really concerned about somebody making some decision by themselves and then the rest of the team has to deal with the consequences. There may be other ways for us to solve that particular problem but that is the group fear that we claim to have.

Clayton:  What are some ideas that you had for fixing it? How could you still have that working agreement where you don’t let people silo on production code, but not do this thing where you have to peer over people’s shoulders?

Roy:  Did you say still have people silo or don’t have them silo?

Clayton:  Not having people silo on production codes is a totally valuable, reasonable thing to have.

Roy:  Sure. I agree and I don’t. There’s other ways to mitigate it. For example, what if we switched off pairs really, really frequently?

Then you wouldn’t get the opportunity to silo for long enough to do any real damage. If you were to do a no‑siloing thing, I don’t know. At this point, the way that I feel when we’re stooging is when I’m the odd man out that’s sitting in the back like, “I am just wasting time.” I could be doing anything like answering email, or doing self‑improvement, or something like that.

I feel like that would be a better use of my time.

Jade:  To not get distracted with trying to solve that particular problem. On a team, what happens when you end up with a working agreement like this where the team feels very strongly about trying to protect one thing, but they’re actually causing other problems with the working agreement that the team has agreed on? What do you do?

Derek:  I don’t really think you can force teams to do things. Sometimes, you could but it’s probably not prudent more often than not. Sometimes, you have to let people be a little bit stupid until they recognize that maybe their stupidity’s holding them back.

It sounds like, in this instance, there’s inklings that people are understanding that what’s happening is problematic, but at this point, they have a value system that says, “We value this so much that, right now, we’re not willing to divest the value of that for something else.”

Roy:  It might be legitimate. I have not been with this team very long, but I’ve heard that in the past, they had some major issues with siloed work that caused major harm to the team and put several of our commitments either in danger or actually destroy their ability to commit to stuff. I can understand and relate to that.

Clayton:  Is there something about the way that a team might make working agreements where they would have the foresight to avoid some of this stuff or…in my way of asking this, how frequently should the team revisit their working agreements?

Jade:  The trick is, a lot of times we want to write them down and carve them into the tablets in the Ten Commandments of the team when, really, they’re a fluid living thing. The intent is that they’re there to help reinforce behaviors that we wish we had.

Once we’ve addressed that, we should get rid of that working agreement. Once it has become habit, let’s move on. They should be very fluid living things.

It’s hard to live with that reality. They can be changing all the time.

Roy:  Does it make sense to have a team working agreement to revisit all of your other working agreements on a regular basis to review them?

Should instead, have a working agreement until something comes up that causes us to question it? That’s the time to bring up whether or not we should continue to have it?

Derek:  I’m starting to lean more and more in life towards working agreements are evil hell. In the sense of they look like what we call “policy,” elsewhere.

We’d be much better suited as teams if we rooted ourselves in values and principles. We could say, “Behavior X is violating value Y.” Opposed to, “Here’s some hard and rigid rule we have to revisit.”

As we continue to add to them, it doesn’t fit on an index card. Then it doesn’t fit on an “8.5 * 11” sheet of paper. Then it doesn’t fit on a poster board.

Next thing, you have got the 795‑page working agreements book that people are trying to, “Subsection B.593 of the working agreement states…”

In this case, if the team said, “We value working together more than value working independently.” They could say, each one of those things “Is it valuable enough for us to do this first”?

They could weigh values against each other.

Roy:  I totally agree. We used to have that problem with Integrum back when we were doing contract development work. We used to come up a smart goal every week. Five weeks in, you totally forget what your smart goal was five weeks ago. Until you break it and it is convenient for somebody else to point it out.

After a while it builds up so much stuff, it’s hard to remember all of it. A base system of values is not hard to remember. You just use logic to figure out the rest.

Derek:  Smart goals are a little bit different. It’s important that you set marks for success to say, “If we do X, can we change our behavior Y and measure a change”?

If we have a hypothesis, and then we do something to work against that hypothesis, can we get the thing we are trying to measure to move? That’s a little bit different than a working agreement.

For retrospective goals, they are only as good as that sprint. Unless, the next sprint, they decide to do this again. They are temporal.

Working agreements are a little different. When people put them down, they think of them a lot more like policy. They exist until somebody says we terminate them.

Jade:  It really comes down to a fixed mind set versus a learning mind set. If we treat the working agreements as rules ‑‑ which is not their intent ‑‑ but it tends to happen that they become the rules of the team. We’re really missing the point.

We’re probably doing Agile, and not being agile. That’s what we really need to be weary of as a team. Even values and principles ‑‑ if they are being used in such a way that they are a weapon against your fellow team members, you’re missing the point.

Clayton:  One thing that’s interesting. If you took a team that wasn’t especially mature from a team perspective. Let’s say they knew about XP. They knew that courage existed.

Courage means a lot of things to a lot of people. Even if they read into what they mean in that context, they might agree to it.

If the team is immature, they might need something that is more of a specific working agreement. As the team matured and grew with that working agreement, they probably would come full circle to, “Hey, we are now at courage again. It means something different to us.”

I wonder if, as the team matures, they can shed some of the weight of those things being rules and can get to the principles. They were always at the principles and values, the entire time. They just didn’t realize it.

Roy:  That makes sense. I like that.

Clayton:  I don’t know if that’s the case or not. It seems like that’s the way things go.

Roy, you had mentioned the idea of having a working agreement to revisit the working agreements.

Jade, you had mentioned that they are a living document. I don’t even know that a lot teams take working agreements seriously. They treat them more like rules, like what Derek’s getting at.

How much effort should you put into those things? How much meaning should they have on the team?

You mentioned team rules, which sounds bad. Doesn’t the team need something like that?

Roy:  As little as possible so that there is as little resistance to change, if you want to change them down the line.

Jade:  I have a question real quick. This team that you’re working with, have you guys discussed your principles and values? Are those things that you’ve identified, or did you just jump right into working agreements?

Roy:  I want to say yes, but I’m not entirely sure if we ever have. I don’t know, sorry.

Clayton:  That’s another thing I’ve seen too.

Roy:  I wouldn’t be able to tell you what our values are, principles. Sorry.

Clayton:  Where people will have a Scrum team and they’ll say, “Oh it’s a Scrum team, so they use the Scrum values,” and then what are the SCRIM values? “I don’t know.” They never even agreed to these things. I feel like that happens all the time.

Roy:  Even at our place, we have the core commitments posted on the wall, but nobody’s committed to them.

Derek:  To me, as I lean further away from working agreements, things like the core really appeal to me. Where you’ve got core commitments, which are like working agreements, that are a lot more value‑based than they are rule‑based.

Then you’ve got constraints to work within, to say this is how we can solve problems based on these values. So that every unique situation that comes up, we don’t have to say, “How do we interpret the rule”? We’ve got mechanisms to communicate with each other to navigate how we want to deal with that rule.

Jade:  These are the Core Protocols by Jim and Michele McCarthy.

Roy:  Trying to avoid getting sued for your GPLv3 stuff?

[laughter]

Clayton:  Are we, maybe saying, “You shouldn’t use working agreements”?

Derek:  I don’t know if I would go as far as to say, “They’re evil. Stay away from them. They’re horrible.” Like all things, they’re a tool and tools can be easily abused. People tend to…when they get into working agreements they tend to get legalistic really quick.

What happens is either that people don’t take them seriously at all, so they have no value, or people abuse them by using them as a stick to hit people with it, that they disagree with, when they want to disagree with them.

Jade:  If they’re done in the right spirit to really support your principles and values by establishing some habits that you really wished you had. They can be effective.

Roy:  You mentioned about the legalistic thing, I’ve noticed that a lot in all sorts of teams, and groups, and people that I’ve interacted with, there just seems to be this human nature to always go towards the legalistic. Why do you think that is?

Derek:  I don’t know if it’s human nature. It’s because we don’t do well with ambiguity. We all bring personal baggage. There are so many things. When we lack construct, when we lack guidelines, we really crave that. Our natural tendency tends be to crave over doing that.

Where when you look at things like the core, they just give you good operating principles to guide on, so that you can deal with issues as they come. To me, that’s like where we’re evolving from an Agile perspective too.

You had traditional project management PMP that was very, very, very, highly prescriptive, highly rule‑based. Any little thing that comes in as a change order, now has a full change request thing, because it’s just not designed to deal with any new introduction into the system.

Now, we’re getting more and more nimble things. Where we say, there’s less and less structure and there’s more and more values and principles. As things come in, you try to basically do the right thing. That’s a much different. I like to call that “it’s permission versus policy.”

When you start to move more towards that, you have to have much more robust ways of dealing with that. If you’ve got no structure at all. It’s almost like the inverse. When you look at Agile, people think, there’s no structure. It’s actually highly, highly structured just in a very simplistic way. The rules are much more simplistic. They’re much more difficult to understand or nuance.

It gets into the whole whether you call it [inaudible 14:00] , or whatever. People that have been doing it for a long time can’t understand why people that are new to it, struggle so much. It should be so simple. There’s just these few little things, but it takes years and years of experience to understand when and how to apply those things. There’s so much context to them.

Clayton:  All right. I think we’re out of time. Thank you, guys.

Jade:  Thank you.

[music]

Announcer:  Is there something you’d like to hear in a future episode? Head over to integrumtech.com/podcast, where you can suggest a topic or a guest.

Looking for an easy way to stay up‑to‑date with the latest news, techniques and events in the Agile community? Sign up today at agileweekly.com. It’s the best Agile content delivered weekly for free.

The Agile weekly podcast is brought to you by Integrum Technologies and recorded in Gangplank Studios in Chandler, Arizona. For old episodes, check out integrumtech.com or subscribe on iTunes.

Need help with your Agile transition? Have a question and need to phone a friend? Try calling the Agile hotline. It’s free. Call 866‑244‑8656.