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

Team Pride

Problems worthy

of attack

prove their worth

by hitting back.

— Piet Hein (1905-1996)

... you are about to embark on yet another challenging project. The work will be technically difficult, or maybe it's just that you have a very short schedule. But at least you have some idea of what you want to do — the beginning of UnityOfPurpose. 

✥ ✥ ✥

People are most successful when they feel good about their project, and are confident. But there is a chicken and egg problem here: Confidence breeds success, but success creates confidence.

Pride perhaps goeth before a fall, but so doth apathy.

Most software projects — sometimes even the fun ones — demand a lot of work. And the ones that aren't fun don't have much of a chance of seeing a victorious finish unless something pulls its people together and draws them on towards completion. The hard work feels even harder because of short schedules. Such projects demand the best everyone can give, so motivation is often a key to success. 

If people consider the work to be "just a job", the results will reflect it. 

Teams tend to become self-fulfilling prophecies: everyone wants to work on a winning team, so teams can pick the best people. On the other hand, teams with low performance tend to be stuck with low morale. People don't join such teams willingly; they come in with a bad attitude. 

So how do you bring such a team out of the doldrums? Even better, how do you give a team a winning attitude right from the start? 

Therefore, 

"We're the best." Instill a sense of elitism into the team. Teams that have a certain arrogance tend to work hard and accomplish what is put before them.

Really, one cannot open a team up and pour in a cup of team pride. Team pride must come from within. But there are many things you can do to help it come to pass: 

  • Start with a worthwhile problem. Team members are more likely to feel elite if they have a challenging problem to tackle. It is especially good if the problem involves new technology; nothing excites a bunch of geeks more than working with the newest stuff.

  • Apply SelfSelectingTeam. If the team self-selects, they will go for the best people, in their opinion. So they will believe they are good.

  • Find some important strength of the team, and make that a rallying point: teach the team that they are good in a particular area. Be sure to find a real strength; people can easily see through a manufactured strength. The strength should be a technical strength; while a team might rally around "we party better than anyone else", it won't get the software written.

  • Provide some explicit separation from other projects. This can be physical location (put people together away from others), organizational, or information (share secrets with the group.) It can also be exemption from some of the rules that everyone else must follow. Just things to make it clear they are set apart from other groups.

  • CompensateSuccess.

  • The parent company must be doing well enough so that it isn't a concern. This author was once on a team that felt it was elite until the company started doing very poorly. The company woes diverted our attention and sapped our morale.

  • FireWalls. This generates an attitude of "Top teams shouldn't be bothered by bureaucratic crap."

  • As with UnityOfPurpose, it helps to unite against a common enemy.

✥ ✥ ✥

By itself, TeamPride does not guarantee the success of a project. But Boehm and others have pointed out that people are the key success element of any project, and TeamPride helps nurture and encourage them. It may even be able to overcome poor overall morale in the company.

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