Agile methodology: values, principles & frameworks guide

Agile methodology is a way of managing projects in short, repeating cycles: you build a small piece of the work, get feedback, adjust, and go again, instead of committing to one fixed plan up front.

It exists to solve a problem every project team eventually hits which is requirements change faster than a rigid plan can absorb.

This guide covers what agile methodology is, the four values and twelve principles behind it, the main frameworks (Scrum, Kanban, and a few others), and how to run your first iteration.

We run our own distributed team on these practices at Slite, so the examples here come from using agile day to day rather than from the manifesto alone.

Key takeaways

• Agile methodology delivers work in short, iterative cycles with continuous feedback, rather than one long, fixed plan.
• It rests on the Agile Manifesto: 4 core values and 12 principles, first written for software in 2001 and now used across many industries.
• The best-known frameworks are Scrum and Kanban, with SAFe, Lean, and Extreme Programming (XP) covering larger or more specialized needs.
• Agile brings real benefits (adaptability, customer feedback, team ownership) and real trade-offs (scope creep, planning, and documentation that drifts out of date).
• You can start with one team and one backlog as the last section walks through the first steps.

What is agile methodology?

Agile methodology is an approach to project management that breaks a project into small increments, delivers them in short, repeating cycles, and uses feedback from each cycle to guide the next by prioritizing working results and responsiveness to change over a single fixed plan set at the start.

Teams organize the work into short iterations called sprints, review what they built at the end of each one, and adjust the plan before starting the next.

Agile began in software development in 2001 and has since spread to marketing, operations, and product teams of every size. It sits within the broader discipline of project management, but replaces fixed, sequential planning with continuous iteration.

The Agile Manifesto gives the approach its foundation: four core values and twelve principles, which we cover next.

The Agile Manifesto

The Agile Manifesto was written in 2001 by a group of seventeen software developers in Utah. They wanted to replace the heavyweight, documentation-first project management of the time with something faster and more collaborative.

Although it was written for software, teams now apply it to project management more broadly.

The 4 core values of agile sit at the heart of the manifesto.

The 4 core values of agile

Each value names a trade-off: it favors the first item without discarding the second.

1. Individuals and interactions over processes and tools

Traditional project management leans on formal processes and tooling. Agile shifts the focus to people and communication, because the team and not the process is what responds to change and meets a customer's needs.

2. Working software over comprehensive documentation

This value is often misread as a licence to skip documentation. It does not say that. It says a working product is the real measure of progress, so documentation should be right-sized to support the work rather than exhaustive for its own sake.

Teams still need documentation but they just keep it lean and current, a tension we return to below in the documentation trap.

3. Customer collaboration over contract negotiation

In traditional project management, requirements are fixed at the start and rarely revisited. Agile treats the customer as an ongoing collaborator, folding their feedback in at every stage so the finished product actually matches what they need.

4. Responding to change over following a plan

Traditional project management relies on a strict project plan: plan, execute, deliver. Real projects rarely run that cleanly — priorities shift, blockers appear, and new information lands mid-flight. Agile is built to absorb that change instead of resisting it.

The 12 principles of agile

The four values are expanded by the manifesto's 12 principles.

In brief, they are:

1. Satisfy the customer through early and continuous delivery of valuable software (or whatever product or service you are working on).
2. Welcome changing requirements, even late in development; agile processes harness change for the customer's advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for shorter timescales.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals; give them the environment and support they need, and trust them to get the job done.
6. Face-to-face conversation is the most efficient and effective way to convey information within a team.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development; everyone should be able to keep a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity as the art of maximizing the amount of work not done is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Who uses agile methodology?

Agile methodology is used well beyond software. Product, engineering, marketing, operations, and design teams all run on it, in startups and large enterprises alike.

It fits any project where requirements evolve, feedback matters, and the team needs to change direction without restarting from scratch which describes most modern work.

Agile tends to pay off most when your projects have traits like these:

• Requirements and priorities that change over time
• Work that evolves across its lifecycle rather than staying fixed
• A strong dependence on customer relationships and feedback
• Room for continuous improvement and optimization
• Regular internal and external feedback loops
• Many tasks that run in parallel

The agile project lifecycle: phases and steps

The agile project lifecycle is an iterative, repeating cycle rather than a single start-to-finish plan: the team defines and prioritizes the work, delivers a slice of it in a short iteration, reviews the result, and carries what it learns into the next round.

1. Vision and product backlog — set the goal and build a prioritized backlog of the work that needs doing.
2. Sprint (or release) planning — pull the top backlog items into the next short iteration and agree on the sprint goal.
3. Sprint execution — the team builds the increment over a one-to-four-week iteration, staying aligned with short daily check-ins.
4. Sprint review — demo the working output to stakeholders and gather their feedback.
5. Retrospective — the team inspects how the sprint went and adapts its approach for the next one.
6. Repeat — re-prioritize the backlog and start the next cycle, continuing until the product is done.

