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

Legend Role ★

Baseball legends George Sisler, Babe Ruth, and Ty Cobb

The hero Westley had returned in the guise of the Dread Pirate Roberts. He explained to Princess Buttercup that he had been trained by the previous Dread Pirate Roberts: "One day Roberts pulled me aside. I'm not the Dread Pirate Roberts, said he. And the man before me wasn't either. Then he explained that the name was important. You see, no one would surrender to the Dread Pirate Westley." (From The Princess Bride, [BibRef-MGM1987]) 

...over time in a project, certain people really excel in their jobs. They become real masters, and take on many important jobs in the project. 

✥ ✥ ✥

Certain individuals take on so many jobs, and become so important to the project that when they leave, the project is in more than just serious trouble.

These individuals are generally the elder statesmen and women in the project. They have been around longer than most anybody else, and their depth of experience is invaluable. But because of their age, they are the ones most likely to retire. 

Not all people are like this. These are the ones who tend to pick up extra work and the associated expertise. So their absence is felt all the more. In fact, it seems like it would take two or more people to fill their shoes. 

Therefore:

Name a role after the person, and make it an honor to fill that role. People will want to emulate the legendary person, and do just as good a job.

In many cases, the role named after the person will naturally emerge. Then it is a matter of formalizing it a bit, and filling it as the legend retires. 

There must be training provided for the person filling the role. Ideally, it is offered by the original legend, as part of turning over the role to the new person. This is as important as naming the role itself. 

A software company we analyzed had a role named "Simon". They told us that Simon had been a key player in the project, and had done seemingly everything. They kept the name, and the jobs he had done. 

Some corporate cultures are built around archetypes, like electric power companies built around the heroic acts of linemen working during threatening weather. 

Emulation can be encouraged with an award. This author wrote some patterns of shepherding. Later, the Neil Harrison Shepherding Award was established, which encourages people to be better shepherds. 

✥ ✥ ✥

This helps maintain project knowledge and expertise over time, helping to keep a ModerateTruckNumber. Note that there is a useful lifetime of legend roles; they will fade over time, which is generally all right. 

There is a subtle but important difference between having a legend role and having the actual legendary person on staff. CultOfPersonality from Don Olson ([BibRef-Olson1998a], 154-155) offers this advice: 

A tight schedule, poorly defined requirements, uneven distribution of skills among the development team, and new technologies has put a project in jeopardy. To save the day, bring in a legendary figure among the developers to take over the lead. Team members who are not impressed may need removal or reeducation. 

LegendRole looks longer term and intends to be an inspirational rather than remedial pattern. CultOfPersonality can work if the legendary figure offers true leadership and develops growth in the team; but then, it is no longer a "personality cult" in the vernacular sense. It is dangerous for a team to develop too much dependency on a single power figure, because the team has difficulty adjusting to a new communication structure, authority and control structure, and culture, when the legendary figure is gone. Also, the LegendRole could become a bottleneck under these situations; see DistributeWorkEvenly. 

This in fact was noted by Alistair Cockburn as being a problem in the XP-based [BibRef-Beck1999] C3 project, where he characterizes XP as a high-discipline methodology and likens it to Humphrey's Personal Software Process. [BibRef-Humphrey1995] This commentary comes from the WikiWiki Web (http://c2.com/cgi/wiki?HighDisciplineMethodology, 27 May 2001): 

I consider XP a HighDisciplineMethodology, one in which the people will actually fall away from the practices if they don't have some particular mechanism in place to keep them practicing. Ron [Jeffries] is that mechanism at the moment. Should (when) Ron leave, then unless he is replaced in his role, I quite expect to see the team not following the practices properly in less than 6 months.

Ron did leave the project and we find on the CthreeProjectTerminated page: 

... It wasn't "to live" it was to stop following all of the practices.

    • "unless [the coach] is replaced in his role, I quite expect to see the team not following the practices properly in less than 6 months. I think that is a fair test of a HighDisciplineMethodology. -- AlistairCockburn"

    • "I'm no longer on C3 full time. Alistair's six-month clock has started. -- RonJeffries 6/25/99"

    • "As of the first of February, 2000, the C3 project has been terminated without a successful launch of the next phase."

The coach in fact does figure strongly in the XP organization ([BibRef-Beck1999], 145-146). The coach is "responsible for the process as a whole" and sometimes must intervene to the point of "rudeness." However, XP as published recognizes both the danger and difficulty of interventions that are overly direct and immediate. But our study of several projects claiming to be using XP practices found strong elements of a personality cult. In one case, in an XP project in an insurance company, the team leader became more assertively involved when the project got behind schedule (the project dutifully and effectively uses the XP planning game). 

If instead the legendary figure consults with the team, with the aim of helping the team members to grow, this can be an effective approach. See [BibRef-Weinberg1986] for ideas.

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