Search this site
Embedded Files
Scrum Pattern Group
  • Scrum PLoP
    • Scrum Tulip PLoP 2021 - Enkhuizen Netherlands
    • Scrum PLoP 2019
    • Scrum PLoP 2018, Quinta da Pacheca, Portugal
    • ScrumPLoP 2017, Quinta da Pacheca, Portugal
    • ScrumPLoP 2016, Porto, Portugal
    • ScrumPLoP 2015, Porto, Portugal
    • ScrumPLoP 2014, Helsingør, Denmark
    • ScrumPLoP 2013, Helsingør, Denmark
    • ScrumPLoP 2012, Helsingør, Denmark
    • ScrumPLoP 2011, Helsingør, Denmark
    • ScrumPLoP 2010, Stora Nyteboda, Sweden
  • Original Org Patterns Site
    • Organizational Patterns of Agile Software Development
      • Book Outline
        • Preface
        • History and Introduction
          • An Overview of Patterns and Organizational Patterns
          • What Are Patterns?
          • What Are Pattern Languages?
          • Organizational Pattern Languages
          • How the Patterns Came to Us
          • Gathering Organizational Data
          • Creating Sequences
          • History and Related Work
          • Introspection and Analysis of Organizations
          • Shortcomings of State of the Art
          • Analyzing Roles and Relationships
          • How to Use this Book
          • Reading the Patterns
          • Applying the Patterns
          • Updating the Patterns
          • Who Should Use This Book?
          • Size the Organization
          • The CRC-Card Methodology
        • The Pattern Languages
        • Organizational Design Patterns
          • Project Management Pattern Language
          • Community of Trust
          • Size the Schedule
          • Get On With It
          • Named Stable Bases
          • Incremental Integration
          • Private World
          • Build Prototypes
          • Take No Small Slips
          • Completion Headroom
          • Work Split
          • Recommitment Meeting
          • Work Queue
          • Informal Labor Plan
          • Development Episode
          • Implied Requirements
          • Developer Controls Process
          • Work Flows Inward
          • Programming Episode
          • Someone Always Makes Progress
          • Team per Task
          • Sacrifice One Person
          • Day Care
          • Mercenary Analyst
          • Interrupts Unjam Blocking
          • Don't Interrupt an Interrupt'
          • Piecemeal Growth Pattern Language
          • Size the Organization
          • Phasing It In
          • Apprenticeship
          • Solo Virtuoso
          • Engage Customers
          • Surrogate Customer
          • Scenarios Define Problem
          • Firewalls
          • Gatekeeper
          • Self-Selecting Team
          • Unity of Purpose
          • Team Pride
          • Skunkworks
          • Patron Role
          • Diverse Groups
          • Public Character
          • Matron Role
          • Holistic Diversity
          • Legend Role
          • Wise Fool
          • Domain Expertise in Roles
          • Subsystem by Skill
          • Moderate Truck Number
          • Compensate Success
          • Failed Project Wake
          • Developing in Pairs
          • Developing in Pairs
          • Engage Quality Assurance
          • Application Design is Bounded by Test Design
          • Group Validation
        • Organization Construction Patterns
          • Organizational Style Pattern Language
          • Few Roles
          • Producer Roles
          • Producers in the Middle
          • Stable Roles
          • Divide and Conquer
          • Conway's Law
          • Organization Follows Location
          • Organization Follows Market
          • Face-to-Face Before Working Remotely
          • Form Follows Function
          • Shaping Circulation Realms
          • Distribute Work Evenly
          • Responsibilities Engage
          • Hallway Chatter
          • Decouple Stages
          • Hub Spoke and Rim
          • Move Responsibilities
          • Upside-Down Matrix Management
          • The Water Cooler
          • Three to Seven Helpers per Role
          • Coupling Decreases Latency
          • People and Code Pattern Language
          • Architect Controls Product
          • Architecture Team
          • Lock 'Em Up Together
          • Smoke Filled Room
          • Stand Up Meeting
          • Deploy Along the Grain
          • Architect Also Implements
          • Generics and Specifics
          • Standards Linking Locations
          • Code Ownership
          • Feature Assignment
          • Variation Behind Interface
          • Private Versioning
          • Loose Interfaces
          • Subclass Per Team
          • Hierarchy of Factories
          • Parser Builder
        • Foundations and History
          • Organizational Principles
          • Priming the Organization for Change
          • Dissonance Precedes Resolution
          • Team Burnout
          • Stability and Crisis Management
          • The Open-Closed Principle of Teams
          • Team Building
          • Building on the Solid Core
          • Piecemeal Growth
          • Some General Rules
          • Make Love Not War
          • Organizational Patterns are Inspiration Rather Than Prescription
          • It Depends on Your Role in Your Organization
          • It Depends on the Context of the Organization
          • Organizational Patterns are Used by Groups Rather Than Individuals
          • People are Less Predictable than Code
          • The Role of Management
          • Anthropological Foundations
          • Patterns in Anthropology
          • Beyond Process to Structure and Values
          • Roles and Communication
          • Social Network Analysis
          • Distilling the Patterns
          • CRC Cards and Roles
          • Social Network Theory Foundations
          • Scatterplots and Patterns
        • Case Studies
          • Borland QuattroPro for Windows
          • A Hyperproductive Telecommunications Development Team
      • Appendices
        • Summary Patlets
        • Organization Book Patlets
        • Bibliography
        • Photo Credits
      • Mysteriously Missing
      • Supporting Pages
        • Common Pattern Language
        • Organizational Patterns
        • Diversity of Membership
  • Original Scrum Patterns Site Archive
    • Scrum as Organizational Patterns
    • Scrum Patterns Summary
    • Software Scrum Patterns
    • First-Level Scrum Patterns
  • The ScrumPLoP Mission
  • What is a PLoP?
