Research from social scientist Merrelyn Emery and socio-technical systems practitioner Trond Hjorteland reveals that agile methodologies, despite their democratic aspirations, have largely failed to address the social dimension of software development — producing a fragmented industry characterized by individualism, laissez-faire coordination, and low motivation, all layered on top of unchanged autocratic organizational structures.
The socio-technical critique
Socio-technical systems design (STSD) and Open Systems Theory (OST) provide a framework for understanding why agile often disappoints:
- Joint optimization required — good systems require optimizing both the technical and social subsystems simultaneously; agile overwhelmingly focuses on the technical (the process of building software)
- Individualism at the core — despite emphasis on teams, agile has little grounding in social sciences; cross-functional teams often lack genuine functional redundancy (multi-skilling in STSD terms)
- Missing coordination — agile removed old supervisory structures that handled control and coordination, but only placed control at the individual level; coordination was "more or less left out"
- Laissez-faire as default — the resulting confusion about who supervises, controls, and coordinates what produces worse outcomes than even traditional autocratic structures (DP1)
Survey findings
An industry-wide survey analyzed using rigorous statistical methods (including Fred Emery's Causal Path Analysis) confirmed:
- Agile is predominantly individualistic with little focus on self-managing groups (Design Principle 2 / DP2)
- Teams exist at lower levels within unchanged autocratic/bureaucratic structures
- Lack of coordination contributes more to low motivation than lack of control — what individuals gain in autonomy is more than lost to missing coordination between people and teams
- The balance between autonomy (self-control) and homonomy (sense of belonging) is fundamentally unbalanced
- Only ~3% of survey respondents appeared to work in genuine DP2 organizations
Scaling frameworks as symptom
Scaling frameworks (SAFe, LeSS, etc.) are an ad-hoc response to agile's missing coordination layer, attempting to fill the gap in a top-down manner that contradicts agile's original democratic intent. They were never part of agile itself.
The SAFe problem in practice
Product leadership expert Melissa Perri (author of Escaping the Build Trap) provides a practitioner's perspective on why SAFe fails organizations:
- The product owner role is misunderstood — it originated in Scrum as a developer-facing prioritization role, not a full product management function. Organizations conflate the two, creating "order-takers" who spend 40 hours a week writing user stories for things that already work instead of doing discovery and talking to customers.
- SAFe imposes rigid ceremony on top of dysfunction — rather than addressing the underlying coordination and empowerment gaps that agile left open, SAFe layers on process (PI planning, release trains) that further distances teams from genuine product thinking.
- Certifications substitute for capability — organizations invest in surface-level certifications rather than real training and mentorship from experienced product managers. The result is credentialed but unskilled product owners.
- Digital transformation needs experienced product leaders — large non-tech companies attempting agile/SAFe transformations need people who have actually built products, not just process consultants.
Perri's critique aligns with the socio-technical analysis: SAFe treats the coordination gap as a process problem to be solved with more structure, when it is fundamentally a social design problem requiring genuine empowerment and multi-skilling.
Relevance to AI adoption
This analysis has direct implications for how organizations adopt AI: the same socio-technical blindness that undermined agile — treating technology as more important than human needs, designing teams around tools rather than around people — risks repeating with AI integration. Organizations that never achieved genuine self-management with agile are unlikely to navigate the far more disruptive shift to AI-augmented work without addressing these structural deficits.