Skip to content

agile

Agile is an approach to software development that delivers work in short, repeated cycles and treats changing requirements as normal rather than as a failure of planning. The name comes from the Agile Manifesto, a 2001 document in which seventeen developers set out four values that favor working software and close collaboration over heavy process and documentation.

In the manifesto’s own words, the four values each prize one thing over another:

  • 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 manifesto grants that the items on the right still have value, but an agile team weights the items on the left more heavily. Twelve supporting principles draw out the consequences, from delivering working software every few weeks to having the team reflect and adjust its habits at regular intervals.

How It Shows Up in Practice

A Python developer rarely meets agile as an abstraction. It arrives as the way a team organizes its work: short iterations, a shared backlog of user stories, a daily standup, and a review and retrospective at the close of each cycle, all tracked on a board in a tool such as Jira, Linear, or GitHub Projects. A single iteration, usually called a sprint, runs the same loop every time:

Four stacked boxes top to bottom (teal Plan, white Build, white Review, yellow Retro) joined by solid down arrows, with a dotted "next sprint" arrow running up the right side from Retro back to Plan.
Every sprint runs the same loop, closing with a retro that feeds one change into the next round.
Language: Text 
two-week sprint
  plan    ->  pull user stories from the backlog
  build   ->  code, review, merge, and test each day
  review  ->  demo working software to stakeholders
  retro   ->  agree on one process change for next time
  repeat

The vocabulary of that loop fills much of this area. The size of a backlog item is estimated in story points, an item counts as finished only when it satisfies the team’s definition of done, and a first release is often scoped down to a minimum viable product. “Comfortable working in an agile environment” is also one of the most common lines in a Python job posting, which is the other reason the word is worth pinning down.

Agile vs. Waterfall

Agile is usually defined against waterfall, the older model it reacted to. A waterfall project moves once through a fixed sequence of phases. It gathers every requirement up front, then designs, builds, and tests in turn, so working software appears only near the end.

Agile replaces that single long pass with many short ones, assuming from the start that requirements will change and shipping something usable early so real feedback can steer the next cycle.

Neither model is automatically correct. Waterfall can suit work with fixed, well-understood requirements and a hard regulatory sign-off, while agile fits the more common case where a team discovers what to build by building it. Agile is a philosophy rather than a procedure, though, so teams adopt a named framework to put it into practice. The two most common, Scrum and Kanban, turn these values into concrete roles, events, and artifacts.

Continuous Integration and Deployment for Python With GitHub Actions

Tutorial

Continuous Integration and Deployment for Python With GitHub Actions

With most software following agile methodologies, it's essential to have robust DevOps systems in place to manage, maintain, and automate common tasks with a continually changing codebase. By using GitHub Actions, you can automate your workflows efficiently, especially for Python projects.

advanced devops

For additional information on related topics, take a look at the following resources:

By Martin Breuss • Updated June 22, 2026
Software Engineering Glossary Share Feedback