Norms, Values, Working Agreements, Simple Rules

The list starts with “Show Respect.”

I find it ironic that the new boss is advocating treating people with respect. Arriving with a set of rules for other adults you’ve just met doesn’t feel respectful to me.  And I’m pretty sure that imposing rules won’t have the desired effect.  Modeling behavior, engaging the group in discussion about patterns of interaction, yes. Coming in with the rules like a kindergarten teacher–not so much.

But the post got me thinking about how teams develop norms.

Teams develop norms whether they are paying attention to norms or not.

Teams build up a pattern of interaction and implicit understandings of what people can do, should do, should not do, must and must not do in various situations.  It’s part of being in group of humans.  Often, the patterns form without much thinking about the implications.  Norms form around where people sit in meetings, or acceptable late arrival, and whether someone should bring cookies on Tuesdays.

Effective teams have a shared approach to work (though not a rigid process).  They explicitly work out agreements about “How we do things.” The team’s agreements evolve to address both challenges and aspirations.  Teams find a way to talk about what matters, and decided how they’ll act out those priorities day to day.

When a team develops agreements, it helps to know what they are trying to accomplish, because different sorts of agreements serve different purposes.

Values

…are statements of what is important.  Value may guide behavior, but are not, in themselves, actionable. Values often represent the espoused beliefs in the organization–which don’t always match the values in action.

Example:  Balance work and life. (But pay attention to what really happens.)

Group Norms

…are informal, often implicit standards of behavior that develop from the interactions of the group.

Example: (By observing the group, we can deduces that…) It’s acceptable to be late for meetings.

Ground Rules

…are statements of expected behavior for specific times, places, and situations.

Example: (Posted in the meeting room) Don’t interrupt each other.

Working Agreements

…are protocols that the group develops and agrees to follow. The protocols aim to forge commitment and a shared approach that will help the team meet their goal.

Example: Code is *done* when all programmer and acceptances tests pass, the customer accepts the story, and the code is checked into the development branch.

Simple Rules

…are short statements that guide interactions and  decision making within the group and across other groups within the organization.  Simple Rules can generalize across many situations, and make values actionable. Simple Rules aim at brining coherence across the organization.

Example: Use every failure as an opportunity to learn.

All of these represent social contracts between group members. Effective teams use all of these tools to create a pattern of interaction and results that enhance their ability to reach goals and improve quality of both work life and results.

Reaching collaboration and high performance is possible without explicit agreements.  It’s much easier (and more likely) for a team to reach high performance when they pay attention to the pattern they want to create and use these tools to help shape the pattern.

Values, ground rules, working agreements, and simple rules each serve a different purpose. Some teams find it useful to both simple rules (which help make values actionable) and working agreements (which address specific practices).

For both simple rules and working agreements, the list should be…

• focused on amplifying desired patterns of behavior
• aimed at helping the team achieve their task and team-work goals
• generalizable
• minimum specifications
• short: no more than seven items on each list (fewer than seven is even better)

Many teams I meet have some variety of agreements about how to act. The groups that do best have a short list, and refresh it as needed.  I visited one group that had a list of 20 team rules.  That’s too many for anyone to remember. And, such a long list is indicative of a different issue–probably that the group members hadn’t developed common language around practices and had very different mental models of how software development works.

I don’t think every group needs to have a list of values, ground rules, group norms and simple rules. The point isn’t to explicitly govern all aspects of behavior.  I visited a group once that had a list of 20 ground rules. It’s always interesting to see how and whether team members hold the group and individuals to their espoused standards.  So look at the posted rules, and then observe how people really act.

“However they arise, such rules test a group’s own credibility. For example, if everyone agrees to make team meetings a top priority and then members fail to show up, it signals that the group may not be able to manage even the simplest of details, let alone conquer its performance challenges. The rules must be enforced. One team we know decided on total confidentiality to encourage open discussion. Early on a member violated the rule by talking to outsiders. When the rest of the team learned that the leader had gently, but firmly, reprimanded the offender, team discussions became even more open, free-wheeling, and, ultimately, creative.”