Scrum Pattern Group

Community Of Trust

In high school, I went to music camp one year. During one orchestra rehearsal, my section was struggling with a particularly difficult passage. The conductor asked about it, and I said, "Don't worry. We will have it tomorrow." He said, "Ok," and continued with the rehearsal. By the next day, we had indeed learned the passage.

... once an organization has been established, interpersonal relationships have a significant positive or negative impact on the effectiveness of the team.

✥ ✥ ✥

It is essential that the people in a team trust each other, otherwise, it will be difficult to get anything done.

Communication is essential to the smooth working of any team; for example, software developers must constantly talk to each other to coordinate interfaces, builds, and tests. If individuals do not trust each other, communication will not be smooth. 

If people do not trust each other, they will spend time in defensive mode. For example, if I don't believe you will provide me a certain interface on time, I might go to great lengths to code around it, costing extra work and time. 

Design reviews can foment distrust. All too often, design reviews are contests among the reviewers to show who is more clever, and thus do not provide helpful suggestions to the designer. One alternative is for people to put on their best social behavior in reviews, but that dampens the energetic discussions that lead to the best insights in group discussions. 

The organization might have policies that smell of distrust: one may have to jump through hoops to be allowed to submit code to the project base. 

The perception of trust or mistrust is the reality, regardless of the intention. 

Therefore:

Do things that explicitly demonstrate trust, so it is obvious. Managers, for example, should make it overtly obvious that they are at the side of the organization, rather than playing a central role that controls people to do what must be done. Take visible actions to give developers control over the process.

The key here is that the actions must be visible and obvious, particularly if they are removing onerous rules and processes. Shortly before I went to work at a certain company, the company dispensed with time clocks for research and development personnel. My co-workers spoke fondly of the time clock smashing ceremony they had. 

✥ ✥ ✥

This is different from the oft-cited "empowerment" strategy. Empowerment is a conscious abdication of control to lower levels (see TheOpenClosedPrincipleOfTeams). In a CommunityOfTrust, progress is more often made by bilateral agreement than by unilateral directions. If people feel they have a voice and have influence over decisions, they are more likely to trust those who make the decisions. By the same token, they are likely to be more responsive in carrying out responsibilities they have committed to themselves over responsibilities that have been "given" to them. In fact, you can't give someone responsibility; you can only give someone accountability. Responsibility is taken, not given. One of the most demoralizing things a manager can do is to give accountability in the absence of responsibility. 

You need trust between the customer and all team members to lay out project plans that extend from SizeTheSchedule in the ProjectManagementPatternLanguage. The same is true for role differentiation; giving everyone pride and individuality can contribute to trust, as in SizeTheOrganization and its subtending patterns in the PiecemealGrowthPatternLanguage. Start building trust by starting small with FewRoles, and let this principle guide the OrganizationalStylePatternLanguage. To keep people from working defensively, one needs a team spirit; this is true ArchitectControlsProduct and subtending patterns relating to PeopleAndCodePatternLanguage. 

CommunityOfTrust provides a foundation for many other patterns, such as UnityOfPurpose, PatronRole, FireWalls, DeveloperControlsProcess, ResponsibilitiesEngage, and more. 

So why is this a separate pattern? It has a specific structural impact: it is about nurturing communication paths, and has some positional impact (in particular, it encourages manager roles away from the center.) Second, the visible nature of the actions is important; we haven't captured that in any of the other patterns. 

Trust is contagious, and spreads most effectively through an organization from the top down.

Copyright © 2026 The Scrum Patterns Group
Report abuse
Page details
Page updated
Report abuse