Organizational Patterns of Agile Software Development
Source: https://accu.org/conf-docs/PDFs_2008/Coplien-20080405OrgPats.pdf ↗
Full text: author page ↗
Coplien's work on organisational patterns predates most of the agile movement and is in many ways deeper than the movement it foreshadowed.
The piece collects patterns observed in high-performing software organisations — patterns like Stable Teams, Patron, Unity of Purpose, Mercenary Analyst — and describes when each applies and when it does not.
For product direction the value is the granularity: instead of prescribing a methodology, Coplien offers a catalogue of patterns that are either present or absent in any team, and that absence is usually diagnostic.
Dense, pattern-oriented, in the tradition of Christopher Alexander. Read for the vocabulary, use the vocabulary afterwards.
Central argument
Coplien argues that agile methods like Scrum are not self-contained innovations but are grounded in a pre-existing body of empirical organizational patterns discovered through social network analysis of real software teams in the early 1990s. His central finding is that process documentation fails — as illustrated by the ISO 9000 case where 80% of work happened under 'documented waivers' — and that focusing on stable roles and their communication structures is a more reliable lever for organizational effectiveness. He demonstrates this by mapping Scrum artifacts and ceremonies directly onto specific organizational patterns (e.g., ScrumMaster as FIREWALLS, Product Owner as PATRON/SURROGATE CUSTOMER), arguing that teams adopting Scrum without these underlying competencies are building on an unexamined foundation.
Critique
The pattern catalogue is derived primarily from large, co-located software organizations of the early-to-mid 1990s — Borland, Bell Labs, telecom — which raises genuine questions about how well the communication intensity metrics and role-coupling findings transfer to distributed, asynchronous, or platform-oriented product organizations. More fundamentally, Coplien's method relies on role-play and social network analysis captured at a point in time, which may reflect the informal power structures that already exist rather than surfacing the organizational changes actually needed. The claim that a communication intensity ratio above 2 signals dysfunction, for instance, is presented as empirically derived but without sufficient detail on sample size, industry variation, or confounding variables to evaluate its generalizability.
Why it matters for product
For a CPO, the most actionable insight is the DISTRIBUTE WORK EVENLY pattern and its communication intensity ratio: if a few roles — typically senior PMs, tech leads, or the CPO themselves — are absorbing a disproportionate share of cross-team dependencies, the bottleneck is structural, not a performance issue, and adding process on top will not fix it. Coplien's mapping of Scrum roles to underlying patterns also reframes common product org failures: a Product Owner who lacks PATRON backing in the executive layer, or a team missing SURROGATE CUSTOMER, will produce predictably dysfunctional sprint dynamics regardless of ceremony compliance. The warning to establish organizational pattern 'competencies' before adopting Scrum is directly relevant when scaling — it suggests that fragile delivery at scale is usually a role-clarity and communication-structure problem, diagnosable before choosing a framework.