Explore  

What is agile methodology? (16 examples with pros and cons)

Last updated: February 2025

Agile methodology is a flexible approach to product and project management that focuses on adaptability and collaboration. Agile work is done in small, iterative cycles, which allows teams to respond quickly to change. Agile methodology prioritizes continuous feedback, teamwork, and improvement — so teams can build products that customers love.

Agile is more than a buzzword — it is a mindset that has transformed how folks build and deliver products. Agile methodologies and frameworks provide the structure and guidance that product teams need to deliver value fast.

But when people talk about being (or "going") agile, what do they really mean? Which agile methodology is best? Do all of the formal agile approaches adhere to the Manifesto for Agile Software Development, colloquially known as the Agile Manifesto? Can you call yourself agile without following a specific agile framework?

Merriam-Webster defines agile as "marked by ready ability to move with quick easy grace." Any product team would be happy to be described that way! And if we think about being agile as "quick easy grace," then we can more easily loosen the restrictions and process pedantry that you have likely heard about from agile purists. So to answer our last three questions above? It depends, not really, and sure.

With that in mind, every team must forge a unique path based on its market, how its organization operates, and what its customers need — regardless of the specific methodology, framework, or workflow it follows.

We cover quite a bit in the sections below. Even so, we only scratch the surface of one of the more hotly debated topics in product development. If you take away anything from this guide, we hope it is this: Agile is for rapid value delivery. Feel free to jump ahead as needed — with quick easy grace:

What is the history of agile?

An Aha! whiteboard showcasing the history of agile

Agile methodologies have evolved from kanban in the 1940s to the Agile Manifesto in 2001 to today's modern scaling frameworks, such as the Scaled Agile Framework® (SAFe®) and Large-Scale Scrum (LeSS). The timeline above was created on the Aha! timeline diagram template.

Early roots of agile: Kanban, IID, and beyond

Agile is older than you might think. Kanban was conceived in the 1940s. Iterative and Incremental Development (IID) dates back as early as the 1950s, with evidence of use by teams at NASA and IBM. Other adaptive methods, such as Evolutionary Delivery (EVO) and Rapid Application Development (RAD), were in use through the 1970s.

However, it was not until the late 1990s that agile gained widespread traction. So what pushed what we now know as agile to the forefront? Two forcing factors: backlash against bureaucracy and colossal business change.

The rise of waterfall and the push for change

Good project management of software procurements is impossible without some form of explicit (validated) and governing requirements.

Winston Royce

(Royce is widely credited as the first person to formally describe the waterfall method through his works in the 1970s.)

IID, EVO, RAD, and other adaptive methods were seen as fringe and not taken seriously by established companies for decades. Instead, most organizations continued to rely on the single-pass software development lifecycle known as waterfall.

Waterfall defines requirements upfront and delivers projects in sequential phases. It can be effective for projects with a fixed scope, but vulnerable to failure if requirements change during development. And as anyone who works in technology knows, it is nearly impossible to anticipate all requirements at the outset.

The rigidity of single-pass software development created breakpoints between management and engineering teams.

Do you remember the beleaguered engineer from the comic strip Dilbert? First published in 1989, the comic's satirical plot points encapsulate many frustrations shared by developers who felt stifled by office politics and top-down micromanagement. The main complaint was that busywork and process were prioritized over productivity.

Around that same time, new technologies that enabled faster product development emerged. Widespread access to the internet disrupted entire markets. As new software-based products and services gained traction, customer expectations began to change.

Customers wanted products to be continuously improved with new functionality. And they wanted to be involved in suggesting what that new functionality should be and shaping its development. Accelerating time to market became a business priority as companies struggled to survive in highly competitive marketplaces.

From 'light' methods to the Agile Manifesto

With all of this percolating, a group of 17 software practitioners gathered in Utah in 2001. That meeting is the one that is most widely reported in historical accounts of the agile movement.

But the group had actually met a year earlier in Oregon to discuss what they called "light" or "lightweight" development methodologies. No one was particularly comfortable with the potentially negative implications of "light," so they agreed on the word "agile" when they gathered the following year to formalize what became the Agile Manifesto.

I don't mind the methodology being called light in weight, but I'm not sure I want to be referred to as a lightweight attending a lightweight methodologists meeting.

Alistair Cockburn

Co-author of the Agile Manifesto

It is worth noting that many of the original authors of the Agile Manifesto had already developed their own methodologies (such as Extreme Programming (XP), Crystal, and scrum) by the time the group gathered in 2001. These methods, coupled with other novel approaches to programming drawn from the past, were an ideal foundation for developer communities ready to adopt a new mode of working.

The values and principles of the Agile Manifesto

The authors of the Agile Manifesto defined four core values and 12 principles. Those values and principles are meant to guide how agile software development teams should approach their work. And together, the 16 tenets serve as the foundation for many of the agile methods teams use today — with special attention paid to flexible planning, efficient communication, very short feedback loops, and adaptive cycles.

The key components of the Agile Manifesto are reproduced below.

A graphic showing the values of agile: Customer collaboration, working software, individuals and interactions, and responding to change
The Agile Manifesto

“We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

  1. Individuals and interactions over processes and tools

  2. Working software over comprehensive documentation

  3. Customer collaboration over contract negotiation

  4. Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

We follow these principles:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

  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. The most efficient and effective method of conveying information to and within the development team is face-to-face conversation.

  7. Working software is the primary measure of progress.

  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

  9. Continuous attention to technical excellence and good design enhances agility.

  10. Simplicity — 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.”

