Teams building software with shaky requirements tend to land on agile development sooner or later. It releases working software in short, time-boxed cycles, and the plan gets revised from user feedback after each one. Waterfall and other plan-driven methods are what it usually gets measured against.
The name came after the methods. Scrum and Extreme Programming were already around when 17 practitioners met at Snowbird, Utah, in February 2001. They picked the word agile to replace the label lightweight methods, according to Martin Fowler’s account of the meeting.
What is agile development?
The IEEE Technology Navigator puts a typical cycle at one to four weeks. Each one ends with software a user can run, and the feedback on it decides what gets built next. Requirements change as that feedback comes in, which is most of the point.
Underneath sits an iterative way of building software, so planning, coding, testing and review repeat in every cycle. Quality assurance runs inside those cycles rather than waiting for a test phase after coding stops.
Delivery is incremental too. Each cycle adds a usable piece to the product through incremental delivery of software, so there is no single big release at the end of the project.
Agile is a set of values first and a method second, which is why teams can run it with different frameworks.
People get a few things wrong about it. It isn’t one framework (Scrum, Kanban and Extreme Programming all sit under it), and it isn’t a ban on planning, since teams plan every cycle in small pieces. Documents stay as well. Working software just ranks above them.
In Digital.ai’s 17th State of Agile report (2024), 71% of the 788 respondents said they use agile in their software development lifecycle.
Where does agile development come from, and what does the Agile Manifesto say?
The Manifesto for Agile Software Development was written at a Utah ski resort, the Lodge at Snowbird, on February 11-13, 2001 (agilemanifesto.org). Seventeen people took part (agilemanifesto.org). It sets out 4 values and 12 principles for building software.
The values statement itself is short, 68 words covering all 4 values (PMI Disciplined Agile). Principle 3 gives the delivery range as a couple of weeks to a couple of months, with the shorter timescale preferred (agilemanifesto.org).
How the Manifesto was written
The Snowbird meeting grew out of an earlier gathering of Extreme Programming supporters that Kent Beck organized at the Rogue River Lodge in Oregon in spring 2000, according to the history page on agilemanifesto.org.
Scrum and Extreme Programming both predate the Manifesto. The attendees were writing down what their separate methods shared, which is why the document names no framework.
As O’Reilly’s The Art of Agile Development describes it, the meeting gave the industry the term “agile” and the Manifesto itself. It also produced the Agile Alliance, a nonprofit that spreads agile practice.
The Manifesto values
Each value ranks one thing above another, and the Manifesto says the lower item still has value. Individuals and interactions come before processes and tools. Working software comes before comprehensive documentation, customer collaboration before contract negotiation, and responding to change before following a plan.
Agile development does not drop contracts, plans, processes or documentation. It ranks them second.
The principles behind the Manifesto
The 12 principles turn the values into working rules, and they cluster by theme.
The first three cover delivery. Satisfy the customer through early and continuous delivery, accept changed requirements even late in the project, and release working software every couple of weeks to couple of months, with a preference for the shorter timescale.
Principles 4, 5, 6 and 11 deal with people. Business people and developers work together daily. Motivated people get support and trust, face-to-face conversation is the preferred channel, and the best designs come from self-organizing teams.
Principles 7 and 8 cover progress and pace. Working software is the main measure of progress, and teams keep a constant pace they can sustain indefinitely.
The remaining group, 9, 10 and 12, is about quality and adjustment. Technical excellence and good design keep a team agile, simplicity means maximizing the work not done, and the team reviews its own habits at regular intervals.
Four of the 12 principles concern how people work together, and none of them names a tool.
How does an agile development cycle work?
Every agile framework repeats the same loop. Plan a little, build and test it, show it, adjust, all inside a fixed time box, and end with a working increment.
Here is how one sprint runs, step by step.
- Refine the product backlog. The product owner orders items by value, and the team clarifies the top ones until each is small enough to finish in one cycle.
- Plan the sprint. The team picks items from the backlog, sets a sprint goal and breaks the work into tasks.
- Build and test together. Developers code, test and fix inside the same cycle, and meet briefly each day to adjust the plan.
- Integrate continuously. Every change merges into the shared codebase and passes automated tests, so the product stays releasable.
- Review the increment. The team shows working software to stakeholders and collects feedback.
- Hold a retrospective. The team inspects how it worked and picks improvements for the next cycle.
The length of a sprint stays fixed once the team picks it. If the work doesn’t fit, the team trims scope and keeps the date.
Teams keep each increment releasable through continuous integration, which merges every developer’s changes into a shared codebase frequently and runs automated tests on each merge.
Work enters the cycle as user stories, short descriptions of a need from the user’s point of view. Acceptance criteria say when a story counts as done, and story points estimate its size relative to other stories.
Sources don’t agree on cycle length, which matters when a team picks a cadence. The Agile Manifesto (2001) allows a couple of weeks to a couple of months, with the shorter timescale preferred. The Scrum Guide (2020) caps it at one month or less, fixed in length. The IEEE Technology Navigator says typically one to four weeks.
The one-to-four-week norm tracks Scrum’s one-month cap, not the Manifesto’s wider range.
Who does what on an agile team?
The 2020 Scrum Guide gives a Scrum Team one product owner and one scrum master, and everyone else on the team is a developer. Other agile frameworks name roles differently, so this section follows Scrum, which 63% of agile teams use (Digital.ai, 17th State of Agile, 2024).
Roles on the team
The product owner decides what gets built and in what order. That means managing the product backlog and ordering it by value. One person holds the role per team, so priorities have a single owner.
The scrum master looks after how well the team follows Scrum. In practice that means removing impediments and keeping events inside their time boxes.
Developers build, test and deliver the increment.
The cross-functional model also works above team level. In 2015 ING began reorganizing its group headquarters, 3,500 staff, into about 350 nine-person squads in 13 tribes, and a January 2017 McKinsey Quarterly interview reports better time to market and higher employee engagement.
Artifacts that track the work
The product backlog is the ordered list of everything the product still needs, and the product owner owns it. The sprint backlog holds the sprint goal, the items picked for this sprint and the plan to deliver them. That one belongs to the developers.
The third artifact, the increment, is the sum of usable work finished to the team’s definition of done. The definition of done is a shared checklist, such as code reviewed, tests passing and documentation updated. An item that misses it stays out of the increment.
Velocity and burndown charts track the pace of finished work. Velocity helps one team plan its next sprint, and it stops meaning anything once managers compare it across teams or set it as a target.
Events inside a sprint
Each event in a sprint has a maximum length, and the table below uses the figures for a one-month sprint.
| Event | Who attends | Time box (one-month sprint) |
|---|---|---|
| Sprint planning | Whole Scrum Team | 8 hours maximum |
| Daily scrum | Developers | 15 minutes, any sprint length |
| Sprint review | Scrum Team and stakeholders | 4 hours maximum |
| Sprint retrospective | Whole Scrum Team | 3 hours maximum |
Scrum Alliance’s 2020 Scrum Framework reference lists these limits, and shorter sprints get shorter events.
The daily scrum was once called the daily stand-up. Scrum.org notes the name changed because participants are not required to stand.
Which agile frameworks do teams use?
No framework is required. Scrum, Kanban, Extreme Programming, Lean software development and SAFe are the five that keep turning up in the sources.
| Framework | Core rule | Best fit | Weak spot |
|---|---|---|---|
| Scrum | Fixed-length sprints with a sprint goal | Feature work a team can plan | Constant interrupts break the sprint |
| Kanban | Visualize the workflow, limit work in progress | Support and maintenance queues | No built-in planning cadence |
| Extreme Programming | Pair programming, test-first coding | Small teams with shifting requirements | Pairing meets resistance |
| Lean software development | Eliminate waste in the value stream | Teams cutting handoffs and waiting | Principles only, no prescribed events |
| SAFe | One shared cadence for many teams | Large organizations with dependent teams | Heavy overhead for a single team |
They prescribe different things. Scrum gives you a cadence, Kanban a flow rule, Extreme Programming an engineering discipline. Lean offers a waste filter, and SAFe is a coordination layer for many teams at once.
Kanban and its Toyota origin
Toyota engineers Sugimori, Kusunoki, Cho and Uchikawa described Taiichi Ohno’s kanban system in the International Journal of Production Research in 1977, as part of the Toyota Production System. It was built to make only the necessary products, in the necessary quantity, at the necessary time.
Software teams carried that pull logic over to Kanban boards, where work items move across columns and each column holds a capped number of items.
Scrum.org’s Kanban Guide for Scrum Teams (January 2021) names 4 practices. Teams visualize the workflow and limit work in progress, then actively manage items in progress, and inspect and adapt the definition of workflow. The same guide says lowering work in progress is the first move when cycle times run too long.
Extreme Programming
Extreme Programming (XP) prescribes engineering practices, not meeting structure.
Kent Beck developed extreme programming as project leader on Chrysler’s C3 payroll project, then described it in Extreme Programming Explained (Addison-Wesley, 1999).
Its practices include pair programming, test-first coding, refactoring, small releases and a 40-hour week.
Beck advises no more than 12 developers working in pairs, according to Lee Copeland’s Computerworld overview. Pair programming draws most of the objections. Sun’s James Gosling said Sun used XP techniques such as unit testing but passed on pairing.
Lean software development
Mary and Tom Poppendieck adapted 7 lean principles from manufacturing in Lean Software Development: An Agile Toolkit (Addison-Wesley, 2003), plus 22 thinking tools.
The first principle, eliminate waste, covers extra features, task switching, waiting and defects. Lean sets no roles or events, so teams run it alongside Scrum or Kanban.
SAFe for many teams
SAFe suits organizations where many teams depend on each other. Dean Leffingwell created it in 2011, IBM notes, and Scaled Agile Inc. says it is practiced at over 20,000 enterprises.
It layers shared planning on top of team-level practice, such as program increment planning for each agile release train. A single team gets little from that extra layer.
How to choose between Scrum and Kanban
Scrum fits when work arrives as a backlog of features a team can plan, and when stakeholders want a regular review rhythm. Kanban is the better match when work arrives continuously, like support tickets or maintenance requests, or when priorities change daily and a fixed sprint would keep breaking.
The two also combine. Scrum.org’s Kanban Guide for Scrum Teams adds no events beyond those in the Scrum Guide.
How does agile development differ from waterfall?
Agile fixes the time box and lets scope flex. Waterfall goes the other way, fixing scope up front and letting the schedule move when something has to give.
| Dimension | Agile development | Waterfall |
|---|---|---|
| Scope | Revised every cycle | Fixed before build starts |
| First working software | End of the first cycle | After the testing phase |
| Customer feedback | At every cycle review | Mostly at acceptance |
| Documentation | Written in step with the code | Produced per phase as sign-off gates |
The sequential waterfall approach runs requirements, design, build, test and release in strict order. Royce’s 1970 diagram splits that into 7 stages, from system requirements through operations.
Winston Royce’s paper, published in the Proceedings of IEEE WESCON in August 1970, is the usual citation for the sequence. He never used the word waterfall.
Sources disagree on what he meant. Robert C. Martin (C++ Report, February 1999) says Royce’s paper describes an iterative and incremental style, and suggests managers took one or two of its illustrations while ignoring the text. A 2016 ProjectManagement.com commentary reads it differently. It finds sequential phases and heavy documentation in Royce’s process alongside iteration and customer involvement, so it treats the paper as a foundation for both agile and modern waterfall.
Hybrids are common enough that PMI and the Agile Alliance gave them their own sections in the Agile Practice Guide (2017), including combined agile and predictive approaches.
For a phase-by-phase view, read this agile and waterfall comparison.
When does agile development stop working?
It breaks down when a contract fixes scope and price, when regulated sign-off stages can’t be skipped, when nobody really owns the product, or when the team can’t get at its users.
Conditions where it fails
Fixed scope and fixed price is the first clash. The more both are fixed, the further the contract moves from agile contracting, according to Browne Jacobson’s 2022 legal update. Pricing per iteration or per deliverable avoids the clash.
A fixed-scope contract usually hangs on a detailed software requirement specification, and changing it mid-project triggers formal change orders.
Regulated sign-off is next. Standards demand documented, verified activities at set gates, and a sprint cannot skip them.
Regulated work adds software compliance obligations that a sprint cannot shorten. IEC 62304, the medical device software standard, specifies no lifecycle model, so agile teams can use it, but it still requires every activity to be documented and verified.
Both camps agree agile development can comply, but they differ on the cost. AAMI TIR 45 (2012) holds that agile practices, applied within a quality system and safety risk management, can meet regulatory expectations of well-documented development. The Johner Institute is less optimistic. It says the hope of cutting documentation effort is mostly not met, and that attempts often end in a high share of documentation that does not improve quality.
Weak product ownership is simpler to spot. If nobody orders the product backlog, sprint planning has no input and the team guesses. And a review without real users only tests the team’s own assumptions.
What faux agile looks like
Of the respondents using agile in Digital.ai’s 17th State of Agile report (2024), only 11% were very satisfied and 33% were somewhat satisfied.
The report names mixed agile approaches, organizational resistance to change, a lack of understanding among leadership and internal silos as the obstacles to enterprise-wide adoption.
Faux agile is what usually sits behind numbers like that. Teams keep the ceremonies and drop the values. Atlassian’s Manifesto article has signatory Ron Jeffries using the label Faux Agile for approaches that have turned negative.
Martin Fowler uses the same term in his 2018 Agile Australia keynote for agile that is only a name, with none of the practices and values in place.
A caution on reading the surveys. The 18th edition (2025) drew nearly 350 participants, mostly agile coaches and consultants at organizations with over 20,000 employees. That pool is narrower than the software professionals surveyed a year earlier, so the two editions do not form a clean trend line.
A decision rule for choosing
If requirements are uncertain and users can answer questions inside a cycle, go with agile development. Waterfall or a hybrid makes more sense once a contract or regulator fixes scope and approvals in advance.
Most cases come down to one question. Who can change the scope mid-project? If nobody can, agile development has nothing to adapt.
How do teams start with agile development?
Begin with a single team on a single product backlog, running one framework, and widen the scope only after the team has finished its first few cycles.
First steps
Digital.ai’s 17th State of Agile report (2024) found that 52% of respondents at small organizations say enterprise agile works very or somewhat well, against 43% at larger companies. That gap argues for a pilot with one team on one product.
Scrum is the usual first pick because the Scrum Guide names every role, event and artifact. A new team can follow Scrum as written, then adapt it once it knows why each piece exists.
Tools for backlogs and boards
Atlassian’s Jira Software documentation (as of October 2026) describes a scrum board for teams that plan their work in sprints and a kanban board for teams that manage and constrain work in progress.
Kanban boards started as physical boards with cards, Atlassian notes, and a wall with sticky notes still works for one co-located team.
Teams that only need visual boards can start with a lightweight kanban app such as Trello and add a backlog column by hand.
What goes wrong in the first months
Digital.ai’s 15th State of Agile report (2021) listed inconsistent processes across teams and a lack of agile skills among the top challenges.
Inconsistent practice gets fixed by agreeing on one definition of done and one sprint length before a second team joins, with a single board layout across both. Thin skills are a different problem. Pair the pilot with someone who has run sprints before, and keep the Scrum Guide open during the first retrospectives.
Skipping the retrospective is the quickest way to freeze both problems in place.
Agile Development FAQ
What are the benefits of agile development?
Respondents to Digital.ai’s 17th State of Agile report (2024) named improved collaboration and better alignment with the business as the top benefits. Small organizations also reported better software quality.
The same report says those benefits have yet to reach their expected potential, and that medium and larger companies face the most barriers to scaling agile.
Is agile development the same as DevOps?
No. Agile development governs how a team plans and builds software in short cycles, while DevOps covers the handoff into deployment and operations. The two overlap, and this breakdown of the difference between agile and DevOps shows where.
Does agile development work outside software?
Yes. The Agile Practice Guide (2017), written by PMI with the Agile Alliance, notes that project teams use agile approaches in industries beyond software development.
The software vocabulary (sprints, increments) carries over to other fields with light renaming.
Which certifications exist for agile development?
Scrum.org, Scrum Alliance and PMI each run credentials. Scrum.org’s Professional Scrum Master I assessment has 80 questions, a 60-minute limit and an 85% pass mark.
The Agile Alliance itself endorses no methodology or certification, according to the Agile Practice Guide.
How to Tell Whether Agile Development Is Working
Agile development is working when each sprint review shows software that users can run and stakeholder feedback changes the order of the product backlog. Meetings that produce neither result are overhead.
A few signals are worth checking, cheapest first. Does every sprint review show runnable software? Does feedback reorder the product backlog? And how many days does an item take from started to done? That last one is cycle time.
The order follows cost. The first two need no tooling, while cycle time needs a board that the team keeps current.
Board upkeep is the trade-off. Every item carries a small status-update overhead, and the team accepts it in exchange for a measure that does not depend on opinion.
Teams still weighing methods can compare other software development lifecycle models before committing to one.
- Notepad++ Android Options: Apps That Come Close - October 21, 2026
- Data Management Services: A Practical Guide for Growing Companies - October 21, 2026
- MongoDB Cheat Sheet - October 20, 2026
