The debate between shareholder primacy and stakeholder theory concerns the legal obligations of corporate directors. Introduction A corporation is never just a machine for making money. It is a legal institution, a social system, and a vehicle for allocating power, risk, and responsibility. That is why one of the most important debates in corporate governance continues to divide scholars, executives, regulators, and investors: should corporations exist primarily to maximize shareholder value, or should they balance the interests of all the people and institutions affected by their actions? This debate is commonly framed as shareholder primacy vs. stakeholder theory. Shareholder primacy says the corporation's central obligation is to its owners, the shareholders. Stakeholder theory says the corporation owes duties to a wider circle of affected parties, including employees, customers, suppliers, creditors, communities, and sometimes society at large. This is not a purely academ...
Agile project management examined: its roots in iterative software development, the 2001 Manifesto’s four values and twelve principles, the shift from detailed upfront planning toward incremental value delivery, and the challenges of applying Agile at organizational scale.
By Kateule Sydney — Researcher and Writer | Last Verified: 2026-10-03 | Published by Kat-Syd Resources Hub
Agile project management: iterative delivery, values, and the challenge of scale
Table of Contents
Chapter 1 — Agile Is an Approach Grounded in Values and Principles
One of the most persistent misunderstandings about Agile is that it is a single methodology that an organization can simply implement. A more accurate description is that Agile originated in software development and has subsequently influenced project and product-management practices in other sectors. It is grounded in a set of values and principles rather than a prescribed procedure. The Manifesto for Agile Software Development provides the original statement of those values and principles; particular frameworks and methods provide different ways of putting them into practice.
Scrum, Kanban, Extreme Programming (XP), Crystal, Feature-Driven Development (FDD), and other approaches should therefore not be treated as identical implementations of one prescribed Agile method. They differ substantially in their practices, roles, engineering techniques, governance, and degree of prescription.
Academic literature also cautions against treating Agile as having one universally accepted definition. A 2024 systematic literature review examined 80 academic papers and found substantial variation in how Agile project management is defined and applied beyond software development. Agile practices have subsequently been studied in areas including construction, manufacturing, banking, energy, education, and government.
Definition. For software development, Agile can be understood as an approach that emphasizes iterative and incremental delivery, close stakeholder collaboration, frequent feedback, technical quality, and responsiveness to changing requirements. The original Manifesto was specifically about developing software, although its values and principles have subsequently influenced project and product management more broadly.
This distinction matters when comparing Agile with formal project-management standards. The PMBOK Guide is a project-management standard and body of guidance, whereas the Agile Manifesto is a declaration of values and principles for software development. They operate at different conceptual levels. That distinction between a standard and a value system matters here because the two documents answer different questions.
The Agile Manifesto states four preferences:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The wording is important. The Manifesto does not say that the items on the right are worthless. It explicitly says that they have value, while assigning greater value to the items on the left. Consequently, Agile does not mean eliminating processes, documentation, contracts, or plans. It means giving greater priority to people and interactions, working product increments, collaboration, and adaptation when those priorities conflict with rigid adherence to established processes.
The Manifesto also contains twelve principles, including early and continuous delivery of valuable software, welcoming changing requirements, frequent delivery of working software, close cooperation between business and developers, motivated teams, technical excellence, simplicity, and regular reflection on how to become more effective.
Carry forward: Agile is best understood as a family of approaches grounded in shared values and principles, not as one universal procedure. Frameworks and methods provide different implementations and should be selected and adapted to context.
Chapter 2 — The 2001 Manifesto Consolidated Earlier Practice
The Agile Manifesto is often described as the beginning of Agile. Historically, that is too simple. The Manifesto was a major consolidation point for software-development approaches that had already been developing during the 1990s.
According to the Manifesto’s own history, seventeen people met at The Lodge at Snowbird in Utah from February 11 to 13, 2001. Participants represented or were associated with approaches including Extreme Programming, Scrum, Dynamic Systems Development Method (DSDM), Adaptive Software Development, Crystal, Feature-Driven Development, and Pragmatic Programming.
The meeting therefore did not create all of the practices from nothing. It produced a concise statement of common values around which practitioners from different approaches could agree.
What the Manifesto Did, and Did Not, Do
The Manifesto did not establish a single implementation method. It also did not eliminate the differences between the approaches represented by its participants. Instead, it articulated common priorities. This distinction explains why Agile subsequently developed into a broad family of approaches rather than a single standardized methodology.
For example:
- Scrum provides a lightweight framework for developing and sustaining complex products, with defined accountabilities, events, and artifacts
- Extreme Programming (XP) places particular emphasis on software-engineering practices such as test-driven development, pair programming, and continuous integration
- Crystal developed as a family of approaches intended to vary according to factors such as team size and system criticality
- Feature-Driven Development (FDD) organizes development around features and domain modeling
- DSDM developed a more structured approach to iterative delivery and emphasized constraints such as time and cost
These approaches share important Agile ideas, but they are not interchangeable. Calling all of them simply the Agile methodology obscures meaningful differences in how work is organized.
Carry forward: The 2001 Manifesto was a consolidation of shared values and principles among practitioners from several approaches. It was not the invention of iterative software development, nor was it a detailed operating manual for project management.
Chapter 3 — Agile Changes How Scope, Time, Cost and Value Are Managed
The claim that Agile simply inverts the iron triangle is too absolute. A better explanation is that many Agile approaches deliberately make scope more adaptable while using time, capacity, and other constraints to structure iterative delivery.
The traditional project-management triangle is commonly expressed through scope, schedule, and cost. In practice, however, projects can choose different constraints depending on their circumstances. There is therefore no universal rule that traditional projects always fix scope while Agile projects always fix time and cost.
In an Agile environment, a team may use fixed-length iterations and a relatively stable team capacity while allowing the content of each iteration to change as priorities and evidence change. This is a common pattern, not a universal law of Agile.
Jim Highsmith, one of the Manifesto authors, described a related Agile triangle in which value, quality, and constraints receive greater attention. The constraints remain relevant; they include traditional project parameters such as scope, schedule, and cost. PMI’s interview with the Manifesto authors also records Highsmith’s description of a movement from the traditional iron triangle toward value, quality, and constraints.
What Changes in Practice
- Scope can become a managed variable — product backlogs and priorities can change as new information emerges
- Time can be deliberately time-boxed — Scrum, for example, uses fixed-length Sprints
- Team capacity can provide a practical cost constraint — a stable team working over repeated iterations creates a more predictable short-term capacity envelope
- Value becomes an important decision criterion — teams prioritize work according to expected usefulness and stakeholder needs rather than simply completing everything listed in an original specification
- Quality is not supposed to be the variable sacrificed to maintain speed — Agile principles explicitly emphasize technical excellence and good design
Thus, the important distinction is not that Agile abolishes project constraints. It changes how teams respond when uncertainty makes detailed long-range prediction unreliable. A project with a fixed launch date, for example, may protect the date by changing which features are included in the release. A project with a regulatory scope requirement may have less freedom to vary functionality and may require a different combination of Agile and predictive practices.
Carry forward: Agile does not eliminate the scope-schedule-cost relationship. It commonly uses iterative delivery and prioritization to allow some aspects of scope and requirements to adapt as knowledge improves.
Chapter 4 — The Challenge of Scaling Agile
The strongest criticism of Agile should not be expressed as Agile works at small scale and fails everywhere else. That statement is too broad for the evidence. A more defensible conclusion is that scaling Agile introduces coordination, governance, architecture, dependency, culture, and contracting challenges that are less prominent in a single small team.
The original Agile practitioners themselves acknowledged that early Agile projects tended to be smaller and co-located, while later organizations applied Agile to much larger and more distributed environments. Jim Highsmith described that evolution in a PMI interview with several Manifesto authors. Contemporary research also shows that Agile project management is no longer restricted to small software teams. A 2024 systematic literature review identified research on Agile across numerous industries, while a 2025 systematic literature review of Agile software-development research examined 208 relevant articles published between 1999 and 2024, including research on large-scale Agile implementations.
Three Important Scaling Challenges
Coordination and dependencies. When several teams work on interdependent systems, local team autonomy does not remove the need for coordination. A 2026 field study involving a Fortune 500 company examined a voluntary transition from plan-driven development toward Agile practices in a system-of-systems environment. The researchers found that greater development-platform variety across applications was negatively associated with teams’ use of Agile practices, and that the effects of centralized versus decentralized decision rights depended partly on inter-application dependency and platform variety. This is important evidence, but it should not be presented as proof that Agile itself fails at scale. It is evidence that technical and organizational dependencies can affect Agile adoption in large system environments.
Culture and organizational conditions. Agile emphasizes collaboration, empowered teams, feedback, and adaptation. Those practices interact with organizational culture and management structures. A 2024 systematic literature review on organizational culture and Agile project management found that hierarchical cultural characteristics such as rigid structures and formalized communication can create difficulties for Agile projects, while group-oriented cultural characteristics associated with empowerment and teamwork can support Agile practices. This does not mean that an organization must abandon hierarchy to use Agile. It means that the way authority, communication, decision-making, and collaboration are organized can affect how Agile practices function.
Contracting and funding. Agile’s emphasis on evolving requirements can create tension with contracts that attempt to specify detailed scope, schedule, and price in advance. But it is too strong to say that fixed-price contracts prohibit customer collaboration. Research on Agile contracting shows that fixed-price arrangements can be adapted to Agile projects. A systematic review published in 2026 found that traditional funding and contracting approaches can be suboptimal for Agile software projects, while alternative approaches can support flexibility and collaboration. The review also found that alternative arrangements introduce their own cultural, structural, and scope-management challenges. Therefore, the more accurate statement is that some conventional contractual structures can constrain Agile’s flexibility, but contractual design can be adapted rather than simply abandoned.
Adoption Versus Transformation
Another recurring issue is the difference between adopting Agile practices and changing organizational behavior. Andrew Hunt, one of the Manifesto authors, told PMI that organizations had adopted some improved software-development practices without necessarily adopting what he regarded as true agile behavior. Highsmith similarly described Agile as involving both doing Agile and being Agile, with the latter requiring a different management style. This distinction is useful because ceremonies alone do not establish the values described by the Manifesto. An organization can hold daily meetings, maintain a backlog, and work in iterations while retaining centralized decision-making, weak customer feedback loops, and rigid requirements.
Carry forward: Scaling Agile is primarily a coordination and organizational-design problem as much as a process problem. The evidence supports caution about assuming that practices developed in one context will transfer unchanged to another.
Case Study
The Spotify case is useful, but it needs to be described carefully. The material commonly called the Spotify Model was not originally presented by its authors as a universal framework that other organizations should copy. Treating it as a universal framework, however, goes beyond what the original evidence supports.
In 2012, Henrik Kniberg and Anders Ivarsson published Scaling Agile @ Spotify with Tribes, Squads, Chapters and Guilds. The paper described how Spotify was organizing its development teams at that point in its growth. The structure included squads (small, cross-functional teams organized around product work), tribes (groups of squads working in related areas), chapters (groupings of people with related skills within a tribe), and guilds (communities of interest that could cross organizational boundaries).
The original document contains an important warning that is frequently lost when the model is reproduced elsewhere: it described a snapshot of Spotify’s current way of working and a journey in progress, not a journey completed. That distinction is central. The document is evidence of how Spotify organized itself at a particular point in time. It is not evidence that every organization should reproduce the same structure.
The Spotify material provides evidence that one rapidly growing software organization experimented with combining autonomous teams with mechanisms for coordination and professional communities. The Spotify material is not, by itself, evidence that the structure is universally effective or ineffective. It is primarily a documented case of how Spotify organized its development work at a particular point in its evolution. Spotify’s own published engineering material from the period illustrates the importance of autonomy and technical mechanisms for handling dependencies. For example, Spotify described autonomous squads and practices intended to allow teams to continue working even when dependencies existed between teams. Subsequent accounts of the Spotify approach emphasize that the organization continued to evolve and that the 2012 description should not be interpreted as a permanent blueprint.
The strongest lesson from the Spotify case is not that the Spotify Model failed. Nor is it that the Spotify Model works. The evidence supports a narrower conclusion: an organizational structure developed for one company’s circumstances should not automatically be treated as a universal Agile framework. The original authors themselves provided the basis for this interpretation by describing the model as a snapshot of Spotify’s evolving way of working.
For organizations studying the case, the useful questions are contextual rather than procedural. What coordination problem were the squads intended to solve? What decisions could individual teams make independently? What mechanisms connected teams working on related products? How were technical expertise and professional development supported? Which parts of the structure were specific to Spotify’s culture and technology environment? Those questions are more transferable than simply renaming teams squads and creating tribes, chapters, and guilds. That same lesson about context transferring across markets appears in my post on supply chain design and resilience, where the design has to match the environment.
Conclusion
Agile emerged from software-development practice that predated the 2001 Manifesto. The Manifesto brought seventeen practitioners together at Snowbird in February 2001 and expressed four values and twelve principles that became a major reference point for iterative and adaptive software development. Its central contribution was not a detailed project-management procedure. It was a different set of priorities: individuals and interactions, working software, customer collaboration, and responsiveness to change were valued more highly than processes and tools, comprehensive documentation, contract negotiation, and adherence to an initial plan.
In project-management terms, Agile commonly changes how uncertainty is handled. Instead of assuming that every important requirement can be specified accurately before development begins, teams can use short feedback cycles, incremental delivery, and reprioritization to learn during development. This does not remove scope, schedule, or cost constraints; it changes how they are managed.
The evidence supports the use of Agile’s iterative and adaptive logic particularly where requirements are volatile and where learning during development can materially improve the product. But the original Manifesto does not provide a detailed theory of organizational scale. That leaves organizations to develop additional mechanisms for coordination, governance, architecture, dependencies, decision rights, culture, and contracting when applying Agile in larger environments. The evidence on scale is more nuanced than the simple claim that Agile works only for small teams. Agile is now studied and practiced in large and distributed environments, but scaling introduces additional problems involving dependencies, decision rights, technical architecture, organizational culture, contracting, and coordination. The Fortune 500 system-of-systems study illustrates one such interaction between platform variety, dependencies, and Agile adoption.
The strongest counterargument to my position is that Agile has been adopted successfully at scale by many organizations, and that the failures reflect poor implementation rather than a limitation of the framework. I take that objection seriously. There are documented successes in large-scale Agile. Evidence from large-scale environments suggests that coordination mechanisms, technical dependencies, and decision rights can materially affect how Agile practices work at scale. Organizations therefore cannot assume that small-team autonomy will automatically scale without additional organizational and technical mechanisms.
My recommendations follow from that conclusion:
- Treat Agile as an approach grounded in values and principles, not as one universal methodology — choose methods such as Scrum, Kanban, and XP based on the project’s needs, and do not install ceremonies as a substitute for culture
- Select and tailor frameworks and practices according to the project’s context — requirements volatility, customer access, technical dependencies, regulatory environment, and team organization all matter
- Use iterative delivery to manage uncertainty where learning during development can materially improve the product — but do not assume that time-boxing automatically means scope is always flexible or cost is always fixed
- Recognize that scaling introduces coordination and governance problems that require deliberate mechanisms — build the coordination and decision rights before scaling, not after
- Treat the Spotify material as a contextual case study rather than a universal organizational blueprint — the authors themselves described it as a snapshot of a journey in progress
- Do not confuse Agile ceremonies with adoption of Agile values and principles — doing Agile is not the same as being Agile
The central argument of this post is that Agile is a set of values and principles for responding to uncertainty through iterative, collaborative, and incremental development, and the organizational and technical practices used to implement those ideas must be adapted to context.
References
- Beck, K., et al. (2001). Manifesto for Agile Software Development — Agile Manifesto
- Agile Manifesto. History of the Agile Manifesto — Snowbird meeting, February 2001
- Bowles Jacks, M. (2011). Agile: The Authors of the Manifesto Discuss Agile’s Evolution — Project Management Institute
- Dong, H., Dacre, N., Baxter, D., Ceylan, S., et al. (2024). What is Agile Project Management? Developing a New Definition Following a Systematic Literature Review — Project Management Journal
- Lee, J. S., Maruping, L. M., & Keil, M. (2026). Understanding Factors Affecting the Use of Agile Development Practices in System of Systems Environments — Journal of the Association for Information Systems, 27(2), 412–441
- Kniberg, H., & Ivarsson, A. (2012). Scaling Agile @ Spotify with Tribes, Squads, Chapters and Guilds
- Spotify Engineering. Backend Infrastructure at Spotify — Spotify
- Information and Software Technology. (2025). A Systematic Literature Review of Agile Software Development Projects, 182, 107727
- Ngereja, B., & Jørgensen, M. (2026). Alternative Funding and Contracting Approaches Relevant for Agile Software Development — Journal of Systems and Software, 232, 112680
- Vine Journal of Information and Knowledge Management Systems. (2024). How Does Organisational Culture Affect Agile Projects? A Competing Values Framework Perspective, 55(5), 1077–1104
Read Also on Kat-Syd Resources Hub
PMBOK Guide: Origins, Structure & Limits — The PMI standard, the Eighth Edition's principles and domains, and the criticisms of rigidity, tested against PMI documentation and a Trinidad construction study.
Operations Management — The ten decisions, productivity and quality, and operations strategy, tested against Toyota and Safaricom.
Supply Chain Design and Resilience — Network design, risk categories, visibility and resilience strategies tested against Apple and Safaricom.
Written by Kateule Sydney — Researcher and Writer
© 2026 Kat-Syd Resources Hub. All rights reserved.
Kat-Syd Resources Hub — Educational case studies and analytical reference