25 Years of Agile: When Software Development Became Project Management

Agile is still here after 25 years, but its centre of gravity has moved

I have worked on more than a few programmes that described themselves as Agile. Their teams ran two-week sprints, held a daily meeting every morning, managed backlogs in Jira, and presented velocity charts during regular reviews. From the outside, the process looked complete, yet a small change could still take weeks to pass through development, integration testing, security review, and deployment. Releases happened quarterly, shared environments remained permanent bottlenecks, and developers rarely spoke directly with the people using the product. Those programmes had plenty of Agile activity but lacked the ability to change software safely and continuously.

February 2026 marked 25 years since the Agile Manifesto was created at Snowbird, Utah. A quarter of a century is enough time for an idea to leave a professional community, enter the mainstream, become an industry standard, and gradually acquire meanings that differ from its original context. Today Agile is often discussed through sprint planning, story points, Scrum Masters, roadmaps, portfolios, and enterprise transformation programmes. The 2001 document, however, was explicitly titled the Manifesto for Agile Software Development.

That difference is more than wording. Agile was formed by people who designed, programmed, tested, and delivered software. They were looking for an approach better suited to the uncertainty inherent in software development. Over the following 25 years, the emphasis in many organisations shifted from creating a professional software-development team to managing that team through a new process model.

This is not an argument against project management. Large software programmes still require budgets, plans, risk management, dependency coordination, and accountability. The problem begins when the management layer is treated as the whole of Agile while engineering capability becomes an optional concern to be addressed later.

Agile grew out of the frustration of software practitioners

During the 1990s, many organisations developed software through processes dominated by upfront plans and documentation. Requirements were expected to become complete before development, architecture was designed for the whole system, and analysis, implementation, and testing were separated into distinct phases. A change introduced after the baseline had been approved often had to pass through a formal control process.

This structure created a sense of certainty for management, but software rarely evolves in a certain environment. Customers often understand what they need only after using a real version. Developers discover many constraints only when integration begins. Markets, regulations, infrastructure, and user behaviour can all change before the original plan reaches its end.

Alongside these heavyweight processes, several lighter development methods appeared: Extreme Programming, Scrum, Crystal, the Dynamic Systems Development Method, Adaptive Software Development, Feature-Driven Development, and other pragmatic approaches. Their practices were not identical, but they shared an effort to shorten feedback loops, put working software in front of users earlier, and give delivery teams more agency.

From 11 to 13 February 2001, 17 representatives of these approaches met at the Snowbird resort in Utah. They did not create a single framework, a certification system, or a standard process for every project. Their meeting produced four value statements and 12 principles intended to guide software development.

The opening of the Manifesto says that the participants were uncovering better ways to develop software by doing it and helping others do it. The phrase “by doing it” matters. Agile did not begin as a management theory imposed on teams from outside. It was distilled from the experience of people building software and living with the consequences of technical decisions every day.

The 17 people behind the Agile Manifesto

Calling all 17 participants “software engineers” does not capture the full variety of their roles. The group included programmers, testers, architects, consultants, authors, and creators of development methods. The more important commonality is that most had deep practical experience and had already built or applied lightweight approaches before the word Agile was chosen.

• Kent Beck — Originator of Extreme Programming, an important advocate of Test-Driven Development, and co-creator of JUnit.
• Mike Beedle — An early Scrum practitioner who combined Scrum with XP and co-authored Agile Software Development with Scrum.
• Arie van Bennekum — A DSDM practitioner, facilitator, and coach focused on connecting business needs with software delivery.
• Alistair Cockburn — Creator of the Crystal family of methods and a major influence on the practical use of use cases.
• Ward Cunningham — Creator of WikiWikiWeb and a contributor to CRC cards, the patterns community, and Extreme Programming.
• Martin Fowler — Author of Refactoring and a leading voice on software design, evolutionary architecture, and people-oriented methods.
• James Grenning — Embedded-software specialist, inventor of Planning Poker, and author of Test-Driven Development for Embedded C.
• Jim Highsmith — Creator of Adaptive Software Development and an influential writer on leadership under uncertainty.
• Andrew Hunt — Co-author of The Pragmatic Programmer, developer, and consultant known for method-independent engineering practices.
• Ron Jeffries — One of the first Extreme Programming coaches and co-author of Extreme Programming Installed.
• Jon Kern — Software architect, contributor to Feature-Driven Development, and advocate of frequent, tangible, working results.
• Brian Marick — Programmer and testing consultant who helped shape the early ideas of Agile Testing.
• Robert C. Martin — Software engineer, consultant, and influential author on design, code quality, and professional responsibility.
• Steve Mellor — Co-developer of the Shlaer–Mellor method and a key author in Executable UML and model-driven development.
• Ken Schwaber — Co-creator of Scrum and an experienced developer, product manager, and software-development consultant.
• Jeff Sutherland — Co-creator of Scrum and a former CTO and VP of Engineering across several technology companies.
• Dave Thomas — Co-author of The Pragmatic Programmer and a developer who emphasised that people’s capability and involvement matter more than methodology.

