DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

The software you build is only as secure as the code that powers it. Learn how malicious code creeps into your software supply chain.

Apache Cassandra combines the benefits of major NoSQL databases to support data management needs not covered by traditional RDBMS vendors.

Generative AI has transformed nearly every industry. How can you leverage GenAI to improve your productivity and efficiency?

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workloads.

Related

  • Revolutionizing Financial Monitoring: Building a Team Dashboard With OpenObserve
  • The Modern Data Stack Is Overrated — Here’s What Works
  • Platform Engineering for Cloud Teams
  • Shifting Left: A Culture Change Plan for Early Bug Detection

Trending

  • Mastering Advanced Traffic Management in Multi-Cloud Kubernetes: Scaling With Multiple Istio Ingress Gateways
  • Endpoint Security Controls: Designing a Secure Endpoint Architecture, Part 1
  • Revolutionizing Financial Monitoring: Building a Team Dashboard With OpenObserve
  • Ensuring Configuration Consistency Across Global Data Centers

Norms, Values, Working Agreements, Simple Rules

By 
Esther Derby  user avatar
Esther Derby
·
Jan. 19, 13 · Interview
Likes (0)
Comment
Save
Tweet
Share
10.5K Views

Join the DZone community and get the full member experience.

Join For Free
Bob Sutton recently posted a piece on Team Guidelines.  The guidelines–all Mom and Apple Pie–where handed down by a new boss for the team to follow.

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.”

Norm (artificial intelligence) teams

Published at DZone with permission of Esther Derby, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Revolutionizing Financial Monitoring: Building a Team Dashboard With OpenObserve
  • The Modern Data Stack Is Overrated — Here’s What Works
  • Platform Engineering for Cloud Teams
  • Shifting Left: A Culture Change Plan for Early Bug Detection

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: