New to Agile or Scrum? Start Here

Agile helps teams deliver value sooner, learn faster, and adapt when plans change. Use this guide to understand what agile is, how it differs from Scrum, when agile helps, and where to go next if you are just getting started.

Who This Guide Is For

This guide is for people who are new to agile, new to Scrum, or trying to make sense of terms they have heard but not fully understood.

It is especially useful for:

People joining an agile or Scrum team for the first time
Leaders whose teams are being asked to “be more agile”
Stakeholders who work with Scrum teams and want to understand how they operate
Product owners, Scrum Masters, managers, analysts, designers, testers, and developers looking for a clearer starting point
Teams trying to understand whether agile is right for their work

If you already know the basics and want a deeper explanation of Scrum, start with The Scrum Framework. If you are trying to improve requirements and backlog items, start with User Stories.

In This Guide

This guide explains what agile is, how agile differs from Waterfall and Scrum, why agile uses short feedback cycles, and when agile is most useful.

You will also learn what changes when a team becomes agile, common misconceptions to avoid, a practical way to get started, and which guide to read next based on what you are trying to learn.

What Is Agile?

Agile is an approach to product development and project management that emphasizes delivering value in small pieces, learning from feedback, and adapting as understanding improves.

Agile teams do not try to predict every detail up front. They make enough of a plan to begin, deliver a small piece of useful work, inspect the result, and then decide what to do next.

Agile teams still plan. They treat plans as something to update as they learn, rather than as contracts that must be defended long after reality has changed.

Agile is especially useful when the work is complex, the right answer is uncertain, or feedback from users and stakeholders will change what should be built.

Agile vs. Waterfall

Waterfall and other phased approaches organize work into sequential stages such as analysis, design, build, test, and release.

That can work when the problem is well understood, change is unlikely, and the cost of feedback arriving late is low. But many product-development efforts are not like that. Requirements change. Users react differently than expected. Technical risks appear. Stakeholders learn what they really need only after seeing something working.

Agile shortens the feedback loop. Instead of waiting until the end to learn whether the product is right, agile teams deliver smaller increments and use what they learn to adjust. The goal is to make planning more useful by updating plans as the team learns, especially when early plans were created with limited information.

A useful way to think about the difference is this: Waterfall works best when the path is predictable. Agile helps when learning during the work is essential. Learn more about Agile vs. Waterfall.

Defined vs. Empirical Work

Another way to understand the difference is to ask whether the work is defined or empirical.

In a defined process, the steps can be written down in advance and repeated with the same result. That works well for predictable, repeatable work.

Product development is usually different. No one can write down every step for building the right product, hand those steps to ten teams, and expect the same result from each. Teams need to inspect what is happening, adapt based on what they learn, and make their work transparent enough that good decisions can be made.

That is why agile approaches use short feedback cycles. They are built for work where learning during the work is essential.

Agile Is Iterative and Incremental

Agile teams work both iteratively and incrementally. Iterative means improving something through repeated feedback. A team builds something, inspects it, learns from it, and improves it.

Incremental means building the product in small pieces. Each piece adds to what came before.

A comedian developing a new act does both. The comedian tries a joke, improves the wording, adjusts the timing, and learns what gets a laugh. That is iteration. As more jokes work, the comedian adds them to the act until five minutes becomes ten minutes, then thirty, then a full show. That is incremental development.

Product development works the same way. Agile teams improve what they have already built while also adding small pieces of new value. Iterating without adding anything new can stall progress. Adding more and more without improving what is already there can produce a weak product.

Good agile teams do both. Learn more about iterative and incremental development.

When Agile Helps

Agile is most useful when a team needs to learn its way toward the right solution. That often happens when:

The product is new or complex
Customers or users are likely to change their minds after seeing early versions
Stakeholders disagree about what matters most
The technology includes uncertainty or risk
The team needs faster feedback than a long project plan can provide
The organization wants to reduce the cost of discovering mistakes late

Agile may be less important when the work is routine, the solution is already known, and little meaningful feedback is needed along the way.

Before deciding whether to use agile, ask whether shorter feedback cycles, cross-functional teamwork, and regular adaptation would help the team deliver a better result. Learn more about when to use agile.

Agile vs Scrum

Agile is a broad category. Scrum is one way to work within that category. Think of walking into an appliance store because you need a new refrigerator. Once you get to the refrigerator section, you still have choices: Samsung, Whirlpool, GE, Bosch, and others. They are all refrigerators, but they are different brands of refrigerator.

Agile works the same way. Scrum is one “brand” of agile. Kanban, Extreme Programming, DSDM, Feature-Driven Development, SAFe, Large-Scale Scrum, Crystal, and others are also ways teams may work in an agile manner.

So if someone says a team is agile, you know the broad category of how they work. If they say the team uses Scrum, you know more. Scrum gives teams a specific structure: accountabilities, events, artifacts, and short cycles called Sprints.

Scrum should help a team become more agile. When Scrum becomes only a set of meetings and rules, the team may be using Scrum mechanically without getting much agility from it. Learn more about Agile vs Scrum and The Scrum Framework.

Common Agile Approaches

There are many ways to work in an agile way. The most useful approach depends on the team, product, organization, and type of work.

This section focuses on common agile approaches. Practices such as user stories, story splitting, estimating, and planning are covered later in the learning path.

Scrum

Scrum is a lightweight framework for complex work. Scrum teams work in short cycles called sprints, create a usable increment of product, and use feedback to decide what to do next.

Scrum defines three accountabilities: Product Owner, Scrum Master, and Developers. It also includes recurring events such as Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. Learn more about The Scrum Framework.

Kanban