Inside a single sprint, the work itself still moves through the familiar development steps (requirements, design, build, test, deploy, and review) before the increment is demoed at the sprint review.

The loop is the point: because the team re-plans at the end of every iteration, an agile project can absorb new information and change direction without starting over. That repeating cycle is what makes agile adaptive.

What are the benefits of agile?

Agile's main payoffs are faster feedback, lower risk, and more engaged teams.

Here are the three we see most, from us — a distributed team that runs on our own self-maintaining knowledge base at Slite.

1. Improved customer experience and satisfaction

Customer satisfaction drives almost every other project outcome: repeat sales, word of mouth, and loyalty. Because agile makes customer collaboration one of its four values, feedback is built into the work rather than collected once at the end. Teams test and review inside each sprint, so they can fold new findings into the next version quickly.

2. Fewer risks, greater adaptability

Rigid, linear project management fails when events do not unfold as planned — and on complex projects, they rarely do. Agile lowers that risk by letting teams adjust mid-project, accounting for new conditions and re-prioritizing as they learn instead of only before work starts or after it ends.

Shorter cycles and more frequent reporting also make progress easier to see. Most agile teams capture that rhythm in a short project report at the end of each cycle.

3. Happier, more autonomous teams

Agile gives team members real ownership: they solve problems, propose ideas, and take responsibility for outcomes rather than waiting for instructions. That autonomy, plus the constant communication agile encourages, tends to build morale and trust across a team. People who are trusted to do the work usually do it better.

Common challenges of agile methodology

Agile is not a free win. The same flexibility that makes it powerful introduces trade-offs worth planning for.

• Scope creep. Welcoming change is a value, but without a disciplined backlog, "just one more thing" can stretch a project indefinitely.
• Long-range planning is harder. Iterative delivery makes fixed budgets, deadlines, and roadmaps tougher to commit to, which can frustrate stakeholders who need firm dates.
• It demands team maturity. Self-organizing teams need experience and trust to work well; agile struggles when a team is new or under-supported.
• Scaling is non-trivial. Coordinating many agile teams on one product is a discipline of its own — the reason frameworks like SAFe exist.
• Documentation drifts out of date. Favoring working software over comprehensive documentation is healthy, but pushed too far it leaves teams with knowledge that no longer matches reality. That drift is common enough to deserve its own section below.

Agile vs waterfall: how they differ

Agile is often defined against waterfall, the traditional sequential model where each phase finishes before the next begins. The difference comes down to when you plan, how you handle change, and how often you deliver.

Neither model is universally better. Waterfall suits projects with stable requirements and strict compliance needs; agile suits work where the requirements will change as you learn.

Agile team roles and responsibilities

Agile teams are small, cross-functional, and self-organizing, so roles are defined by ownership rather than by hierarchy. A few show up on almost every agile team, whatever the framework:

• Product owner — owns the backlog and its priorities, represents the customer, and decides what gets built next.
• Team facilitator (scrum master or agile coach) — protects the process, clears blockers, and keeps the team focused; the title changes from one framework to the next.
• The delivery team — self-organizing and cross-functional, it owns how the work gets done and estimates its own capacity.
• Stakeholders and customers — give feedback every cycle rather than only at the start and the end.

The traditional project manager role changes the most under agile. Instead of command-and-control planning, it shifts toward facilitation and servant-leadership, and its old responsibilities are usually split between the product owner and the team facilitator.

Types of agile methodologies

There is no single way to do agile. Some frameworks came from software, others from manufacturing, and each shapes the same values into a different working rhythm. Before the frameworks, it helps to know a few practices they share.

User stories

In agile, work requests are often written as user stories, because the method centers the customer's perspective. A user story describes what someone wants done and why. It stays short — just enough for the team to estimate the work involved.

Sprints

A sprint is simply a fixed period of work. Agile teams work in iterations of one to four weeks, each built around a specific goal. You keep running sprints until the project is finished, then start the cycle again.

Daily standups

Frequent communication holds agile together. A short standup happens every day so the team stays in sync. It does not need to run long — it just covers what each person is working on and surfaces anything blocking them.

Scrum

Scrum is the best-known agile framework — so well-known that people often use "scrum" and "agile" interchangeably. They are not the same: scrum is one way to practise agile, with a specific set of roles and ceremonies. It gives teams a structure for planning and running work without dictating exactly how to do it.

Scrum defines three accountabilities within one Scrum Team: the Scrum Master, the Product Owner, and the Developers (the people doing the work).

A typical scrum cycle runs like this:

1. Start with a clear vision and a prioritized list of features called the product backlog. The Product Owner is responsible for the product backlog.
2. Kick off with a sprint planning meeting — the session where the team decides what to build next. Sprint planning usually covers:
   • Reviewing the product backlog
   • Setting the sprint goal
   • Estimating the sprint backlog
   • Committing to the sprint