This list restores the right context around Agile. It was not created by a group of project managers searching for a better reporting mechanism. The people at Snowbird brought experience in programming, testing, object-oriented design, patterns, refactoring, iterative delivery, facilitation, and team organisation. They disagreed on method, but they recognised a shared problem: process could not substitute for the capability of the people building the product.

The four values through a software-development lens

The four values use the structure “X over Y.” The items on the right still matter, but the items on the left receive greater priority when the two come into conflict, creating a system for guiding decisions rather than an absolute rulebook. Processes, tools, documentation, contracts, and plans remain necessary in many contexts. A banking platform needs control evidence, a healthcare system needs traceability, and a government programme needs contracts and governance. Those mechanisms should support product development and risk control rather than making compliance with the mechanism the primary goal.

Individuals and interactions over processes and tools

Processes and tools help a team maintain consistency. Source control, issue tracking, CI pipelines, coding conventions, and a definition of done all have value. None of them, however, can resolve a difference in domain understanding, an ambiguous architectural decision, or an overlooked dependency between teams by themselves.

I once worked with a programme where three teams integrated through a shared set of APIs. The process required every change to have a ticket, an updated OpenAPI specification, and an approval before merge. The management board showed every step as complete. During integration, one team discovered that it interpreted the status field as the state of a transaction, while another treated it as the state of reconciliation. The schema was valid, the pipeline was green, and the documentation existed. The system was still wrong because the people responsible for the two domains had not developed a shared understanding.

A 45-minute design session involving developers from both sides and a domain expert could resolve more than several days of ticket exchanges. The teams would still update the API contract, tests, and Architecture Decision Record afterwards. The difference is that process and documentation would preserve an understanding that had already been formed rather than attempting to replace it.

The first value also speaks directly to technical autonomy. A team cannot be self-organising if every decision—from module boundaries and API design to testing strategy—is imposed by an external group. Governance remains necessary in large systems, but effective governance defines guardrails, quality attributes, and mandatory constraints. Decisions inside those boundaries should stay with the people closest to the problem.

The daily meeting provides a simple example. When a team uses it to coordinate work, discover dependencies, and adjust its plan, process is supporting interaction. When each person reports status to a manager in turn, the same event has become a monitoring mechanism. The form is identical; the value is not.

Working software over comprehensive documentation

Documentation describes what we believe the system will do, while working software reveals what it actually does. The gap between those two is where many projects fail. A requirements document can describe a loan-approval flow through dozens of fields and decision branches. Business stakeholders, analysts, developers, and testers may all read the same paragraph while imagining different behaviour. Once a thin vertical slice runs against representative data, those differences become visible: users need a save-draft step that the document never mentioned, an automated rule does not apply to a special customer segment, or the response time of an external service makes the designed interaction unusable.

Working software does not mean a demonstration screen that succeeds only on the happy path. An increment creates valuable feedback only when it is sufficiently close to real conditions: it includes the relevant integrations, representative data, security controls, logging, and a repeatable deployment path. When a team demonstrates on local machines every sprint but needs two months to move code into a production-like environment, the organisation has iteration at the presentation layer, not agility in delivery.

In regulated systems, comprehensive documentation remains a real deliverable. Architecture descriptions, data lineage, threat models, test evidence, and operational runbooks may be mandatory. The strongest documentation, however, evolves with the software and is verified by it. A deployment diagram that no longer reflects the pipeline creates false confidence. An API specification enforced by contract tests has more value than an approved document that has drifted away from the implementation.

This value implies specific engineering capabilities: automated testing, continuous integration, reproducible environments, incremental database migration, observability, and deployment automation. Without them, “working software every few weeks” becomes a promise fulfilled through overtime and risk.

Customer collaboration over contract negotiation

