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
        • Parking Lot
        • IndentationHint
        • Starting Points
          • Project Index
        • OrganizationBookPatternTable
      • Stuff to do
  • 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

Skunk Works ★

At the end of college, I was interviewed for a job with Lockheed Aircraft Corporation, including their famed "Skunk Works" division. They had a huge skunk painted on the wall at the entrance to their work area. Everyone said the same thing to me: "We can't tell you what we do, but we sure have fun." I ultimately went to work elsewhere, but I occasionally wonder what it would have been like to work there. I don't know what work I would be doing, but I'm sure I would have fun doing it.

...organizations have the freedom to iterate and innovate early in the life cycle of their major products. As a project matures, the context becomes rigid, and innovation becomes "forced" and may appear in the guise of "innovation programs." While these programs are good at the divergent thinking component of innovation, they rarely do a good job of convergent thinking. The result is that novelty, valued for its own sake, finds its way into mainstream development where it incurs costs but leads to results that range from indifferent to disaster; "home runs" are rare. The net result is most often negative. 

✥ ✥ ✥

A project must accommodate major innovations but must also keep an eye on risk. It is too risky to innovate too much in project development. Some projects have "innovation programs" that value divergent thinking. The fruits of these efforts often make their way into development. It is only rarely that an organization does an honest evaluation of whether such ideas actually added value; the value is often taken on faith. For example, the latest technologies are always held to have value in their own right; conversion to OO, or to components, or to patterns, is considered "good" without a second thought. Too often, these new ideas have either indifferent results or in fact increase cost. They may decrease time to market or decrease cost, but if they decrease cost at the expense of time to market, then the overall effect is disastrous if time to market is the highest business priority. And, in fact, any new idea can both increase time to market and cost in ways that may never be noticed, in part because of the stock taken in the buzzword value of the idea. 

Yet projects become dead if there is no way to get paradigm shifts into the project now and then. 

Therefore: 

Allow a limited-cost SkunkWorks to form (as a SelfSelectingTeam) to develop an idea outside the constraints of project development, to build confidence in the idea. Give the SkunkWorks organization ownership and credit for the idea.

The organization is sustained by strong FireWalls that insulate it from the scrutiny of upper management and funders; in fact, the very existence of the SkunkWorks should be a secret. The idea is to keep the project off of management radar screens to foster the kind of innovation that leads to success before tradition and its constraints, as embodied in managers, can dampen innovation. 

The success of the idea is assessed according to the fruits of the SkunkWorks effort: the ability of the resulting product to attract customers willing to invest time, money or people in building the product or in otherwise furthering the idea. The product must tangibly show positive results that differentiate it from the mainstream product line; if it is to thrive over existing external and internal competitors, it must demonstrate distinguishing market superiority. Directly moving new ideas into the business units rarely works. As a practical matter, this evaluation of success and the ensuing steps to act on it happen at unusual places in the management structure: at a higher level of management, in an organization that has venture funding, or by using the leverage that marketing can bring from customer needs statements and customer commitments. However, the technology's chance of long-term success is much higher if the skunkworks team includes developers who also have product responsibilities in existing products. They can become seeds for new development teams for the new products or, if they are very lucky, they can be conduits for introduction of the new technology into development organizations. Therefore, this pattern also depends on giving some small set of interested developers some limited amount of time to work with the SkunkWorks team in a GateKeeper capacity. 

The SkunkWorks organization itself rarely can take a product all the way into production. It usually lacks the infrastructure, and sometimes the skill set, to build a solid product. This phenomenon is at the root of many well-known stories about large companies not being able to capitalize on their greatest inventions. 

If the idea succeeds, the team should reap the benefits of the idea. The organization subsidizes some of the risk of the team under the sponsorship of a PatronRole, so that the risk-takers are guaranteed some minimum level of security even if they fail. However, they are not guaranteed the same level of rewards as people who succeed in lower-risk ventures; see CompensateSuccess. 

✥ ✥ ✥

This pattern is a bit different from BuildPrototypes. Prototyping is one strategy towards running a SkunkWorks; however, a SkunkWorks project may just buy an existing product and integrate it with existing products or market it differently without doing any prototyping. 

This pattern does not integrate with the other scheduling and organizational structures in the pattern language because it's a decoupled effort. The effort should evolve into a product over time and eventually incorporate patterns like SizeTheSchedule and SizeTheOrganization, but only after it's on its feet and has proven itself. 

It is important that the SkunkWorks be organizationally separate from the mainline organization. This allows so-called disruptive technologies to flourish within the company. (For further information on disruptive technologies, see works by Clayton Christiansen, professor at Harvard [BibRef-Christianson1997].) 

Though it's clear how SkunkWorks fit into a large organization, it can work on a smaller scale in small organizations as well. A couple of team members can develop innovative ideas "in the margins" as a side activity. This may be a particularly good outlet for employees whose skills are high enough that they seek challenges beyond those offered by day-to-day business.

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