Agile is the most misused word in software development. Teams claim to be agile while running processes that are neither flexible nor effective. Understanding what agile actually means, and what the common distortions look like, helps you evaluate whether the team you are working with is using agile to deliver better software or to avoid accountability.
What agile actually is
Agile is an approach to software development that prioritizes iterative delivery over comprehensive upfront planning. Instead of specifying everything before writing code and then building for months before showing anyone anything, agile teams work in short cycles (sprints), deliver working software frequently, incorporate feedback continuously, and adapt plans based on what they learn.
The Agile Manifesto (2001) summarized the values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
These are preferences, not absolutes. The manifesto says "while there is value in the items on the right, we value the items on the left more."
What agile is not
Agile is not the absence of planning. Agile teams plan constantly. They plan sprints. They maintain backlogs. They do technical design before writing code. The difference is that planning is continuous and responsive rather than comprehensive and fixed upfront.
Agile is not the absence of documentation. It is the prioritization of working software over comprehensive documentation. Documentation that helps developers understand the system, APIs, and data models is valuable and does not contradict agile principles.
Agile is not a justification for vague requirements. "We're agile so we don't need a spec" is not agile. It is improvisation. Agile teams have clear requirements for each sprint's work. The difference is that those requirements are defined shortly before the sprint, not months before it.
Agile is not an excuse for not estimating. Agile teams estimate work using story points or similar relative measures. These estimates inform sprint planning and velocity tracking.
The sprint model
Most agile teams work in two-week sprints. At the start of each sprint, the team selects a set of tasks from the prioritized backlog. They work on those tasks for two weeks. At the end, they review what was completed, demonstrate working software, and plan the next sprint.
This model provides several benefits:
Visibility. Every two weeks, you see working software. You know exactly what was built and you can evaluate whether it meets your needs before the team moves on.
Feedback loops. When you see a feature in a sprint demo and realize it does not work the way you imagined, you can course-correct before two more sprints of work build on that wrong foundation.
Prioritization flexibility. At the start of each sprint, priorities can be adjusted. If a competitor launches something that changes what you need to do next, you can change direction without losing the work already done.
The common ways teams distort agile
Agile as an excuse for no delivery commitments. Some teams use agile to justify an inability to say when anything will be done. "We're agile" should not mean "we have no idea when you will have a working product." Agile teams can forecast delivery timelines based on velocity. If a team cannot give you a reasonable estimate of when key features will be complete, that is a problem independent of the methodology.
Sprint demos that are not real. A genuine sprint demo shows working software doing real things. A sprint demo that shows slides, mockups, or demos of features that are not actually integrated is not a demo. It is a presentation. If a team consistently shows you presentations rather than working software in demos, the sprint process is not producing what it claims.
Endless sprints with no clear roadmap. Agile does not mean you never know what you are building next. There should be a product roadmap that shows the direction of the product over the next several months, even if the specific sprint contents are defined closer to the sprint start. If a team cannot tell you what the next major milestone is, that is poor planning, not good agile practice.
Using backlog grooming to avoid scope conversations. A well-maintained product backlog contains prioritized features with enough detail to plan and estimate. When teams claim they will "groom it later" as a way to avoid defining requirements, they are not practicing good agile.
Agile without retrospectives. The retrospective is the sprint event where the team reflects on how the last sprint went and what to improve. Teams that skip retrospectives miss the primary mechanism by which agile processes improve over time.
What good agile looks like from the outside
You see working software at the end of every sprint. Features in the demo are fully functional, not mocked.
You have visibility into the backlog and can influence priorities. The team is not executing a plan defined without your input.
When something unexpected happens (a technical discovery, a change in your requirements), the team adjusts the plan rather than either ignoring the change or stopping to rewrite the entire project plan.
The team improves over time. Sprint velocity increases or stabilizes as the team gets into rhythm. The quality of sprint demos improves.
Our development process is built around two-week sprints with genuine working software demos. Get in touch to discuss how we structure agile delivery for client projects, or hire a dedicated development team that works this way from day one.