Contract negotiation in the Manifesto is not limited to legal contracts. It also describes a relationship in which each group defines its boundary of responsibility as tightly as possible. Business writes requirements, analysts convert them into user stories, developers implement the acceptance criteria, and testers verify the test cases. When the product fails to solve the real problem, every group can prove that it completed its assigned work. That structure optimises local accountability while losing accountability for the shared outcome. In a case-processing system, a requirement may state that an application without income information must be rejected. Developers can implement the rule exactly and all tests can pass. When operations use the first version, they explain that applications from certain partner channels do not yet contain income data at intake and should enter a manual verification queue. The team has implemented the words correctly while building the wrong business behaviour.

A short collaboration loop with operations changes both functional design and architecture. The system no longer has only accepted and rejected states; it needs a pending-verification workflow, an audit trail, processing permissions, and a timeout policy. This is why developers and architects need access to business context rather than receiving a list of tickets decomposed through several layers of intermediaries.

Customer collaboration does not mean that customers can change everything without considering cost. A mature partnership makes trade-offs explicit. When business wants a new rule in the nearest release, the team should explain the effects on security, data migration, testing, and other commitments. Both sides make the decision together instead of one side issuing a request and the other merely estimating it.

From an architecture perspective, collaboration improves decisions because the team learns what genuinely varies in the domain. A pricing rule that changes weekly should be isolated from the core transaction flow. A process specific to one market should not complicate the whole domain model. This knowledge rarely exists in full inside a document signed at project inception; it develops through feedback with the people using the product.

Responding to change over following a plan

A plan is created from limited information at a particular moment. At the beginning of a project, we usually know the least about the system while being asked to make the longest commitments. Agile does not remove planning; it treats a plan as a hypothesis to be updated when new information appears.

I worked on a project whose initial architecture assumed that every user would authenticate through one identity provider. Several months later, the programme expanded into a new market with different residency and identity requirements. If the architecture baseline had been treated as immutable, the new requirement would have become an expensive exception. Because authentication had been separated from the business domain behind a clear boundary, the change still required effort but did not force the team to rewrite the whole system.

Responsiveness to change therefore does not live only in backlog refinement. It is determined by the structure of the codebase, coupling, meaningful automated tests, observability, and the reliability of the deployment pipeline. A Product Owner can reorder a backlog in minutes. If a small business-rule change touches ten services and requires three weeks of manual regression testing, the organisation is not meaningfully agile.

Architecture must avoid two extremes here. Designing the entire future upfront creates abstractions that have not been validated. Ignoring architecture makes each new change increase coupling. A more effective approach identifies important quality attributes, creates boundaries around volatile domain areas, delays reversible decisions, and improves the design continuously as the team learns.

Responding to change does not mean undisciplined change. Teams that adapt well usually have stronger discipline: trustworthy automated tests, technical review, feature flags, backward-compatible APIs, migration plans, and rollback mechanisms. Engineering discipline makes change routine instead of turning every change into a crisis.

Original Agile had an explicit engineering foundation

Read only as slogans, the four values can look like a broad management philosophy. The 12 principles behind the Manifesto make the scope more concrete. They call for early and continuous delivery of valuable software, frequent delivery of working software, working software as the primary measure of progress, a sustainable pace, daily collaboration between business and developers, projects built around motivated individuals, continuous attention to technical excellence and good design, and architecture and design emerging from self-organising teams. These principles describe the operating capability of a software-development team, where technical excellence keeps the cost of change manageable rather than serving as decoration to be added when the schedule permits. Good design allows the team to continue delivering after sprint 20 without being slowed by its own codebase. Sustainable pace is also more than an employment policy; it prevents overtime from hiding unstable build, test, and release systems.

Original Agile was also not synonymous with one methodology. The Snowbird group did not select Scrum, XP, or Crystal as the standard. They retained common values because each product context is different. A startup searching for product–market fit does not need the same governance model as a national payment platform. An embedded system with long hardware cycles cannot release like a web application. Values guide decisions, while practices must adapt to the environment.

How Agile gradually became project management

The shift did not happen in a single moment, and it cannot be blamed on one profession. Once Agile demonstrated its appeal, large organisations looked for ways to adopt it at scale. For an idea to enter an enterprise, it is normally translated into roles, processes, artefacts, maturity models, training programmes, and assessment criteria. That response is understandable in organisations coordinating hundreds or thousands of people, but the easiest parts of Agile to package are often not the parts that directly create agility.

Ceremonies are easier to deploy than engineering capability