Scaling agile in the modern era

The agile movement has continued to evolve since the Agile Manifesto was published. As agile principles spread beyond individual teams, organizations sought ways to scale these practices across larger and more complex environments.

This led to the development of modern scaling frameworks such as SAFe, LeSS, and Scrum@Scale. These frameworks are meant to help enterprises manage agility across multiple teams, ensuring that the values of flexibility, collaboration, and rapid iteration are maintained on a larger scale.

Today, agile is not limited to software development — it has become a guiding philosophy for industries as diverse as marketing, finance, and healthcare.

Top

Why do companies adopt agile?

A company typically adopts agile because they are experiencing an enterprise transformation. As part of that transformation, the organization has likely identified moving from a legacy workflow methodology (whether it is homegrown or a traditional approach like waterfall) to a more modern way of working as necessary for improved innovation and faster delivery.

Put simply: Keep up or get left behind.

These types of transformations represent a major investment from the organization — both in terms of the resources allocated and the time associated. The larger the company and the more products in its portfolio, the larger the investment.

Agile vs. waterfall

Few product development teams today would say that they practice waterfall. But the reality is that many of the homegrown approaches that organizations follow more closely align with waterfall than with any agile methodology.

And waterfall is not without its benefits for:

  • Hardware products: A waterfall approach can be effective for physical or hardware products where requirements are fixed and change is difficult to accommodate once a project begins.

  • Regulatory compliance: Industries with tight regulations or required stage gates might find that waterfall's sequential nature ensures compliance.

  • Complex product portfolios: Multinational corporations with highly complex product portfolios also find some benefits in waterfall — although SAFe is fast filling that niche for many enterprises looking to go agile, all while retaining close oversight and coordination across the portfolio.

We do have a dedicated guide that compares agile to waterfall. But below is a condensed comparison between agile and waterfall, focusing on the ways the two approaches affect how product teams carry out core responsibilities:

Agile

Waterfall

Define goals

Focus customer-centric goals on areas like user growth and customer delight

Measure business-centric goals using key performance indicators (KPIs) like scope, schedule, and budget

Set strategic themes

Product-level themes guide the high-level efforts needed to accomplish goals

Business-level initiatives tie to specific projects

Build the product roadmap

Plan in quarterly, monthly, or biweekly cycles with flexibility to adjust the roadmap as new information emerges

Plan quarterly or annually with a long-term roadmap commitment to build specific features within a set timeline

Understand customer needs

Continually explore to understand customer needs and validate solutions throughout development

Capture customer needs upfront before development begins during a requirements-gathering phase

Prioritize features

Regularly reprioritize to respond to changing customer, market, and business needs

Establish one-time prioritization in a product requirements document

Define requirements

Refine requirements in real time as new information is discovered

Handoff fully defined in a product requirements document

Develop new functionality

New functionality developed iteratively (and often continuously), with early customer feedback incorporated into the next iteration

New functionality developed according to the PRD, tested before release, and shipped in its totality without customer input

Release customer experiences

Deliver frequently whenever there is tangible customer value to be shipped

Deliver infrequently with a fixed schedule where customer value is delivered at the end of the project

Measure results

Measure success by progress toward strategic goals, product performance metrics, and customer sentiment

Measure success based on the initial scope being delivered on time and within budget

Evaluate the process

Hold formal or informal retrospectives after each iteration to identify areas of improvement, which are immediately implemented

Review where the project overshot or undershot initial scope to improve estimates for the next project

Hybrid vs. custom agile frameworks

Some organizations choose to slowly wade into the agile world by choosing a hybrid approach. This refers to an agile software development framework combined with a traditional waterfall (so-called "wagile") or project-based development structure. Hybrid frameworks can be a helpful transitional path, and some companies might find that they are a lasting solution for their teams.

You might find that your team does better with a blended agile approach. Blended agile refers to two or more established agile frameworks used together — such as "scrumban," which blends the structure of scrum with the flexibility and visualization of kanban.

Some create their own agile frameworks. UnitedHealth Group established the Optum Scalable Agile Method (OSAM), which is a modified application of SAFe. According to a slide presentation that shares some of its challenges with implementing agile at scale, one of Optum's largest agile portfolios has more than six release trains, 35 scrum teams, and hundreds of teammates. OSAM offered the flexibility needed to evolve a massive organization over time.

Another example of an organization creating its own product development framework is our own company. We developed and have used The Aha! Framework for product development for more than a decade — it continues to power our product success today. We formally introduced the framework in 2024, publishing a series of guides about the framework and its activities, guidance on adoption, and comparisons to other methodologies. If you use Aha! Roadmaps, you can view the entire framework with our Frameworks functionality.

Explore The Aha! Framework on a whiteboard. Get the template.

The Aha! Framework large


Top

Benefits of adopting an agile approach

The promise of agile is that your team will be able to save valuable time and resources while creating products that customers love and be happy doing it. That is the dream, right?

But there is Agile and then there is agile — with a little "a." Some argue that if you do not follow a specific framework or set of rules, you are not truly agile. But rigidly adhering to rules can limit creativity and productivity.

Method tailoring, process pragmatism, and comfort with the messy reality of how people plan and deliver should all be welcomed by agile thinkers. What matters more than any one methodology or framework is embracing an agile philosophy. This includes a flexible mindset and continuously seeking ways to improve how work is done so you can maximize the value you deliver to customers.

The benefits of adopting an agile philosophy are quicker release cycles and higher-quality code, which leads to increased customer satisfaction and happier teams.