What Agile Actually Means: A Beginner's Guide to the Basics

If you have just joined a team that says it "works agile," or you keep seeing the word in job postings, it can sound like a club with its own vocabulary: sprints, standups, backlogs, retros. The good news is that the idea underneath all of it is simple enough to understand in one sitting.

Agile is not a single method, a piece of software or a certificate. It is a way of approaching work when you cannot know everything up front: build a small piece, put it in front of the people who will use it, learn from what happens, and adjust. This guide explains where the idea came from, what its values and principles say, and what iterative, incremental delivery looks like in practice.

Where the word "agile" came from

On February 11–13, 2001, seventeen people met at the Snowbird ski resort in Utah. According to the history page on the Agile Manifesto site, written by attendee Jim Highsmith, they included representatives of Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development and Pragmatic Programming, all looking for an alternative to "documentation driven, heavyweight software development processes."

Before the meeting, these approaches were loosely called "light" methods, a label nobody liked. The group called itself the Agile Alliance and signed a short document, the Manifesto for Agile Software Development.

Agile Alliance's introductory guide, Agile 101, explains the word choice: the authors picked "Agile" because it "represented the adaptiveness and response to change which was so important to their approach." Its one-line definition is worth remembering: "Agile is the ability to create and respond to change."

The four values, in plain English

The Manifesto opens: "We are uncovering better ways of developing software by doing it and helping others do it." It then lists four value statements:

• 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 sentence that follows is the one beginners most often miss: "That is, while there is value in the items on the right, we value the items on the left more." The word is "over," not "instead of." Processes, documents, contracts and plans still matter. Agile simply says that when they conflict with the items on the left, the left side should usually win.

In everyday terms:

• A five-minute conversation often settles what a long ticket thread cannot, but you still need a shared place to track work.
• Progress is best shown by something that works, not by a report saying a project is "80 percent done."
• The people you are building for should be involved throughout, not only at kickoff and sign-off.
• A plan is a tool. When you learn something new, the plan should change.

The twelve principles, grouped

The Manifesto is backed by twelve principles. You do not need to memorize them, but it helps to see the themes.

Deliver value early and often. The first principle says: "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." Another calls for delivering working software "from a couple of weeks to a couple of months, with a preference to the shorter timescale." And "Working software is the primary measure of progress."

Welcome change. Teams should welcome changing requirements, "even late in development."

Put people first. Business people and developers work together daily, projects are built around motivated individuals who are trusted to get the job done, and face-to-face conversation is described as the most efficient and effective way to share information.

Keep it sustainable and well made. Teams should be able to maintain a constant pace indefinitely, pay continuous attention to technical excellence and good design, and value simplicity, which the Manifesto describes as the art of maximizing the amount of work not done.

Let teams organize and improve. The best architectures, requirements and designs emerge from self-organizing teams, and at regular intervals the team reflects on how to become more effective, then adjusts.

Iterative and incremental: how agile actually delivers

Two words describe the mechanics of agile work, and they are not the same thing.

Incremental means the product grows in usable slices. Agile Alliance's glossary describes it this way: "each successive version of the product is usable, and each builds upon the previous version by adding user-visible functionality." It contrasts these "vertical" slices with building one technical layer at a time, for example a database first, then business rules, and only at the end a screen anyone can use.

Iterative means you deliberately revisit and improve work you have already done. The glossary notes that agile projects allow for "planned rework," and that they are usually, though not always, organized into a series of fixed-length iterations.

For example, imagine a small public library that wants an online room-booking form. A plan-everything approach would write a full specification, build for months and launch once. An agile approach might deliver, in the first two weeks, a bare form that sends a request to staff by email. Patrons try it, and the team learns that most requests come from phones. The next slice adds a mobile-friendly availability calendar; a later one adds reminders. Every version is usable, and each one is shaped by what the last one taught.

The payoff: real feedback within weeks instead of months, and the freedom to change direction cheaply.

Agile is the umbrella; frameworks are the tools

You will hear about Scrum, Kanban and Extreme Programming. Agile Alliance describes agile as "an umbrella term for a set of frameworks and practices based on the values and principles expressed in the Agile Manifesto and the 12 Principles behind it."

The 2020 Scrum Guide defines Scrum as "a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems." The May 2025 Kanban Guide defines Kanban as "a strategy for optimizing the flow of value through a process." Both are ways to put agile values into practice; neither is agile itself.

Agile Alliance goes further, calling agile "a mindset informed by the Agile Manifesto's values and principles," and citing Alistair Cockburn's view that a methodology is the set of conventions a team agrees to follow. In other words, every team's version will look a little different, and that is expected.

What it looks like in an ordinary week

Most agile teams, whatever framework they use, share a handful of habits:

• One ordered list of upcoming work, so everyone knows what matters most.
• A short cycle, often one to four weeks, or a continuous flow of small items.
• A visible board showing what is waiting, in progress and done.
• A brief daily check-in among the people doing the work.
• Regular demonstrations of finished work to the people who will use it.
• A regular look back at how the team works, followed by one or two concrete changes.

If you are brand new, a good first week looks like this:

1. Read the Manifesto and its twelve principles.
2. Ask which framework your team uses, and read its official guide.
3. Find out where the work list lives and who decides its order.
4. Ask what "done" means on your team before you call anything finished.
5. Attend a review and a retrospective, and notice how decisions get made.

Our guide to agile events for first-timers walks through each of those meetings step by step.

Key takeaways

• Agile is a way of working that favors learning and adapting over predicting everything up front.
• The Manifesto's four values say "over," not "instead of": plans and documents still have value.
• Incremental delivery means each version is usable; iterative delivery means you revisit and improve.
• Scrum and Kanban are frameworks for practicing agile, not synonyms for it.
• Start small: learn your team's work list, its definition of done and its regular meetings.

Sources

• Manifesto for Agile Software Development (2001)
• Principles behind the Agile Manifesto
• Jim Highsmith for the Agile Alliance, History: The Agile Manifesto (2001)
• Agile Alliance, Agile 101: What is Agile?
• Agile Alliance, Glossary: Incremental Development
• Agile Alliance, Glossary: Iterative Development
• Ken Schwaber and Jeff Sutherland, The 2020 Scrum Guide (November 2020)
• John Coleman and Daniel Vacanti, The Kanban Guide (May 2025)