Kanban focuses on visualizing work, limiting work in progress, and improving flow. Kanban can be useful when work arrives continuously, priorities shift frequently, or a team wants to improve how work moves through its system without adopting all of Scrum. Learn more about Sometimes Kanban Is Better Than Scrum.

Extreme Programming

Extreme Programming, often called XP, emphasizes technical practices that help teams create high-quality software. These can include practices such as test-driven development, pair programming, continuous integration, and simple design.

A team does not need to use XP as a full methodology to benefit from some XP practices. Many Scrum teams, for example, use XP engineering practices to improve quality and sustainability.

What Changes When a Team Becomes Agile?

Moving to agile usually requires more than changing meeting names or putting work on a board.

A team usually needs to change how it thinks about planning, teamwork, feedback, and ownership.

Work Gets Smaller

Agile teams try to split work into smaller pieces so they can finish, inspect, and adapt sooner. Large batches hide risk. Smaller increments make learning possible.

Feedback Comes Earlier

Agile teams seek feedback throughout the work, not only at the end. That feedback may come from customers, users, stakeholders, product owners, testers, or the product itself.

Teams Become More Cross-Functional

Agile works best when a team has the skills needed to turn an idea into usable product progress.

Agile teams are also more self-managing than traditional project teams. They are given a goal and expected to decide together how best to achieve it.

Team members still bring different specialties. The difference is that the team collaborates across those specialties, makes many day-to-day decisions itself, and reduces handoffs that slow learning.

Plans Become Easier to Change

Agile teams still plan, but they expect plans to change as they learn. A good agile plan helps the team make the next good decision while acknowledging that the team will learn more as the work continues.

Progress Is Measured by Useful Work

Agile teams care less about whether people are busy and more about whether the team is creating useful product progress. Completed documents, designs, tasks, or meetings matter only if they help the team deliver something valuable.

Common Misconceptions About Agile

Agile is often misunderstood because people see the visible practices before they understand the purpose behind them.

Agile Means No Planning

Agile teams plan frequently. They update plans as they learn instead of treating early plans as fixed. For more detail, see Agile Planning and Forecasting.

Agile Removes the Need for Leadership

Agile changes leadership work; it does not remove leadership. Leaders still clarify goals, remove obstacles, and protect teams from false certainty. For more detail, see Agile Leadership.

Agile Means Changing Anything at Any Time

Agile welcomes change because change often reflects learning. Teams still need focus and thoughtful tradeoff decisions. For more detail, see Agile Planning and Forecasting and Sprint Planning.

Scrum Is the Only Agile Approach

Scrum is the most widely recognized agile framework, but it is not the only agile approach. For more detail, see Agile vs. Scrum and Scrum.

Agile Is Only for Software

Agile ideas can help complex product development and knowledge work whenever feedback, adaptation, and collaboration matter. For more detail, see When to Use Agile.

Agile Automatically Fixes Problems

Agile often exposes weak strategy, leadership, teamwork, or customer understanding. It makes problems visible; people still have to solve them. For more detail, see Agile Misconceptions and Leading Agile Initiatives.

How to Get Started with Agile

Start before you know every agile term. The best way to develop the ability to work differently is to start working differently in a small, thoughtful way.

A practical starting path is to choose one team or product area where shorter feedback cycles would help. Give the team a clear goal, make sure it has the skills needed to deliver useful work, and agree on how the team will plan, coordinate, review progress, and improve. Then start with a small amount of work, finish it completely, get feedback, and improve the team's practices one step at a time.

Training can help, especially when a team needs shared language and a common understanding of Scrum, user stories, estimating, planning, and teamwork. Coaching can also help when the organization's habits make agile difficult to sustain.

Use training to support practice. Agile is learned by doing.

Before You Choose an Agile Starting Point

Use these questions to decide where your next learning or improvement step should be.

Is the team new to agile concepts, or does it mainly need to learn Scrum?
Is the work complex enough that shorter feedback cycles would help?
Does the team have the skills needed to deliver small increments of useful work?
Are stakeholders prepared to give feedback before everything is finished?
Is the team struggling more with backlog clarity, planning, teamwork, or leadership support?
Are leaders willing to change the system around the team, not just ask the team to change its meetings?

This is not a test to pass. Use it to choose the most useful next conversation, guide, course, or workshop.

FAQ

What is the difference between agile and Scrum?

Agile is the broader approach. Scrum is one framework for applying agile ideas.

Agile emphasizes feedback, collaboration, adaptability, and delivering value. Scrum gives teams a structure for doing that through sprints, roles, events, and artifacts.

Should we use Scrum or Kanban?

It depends on the kind of work and the problems you are trying to solve.

Scrum is often helpful when a team benefits from short planning cycles, a sprint goal, and regular product and process feedback. Kanban can be helpful when work arrives continuously or when improving flow is the main concern.

Many teams combine ideas from both.

Is agile better than waterfall?

Not always.

Agile helps when learning and feedback are important. Waterfall or phased approaches can be reasonable when the work is predictable and change is unlikely.

Waterfall creates problems when teams use a predictive approach for work that requires learning.

Do agile teams still have requirements?

Yes.

Agile teams still need to understand what to build and why. They just avoid trying to specify every detail too early. Many agile teams use product backlogs and user stories to keep requirements lightweight, conversational, and adaptable.

Do agile teams still estimate?

Yes.

Many agile teams estimate so they can make better decisions about scope, priorities, tradeoffs, and timing. The aim is better planning under uncertainty, not perfect prediction.

Does agile require certification?

No. An organization does not become agile because people earn certificates. Teams become more agile by changing how they collaborate, deliver, learn, and improve.