An organisation can introduce two-week sprints by changing its calendar. It can create a backlog, appoint Product Owners, recruit Scrum Masters, and move work onto a board in a relatively short period. Building a reliable test suite, decomposing a monolith, automating deployment, improving observability, or developing the team’s design capability takes months and sometimes years.

Transformation programmes therefore tend to begin and end with what is visible. Leadership sees more ceremonies, more dashboards, and a new role structure. The codebase, release process, and dependencies remain unchanged. The organisation has replaced its management vocabulary without changing its ability to develop software.

What is easy to measure displaces what matters

Velocity, story points, sprint completion, and utilisation produce clear reporting data. They can help a team plan within a limited context, but they become dangerous when used to compare teams, assess individuals, or commit output to management.

Once velocity becomes a target, story points lose their original purpose. When utilisation must remain close to 100 percent, teams lose the capacity to address technical debt, help one another, or learn the domain. When ticket completion is treated as progress, small and easily closed items receive priority over an architectural bottleneck with long-term impact. Working software was intended to be the primary measure of progress, but in many organisations that role has gradually been replaced by completion of the sprint plan.

Certification and frameworks create a scalable market

Deep engineering capability cannot be validated after a short course. The ability to design for change, refactor safely, or build a reliable delivery pipeline develops through extended practice and feedback. Roles, events, artefacts, and vocabulary, by contrast, can be standardised into training material, examinations, and certificates.

Once Agile became a market for training, consulting, and transformation, it needed repeatable products. New frameworks, certification levels, and operating models allowed that market to continue growing. This does not make every course or framework useless. They can provide a shared language and help organisations begin. The risk appears when framework completion is treated as proof that the organisation has become Agile.

Scrum became a synonym for Agile

Scrum provides an accessible framework for managing work: a Product Backlog, Sprints, a Product Owner, a Scrum Master, and regular events. It solves part of the coordination problem and creates a feedback rhythm. Scrum does not prescribe how to design code, automate tests, manage architecture, or deploy software.

When Scrum is adopted without corresponding engineering practices, a team may produce a new increment every sprint while internal quality declines. The first sprint moves quickly, the tenth begins to slow, and after a year much of the team’s time is spent on regressions, dependencies, and environment failures. The management framework continues to run on schedule while the product’s ability to change deteriorates, so a team can practise Scrum diligently and still fail to be Agile in the original sense.

Agile transformation is often imposed from outside the team

The first value places individuals and interactions above processes and tools, yet many transformation programmes begin by imposing a standard process across teams. Meeting structures, ticket formats, estimation scales, and reporting lines change before teams can identify the real bottlenecks in their delivery flow. When transformation is measured through framework compliance, teams learn how to present compliance: retrospectives become safe and low-impact, estimates are adjusted to match expectations, and problems such as shared databases, manual deployment, unstable tests, or unclear architecture ownership remain outside the conversation. This command-and-control rollout weakens the very capacity for local adaptation that the programme is intended to create.

The Agile shell and the real capability to change

After years of working with enterprise systems, I often separate two layers when assessing an organisation’s agility. Coordination agility is the ability to plan in short horizons, visualise work, adjust priority, and coordinate stakeholders; Scrum, Kanban, backlogs, and ceremonies support this layer reasonably well. Technical agility is the ability to change code, data, infrastructure, and architecture quickly enough while keeping the system stable, supported by modularity, automated tests, CI/CD, observability, evolutionary design, ownership, and developer skill.

Many organisations invest heavily in the first layer because it is visible, while expecting the outcomes of the second. They change the backlog frequently and then become frustrated that delivery cannot keep up. Teams are asked to increase velocity while integration testing takes three days, a release needs 12 approvals, and a schema change must be synchronised across six systems. Another ceremony rarely solves that problem because the bottleneck is in the architecture and delivery system.

I once saw a programme with eight squads, complete Product Owner and Scrum Master coverage, and a carefully managed roadmap. All services, however, had to integrate in one shared environment, contract tests were almost nonexistent, and every deployment required manual work by a separate operations team. Each squad completed its sprint scope but waited weeks for end-to-end verification. Squad velocity looked healthy while system lead time continued to grow.

The programme eventually shifted its attention to isolated test environments, contract testing, deployment automation, and domain-based ownership. The number of ceremonies did not increase, but the time required to move a change into a real environment fell substantially. That is closer to the goal of original Agile: improving the ability to turn feedback into working software.