3. The sprint backlog is the set of tasks the team commits to for that sprint. Work begins once planning is done.
4. Meet for about 15 minutes each day in the daily scrum. Keep it short. Each person names what they finished, what they will do next, and any blockers.
5. When the sprint ends, hold a sprint review to demo what was built and discuss what still needs work.
6. Hold a sprint retrospective as well, focused on what to improve next time. Note: you can grab our free sprint-retrospective template at Slite.

Together these ceremonies reinforce scrum's three pillars: transparency, inspection, and adaptation.

Kanban

Kanban is another popular agile framework. Instead of time-boxed iterations, it focuses on visualizing work and managing flow across a project's life.

Kanban is a Japanese word for "visual board" or "sign board." Although the term "kanban method" was popularized for knowledge work around 2007, the system itself was developed by Toyota's Taiichi Ohno in the late 1940s and 1950s to limit work in progress; it had spread across Toyota's operations by the 1960s.

A kanban board can be arranged many ways, but the simplest uses three columns:

• To do
• Doing
• Done

You visualize the work by moving tasks across the columns, which makes bottlenecks and progress obvious at a glance. Pair the board with a weekly progress report so stakeholders see the same picture without extra meetings.

Scaling and other frameworks

Scrum and Kanban cover most teams, but a few other frameworks are worth knowing:

• SAFe (Scaled Agile Framework). Coordinates many agile teams working on one large product — the go-to when a single backlog and one scrum team are not enough.
• Lean. Comes from manufacturing and focuses on maximizing value while cutting waste out of the process.
• Extreme Programming (XP). An engineering-heavy framework built around practices like pair programming, test-driven development, and continuous integration.

You will also see Crystal and Feature-Driven Development (FDD) in larger organizations, though they are less common than the frameworks above.

Agile and the documentation trap

Agile's second value (working software over comprehensive documentation) is one of its most useful ideas and one of its most misused.

Read carefully, it argues for right-sized documentation.
Read lazily, it becomes an excuse to write almost none.

Fast-shipping teams tend to drift toward the second reading, and that is where the trouble starts.

The mechanism is simple. Every sprint ships changes, but the docs describing how things work rarely get updated at the same pace.

Over a few months, enough of the knowledge base falls out of date that people stop trusting it. Once they stop trusting it, they stop updating it, too. Why maintain something no one reads? And the documentation decays faster.

This is not a rare edge case. Ask almost any engineering or operations lead how much of their team's documentation they would trust without double-checking, and the honest answer is usually: not much.

The cost is real but hidden as time lost re-deriving things that were written down once and never kept current, and decisions made against stale information.

This is the problem we built Slite to solve. Slite is a self-maintaining knowledge base: instead of relying on people to catch and fix every stale page, Slite Agent flags documentation that looks out of date and proposes updates for a human to approve.

It works like an async triage queue with small, reviewable suggestions that arrive as reality drifts, so cleanup happens continuously instead of piling up into one big quarterly effort.

A few honest caveats. This makes documentation lighter and easier to keep current; it does not mean zero documentation or zero effort, and you still decide what is worth writing down.

Every change the Agent proposes is reviewed by a person before it lands, so nothing rewrites your knowledge base on its own.

If keeping documentation in sync with a fast-moving agile team sounds familiar, that is the gap Slite is built to close.

How to get started with agile

Agile rewards starting small and iterating, so treat your first cycle as a practice run. Here is a sequence that works:

1. Define the vision and backlog. Agree on what you are trying to achieve, then list the work as prioritized items.
2. Plan the first iteration. Pull the top items into a short sprint and set a clear goal for it.
3. Run the sprint. Do the work in a fixed one-to-four-week window, with a short daily check-in to stay aligned.
4. Review and retro. Demo what you built, gather feedback, and agree on one or two improvements.
5. Repeat. Carry the lessons into the next sprint and keep going.

Agile stopped being a 2001 experiment a long time ago; it is now how a large share of software, product, and operations teams work. The harder part is keeping the rest of your system — especially your documentation — current as you move that fast.

If you want your knowledge base to keep up with an agile cadence rather than fall behind it, see how Slite works or book a demo.

FAQ

Is agile a methodology or a framework?

Strictly, agile is a mindset defined by the Agile Manifesto's values and principles, not a single method. Frameworks like Scrum and Kanban are the concrete ways teams put that mindset into practice. In everyday use, "agile methodology" is the common shorthand for the whole approach.

Is Scrum the same as agile?

No. Agile is the broader set of values; Scrum is one popular framework for working in an agile way. Every scrum team is agile, but plenty of agile teams use Kanban or another framework instead.

How long is an agile sprint?

Most sprints run one to four weeks, with two weeks being the most common choice. The length usually stays fixed once a team settles on it, so the cadence stays predictable.

Why use agile methodology?

Teams adopt agile to handle changing requirements, deliver value sooner, and get feedback early enough to act on it. It also tends to improve team ownership and morale. The trade-off is that it demands discipline around scope, planning, and keeping documentation current.