Agile and Scrum: Origins, Creators and the Main Ideas

Agile and Scrum describe different things

Agile is a set of values and principles for developing software while learning from experience and adapting to change. Scrum is a framework that gives a team a particular structure for doing complex work. The relationship is close, but the words are not interchangeable. A team can follow agile principles without using Scrum, and simply scheduling Scrum meetings does not guarantee that the team will become adaptable or deliver useful results.

The distinction becomes clearer through a practical question: what should happen when a team discovers that its original plan no longer fits the problem? An agile approach treats the new information as a reason to reconsider the plan. Scrum creates regular opportunities to inspect work and make those adjustments. Neither removes the need for a goal, professional judgement or attention to quality.

Why a different approach was needed

Software projects often begin with incomplete knowledge. Users may struggle to describe a need before they see a possible solution, while developers may discover technical constraints only after trying an implementation. If all requirements are treated as permanently settled at the beginning, a team can faithfully complete a plan that no longer produces the most useful product. Finding that mismatch late makes correction more expensive and disruptive.

The response was not to abandon planning. It was to shorten the distance between making a decision and learning whether it worked. Instead of waiting for one large final delivery, teams could create smaller usable results, seek feedback and update priorities. This reasoning grew through several approaches before the word Agile became their shared label; it did not appear as one person's complete invention on a single day.

Scrum's roots come before the Agile Manifesto

A landmark in the background is a 1986 article by Hirotaka Takeuchi and Ikujiro Nonaka, The New New Product Development Game. Its rugby metaphor helped frame product development as coordinated team movement rather than a simple sequence of handovers. That article concerned product development more broadly; it should not be confused with the later software framework in its fully defined form.

Ken Schwaber and Jeff Sutherland developed Scrum in the early 1990s and jointly presented it at the OOPSLA conference in 1995. They are recognised as its co-creators, while other practitioners also contributed to its development. The first Scrum Guide appeared in 2010. The order matters: Scrum existed before the Agile Manifesto, then became one of the best-known frameworks associated with agile development.

The 2001 meeting that gave Agile a common identity

On 11–13 February 2001, seventeen software practitioners met at Snowbird in Utah. They represented different approaches, including Extreme Programming, Scrum, Crystal and other methods. According to the official account of the meeting, their purpose included finding common ground beyond heavyweight, document-centred development processes. The result was the Manifesto for Agile Software Development, commonly called the Agile Manifesto.

The seventeen signatories were Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland and Dave Thomas. Agile therefore has collective authorship. Scrum's two co-creators were among the signatories, but the larger movement cannot be attributed to them alone.

Four values, with an important qualification

The Manifesto gives greater weight to human collaboration than to rigid reliance on procedures, to functioning software than to exhaustive descriptions, to an ongoing customer relationship than to contractual bargaining, and to adapting when circumstances change rather than mechanically preserving an old plan. These priorities help resolve tensions that teams encounter in real projects. They do not amount to a ban on tools, contracts, documentation or plans.

That qualification is essential. A regulated product may require substantial documentation; a distributed team may depend heavily on tools. The question is whether these things support the work and the people who need its results. The accompanying twelve principles add themes such as frequent delivery, sustainable work, technical care and regular reflection. Agile asks teams to examine how they work, not merely adopt a fashionable vocabulary.

What Scrum adds to those ideas

Scrum organises work around a small team, a shared product direction and repeated periods called Sprints. A Sprint lasts no more than one month. During it, the team works towards a Sprint Goal and creates a usable addition to the product. A shorter cycle limits how long assumptions can remain unexamined, provided the team genuinely inspects results rather than only reporting activity.

The Scrum Guide identifies three accountabilities. The Product Owner is accountable for maximising product value and managing the ordered Product Backlog. Developers create the usable result and organise their work. The Scrum Master helps establish Scrum and improve the team's effectiveness. The Scrum Master is not defined as a manager who assigns everyone's daily tasks, and the Product Owner is one person rather than a decision-making committee.

A working cycle, not just a calendar of meetings

Sprint Planning establishes why the coming Sprint matters, what the team can take on and how it intends to proceed. During the Sprint, the Daily Scrum gives Developers fifteen minutes to inspect progress towards the goal and adapt their plan. The Sprint Review examines the outcome with stakeholders and informs future work. The Sprint Retrospective focuses on improving how the team works together.

These events have different purposes. The Review is not simply an approval gate, and the Retrospective is not an occasion to blame somebody for a difficult week. Likewise, a daily meeting does not become effective merely because people stand up. The connection between observation and action matters more than appearances: when an obstacle or a mistaken assumption becomes visible, the team needs a realistic way to respond.

How the approach looks in an ordinary product

Imagine a team building a learning website. Instead of attempting an entire course platform before showing anything, it might first deliver a small, usable lesson experience. Learners can open a lesson, read its content and mark it complete. Their feedback may reveal that understanding progress is more important than the elaborate dashboard the team originally intended to build first. That discovery can change the order of subsequent work.

This is an illustrative example, not a historical project. It shows two complementary ideas: incremental development adds usable capabilities, while iterative development revisits and improves what has been learned or built. A prototype used only to explore an idea can be valuable, but it is not automatically a finished product addition. In Scrum, work must meet the team's Definition of Done before it counts as part of a completed Increment.

Where other practices and people fit

Agile extends beyond Scrum. Extreme Programming places particular emphasis on software engineering practices; Kanban focuses on managing workflow and limiting work in progress. Teams may also use user stories, estimation techniques or visual boards. Such techniques can support the work, but Scrum does not require user stories, story points or planning poker. Confusing a common recommendation with an official rule makes the framework seem more complicated than it is.

Later teachers and authors helped spread these ideas. Mike Cohn, for example, contributed influential explanations of user stories and agile planning, although he was not a Manifesto signatory. CI/CD belongs to the technical side: frequent integration, automated checks and reliable release processes can support short feedback cycles. It is neither another name for Agile nor a compulsory Scrum component.

What success should actually mean

Agile and Scrum do not promise that every project will be easy or every deadline correct. They make uncertainty something to manage through visible work, feedback and adaptation. That requires conditions beyond the team's meeting room: access to users, clear priorities, the ability to make decisions and a sustainable approach to quality. Changing job titles without changing those conditions can leave the original problems intact.

The useful test is therefore concrete. Can the team discover misunderstandings earlier, respond to evidence and produce something people can use? A busy calendar and a full task board do not answer that question. Understanding the history helps keep the purpose in view: Agile expressed a shared set of priorities, while Scrum offered a framework for putting learning and coordinated delivery into a repeatable rhythm.