The role of a Solution Architect in an Agile team

Agile architecture is often interpreted through two extremes: either architecture is unnecessary because design will emerge, or the architect must complete the whole architecture before development begins. Both approaches ignore the continuous learning inherent in software development.

In an Agile environment, architecture should create optionality—the ability to change direction at a controlled cost. That does not require predicting every future requirement. It requires recognising decisions that are expensive to reverse, important quality attributes, and boundaries that need protection.

A Solution Architect should not only produce a target architecture. The architect must remain close enough to delivery to see where design enables change and where it creates a bottleneck. Some decisions should be standardised across a programme, such as identity, audit, encryption, or observability. Others should remain with the team, such as internal module structure or the testing approach within a service. Distinguishing between these classes of decision is an important part of adaptive architecture.

Architects also need to protect technical work from being dismissed as “not delivering business value.” Correcting a broken boundary, improving build time, or adding contract tests may not create a new screen, but it can reduce the cost of many later changes. Technical investment should still not be defended through generic slogans. Teams should identify the concrete bottleneck, the existing risk, and the expected outcome.

In my experience, effective Agile architecture appears as short decision loops: clarify a quality attribute, test a vertical slice, observe real behaviour, record an important decision, and adjust. Documentation continues to exist, but it lives with the code and changes as understanding changes. Governance continues to exist, but it focuses on risk and outcomes rather than checking whether every template has been completed.

Putting development back at the centre of Agile

Scrum Masters, project managers, certificates, and frameworks can all be useful in the right context, provided that they support a team creating a product rather than substitute for the capability to create it. An organisation can start by changing the questions asked during reviews. Instead of asking only how many story points were completed, examine how long an idea takes to move from decision to production. Instead of checking only the sprint commitment, inspect deployment failure rate, recovery time, manual steps, and dependencies that force teams to wait. Instead of evaluating documentation by page count, ask whether a new developer can understand a boundary, operate a service, and change a rule safely.

At team level, a few questions often reveal more than a maturity model:

• Can the team move a small change into production within a few days?
• Can developers change an important business rule without weeks of full-system regression testing?
• Do the people writing the code hear the problem directly from users or domain experts?
• Does the retrospective produce real changes to build, test, and release systems, or only generic action items?
• Is the architecture reducing the cost of change, or forcing every change through more teams?
• Do metrics reflect customer outcomes and delivery flow, or merely activity?

The answers do not need to be perfect. Every system has constraints, especially in regulated industries or multi-vendor programmes. The important step is to look at the place where agility is actually created. A team is not more adaptive simply because its backlog can change every day. It is more adaptive when it can turn that change into working software without allowing quality to deteriorate.

Agile did not fail; we chose the easier parts

Agile has helped the software industry change in many positive ways over 25 years. Iterative delivery, cross-functional teams, continuous feedback, and product thinking are now familiar ideas, so the goal is not to return to 2001 or reproduce an old method unchanged.

What deserves examination is the shift in emphasis. Agile began with software practitioners searching for better ways to build products under uncertainty. As it became mainstream, it was packaged into roles, events, artefacts, frameworks, and certifications. The management layer was easier to explain, purchase, and measure. The engineering layer was harder because it required time, practice, and deep changes to both the codebase and the organisation.

I do not believe project management simply “stole” Agile. Large organisations will always need good management. Good management, however, does not automatically create an Agile team, just as a sprint board does not create working software. Agile exists only when the people building the product have the skill, agency, and technical foundation to respond to what they learn.

The 2001 Manifesto did not promise that every project would move faster after changing its process. It established priorities: people before mechanisms, working software before evidence on paper, collaboration before defensive responsibility boundaries, and adaptability before loyalty to an outdated plan.

A quarter of a century later, those priorities remain relevant. The difficult part is not remembering the four lines of the Agile Manifesto. The difficult part is building an organisation that trusts developers, maintains engineering discipline, and stays close enough to customers to live by them.

References

• Manifesto for Agile Software Development, 2001.
• Principles behind the Agile Manifesto, 2001.
• History: The Agile Manifesto, Agile Manifesto Authors.
• Authors: The Agile Manifesto, Agile Manifesto Authors.
• Bản tuyên ngôn Agile – lịch sử hình thành Agile, Atoha, 2020.
• The State of Agile Software in 2018, Martin Fowler.
• Robert C. Martin, 2018 Clean Coder Blog essay on the commercialisation and changing focus of the Agile movement.