Iteration revisits work; increments add to what is built
Agile software development can be understood through two related ideas: iteration and increment. Iteration revisits or refines work; an increment adds to what has been built. Agile emphasizes how you and your team respond to changing understanding of the work, rather than requiring every project to follow the same fixed recipe.
That distinction matters when you encounter labels such as Scrum or Kanban. A team can use Agile principles without treating one framework as the definition of Agile itself. The approach emphasizes people, customer feedback, and working solutions over rigid processes and documentation; it does not make every process or record unnecessary. The useful question is what helps you collaborate, learn, and adapt while building the software.
The Agile Manifesto emerged from a February 11–13, 2001 meeting in Utah, where 17 people sought common ground on software development. That origin is consistent with treating Agile as a set of shared principles rather than a single implementation manual.
For your project, use the term to describe an orientation toward collaboration, feedback, and adaptable work. Then look at the actual practices your team proposes. Their names alone do not tell you how decisions get made, how feedback reaches the work, or what kind of software is delivered.
Feedback guides the next cycle of design and development
Agile project management is an iterative development process that continuously gathers feedback from users and stakeholders to create the right user experience. This makes feedback part of the way work proceeds, not simply a final reaction after everything has been built. The approach connects repeated work on a product or service with opportunities to learn from the people involved.
A practical way to picture the cycle is to:
- Identify a question or part of the work that needs attention.
- Design or develop a response.
- Put the resulting work in front of the relevant users or stakeholders when appropriate.
- Consider what their feedback means for the next cycle.
This is a thinking aid, not a required Agile ceremony or a universal schedule. The useful feature is the connection between doing work and using feedback to guide what happens next.
Feedback informs decisions; it does not automatically decide them. You still need to interpret what you hear, relate it to the purpose of the software, and decide what should change or continue. A request, observation, or concern may point to a useful adjustment, but your team has to make that judgment in the context of the work.
This also explains why iteration is more than dividing a project into short periods. A recurring schedule without a way to consider feedback may repeat activity without changing what the team understands. Conversely, feedback that arrives but never affects a later decision is not doing the work described by an iterative approach. The connection matters: each cycle gives you another chance to reconsider the design or build based on what you have learned.
If you are assessing a proposed process, ask where feedback enters the work and how it can shape a subsequent decision. You do not need a particular meeting name to ask that question. The answer should make the path from feedback to later work understandable.
Iteration revisits work; increments add to what is built
Iteration and increment describe related but distinct aspects of development. Iteration means returning to design or development work to reconsider or refine it. An increment means adding a portion to what has been built. Agile frameworks such as Scrum are built on iterative and incremental development.
You can keep the distinction clear with two questions: What did you revisit or adjust? What new portion did you add? The first question focuses on learning and refinement across cycles. The second focuses on how the product or service grows in pieces. A cycle can include both, but you do not have to treat every revision as a new addition or every addition as proof that earlier assumptions have been reconsidered.
For example, suppose your team is developing a user-facing feature. Adding a small part of that feature is an increment. Showing the work to users or stakeholders and then changing its design in response is iterative work. The example separates the two ideas without prescribing a particular feature, release pattern, or method for your project.
The distinction helps you describe what a plan actually accomplishes. If a plan emphasizes iterations, ask how the work can be revisited as understanding changes. If it emphasizes increments, ask what portions are expected to be added over time. If it uses both ideas, ask how feedback and additions relate: does an increment create something the team can learn from, and can that learning shape later work?
These questions help you talk about delivery with more precision than the word “Agile” alone provides. They also keep progress from being reduced to a single measure: work may be refined, expanded, or both, and those are different kinds of movement.
Agile is broader than Scrum or any single method
Agile is the broader approach; Scrum, extreme programming, Lean, and Kanban are among the methods used to carry out an Agile process. Naming a method tells you more about the chosen structure, but it does not by itself explain how your team will apply it.
The available methods include:
- Scrum
- Extreme programming
- Lean
- Kanban
These examples are not an exhaustive menu or a ranking. They show why it is useful to separate the principle from the method: Agile describes an orientation toward adaptable, collaborative work, while a method provides a way to organize practices.
Teams can tailor Agile practices to their needs and may blend frameworks such as Scrum and Kanban. Tactics for using Scrum also vary with context. Together, these points argue against choosing practices by label alone: the same framework name does not describe every detail of how work is handled.
When you examine an approach, look for the practical arrangement behind its name. How does work move from an idea to design and development? Where can users or stakeholders offer feedback? How does your team decide what to revisit and what to add? These questions let you assess whether the described practices support the work you need to do, without assuming that a particular method automatically fits every project.
You can also treat a method as something to examine and adjust rather than as a complete answer. The approach is adaptable, but that does not mean practices should change without a reason. Make the purpose of a practice clear, then consider whether it helps your team collaborate, use feedback, and work toward useful software.
Working solutions do not remove documentation needs
Agile’s preference for working solutions over rigid processes and documentation is a statement about emphasis, not a rule that documentation has no place. Working software and useful records answer different questions. Software shows what has been built; records can help make decisions and work understandable. The Agile principle does not, by itself, determine what records your project needs.
That distinction is especially worth keeping in view when you work on fintech or healthcare software. Do not use the word “Agile” as a reason to set aside documentation or evidence that your project’s obligations call for. At the same time, a preference for working solutions does not require you to turn every activity into a rigid paperwork process. The practical task is to understand what matters for your project and fit that work into the way development proceeds.
Use questions like these to make the boundary concrete:
- What records or evidence does your project need to maintain?
- Which work, decisions, or changes should those records make understandable?
- Who will keep the relevant information connected to the work as it develops?
- How will your team tell whether its approach to documentation still fits the project?
These are prompts for discussion, not a universal checklist of required records. Their purpose is to keep two concerns visible at once: the team needs working solutions, and it needs to understand the documentation expectations that apply to its own work. Agile describes an approach to organizing development; it does not settle that project-specific question for you.
Regulated teams must assess security and evidence separately
For fintech and healthcare software, Agile can describe how your team organizes work, receives feedback, and adapts. It does not establish that the resulting software meets applicable regulatory or security obligations. Those are separate questions for your project. An iterative schedule or a set of working increments should not be mistaken for proof of compliance, security, or project success.
Keep the distinction visible when planning. Your delivery approach answers questions about collaboration and the progression of design and development. Your project’s applicable security, traceability, risk, and evidence needs require their own consideration. Agile alone does not tell you which obligations apply, what evidence is needed, or whether a particular product meets them.
A security-focused example appears in the April 2024 initial public draft of NIST SP 800-218A. That draft recommended reusing existing, well-secured software when feasible to lower development costs, expedite development, and decrease the likelihood of introducing additional security vulnerabilities. It described reuse as particularly important for software that implements security functionality, including cryptographic modules and protocols.
The recommendation is bounded: it concerns existing software that is well-secured, and it says to reuse it when feasible. It is not a reason to assume that any existing component is suitable or that reuse settles your project’s security considerations. For your planning, it can prompt a focused question: where security functionality is involved, is there existing, well-secured software that is feasible to reuse?
This keeps Agile’s potential usefulness and its limits in the same frame. Feedback and iteration can help your team adapt its design and development work. They do not replace attention to security choices or the evidence your project needs. Reuse, where feasible and appropriate to the project, is one consideration from a security-development recommendation; it is not a complete security process.
If you are working in financial services or healthcare, make the relationship between delivery practices and project obligations explicit. Ask which concerns need attention alongside the next development cycle, who is responsible for addressing them, and how the team will understand whether its approach remains appropriate. Those questions do not turn Agile into a compliance method. They help you avoid confusing a way of organizing work with a conclusion about compliance or security.
Choose practices that fit the project’s constraints
Choose Agile practices by looking at the work they need to support, not by assuming that a framework name settles the decision. Teams can tailor practices or blend frameworks such as Scrum and Kanban, and tactics vary with context. A useful starting point is to name the feedback your team needs, the work it expects to revisit, and the portions it expects to add.
You can then review the proposed approach with a few practical questions:
- How will collaboration and feedback fit into design and development?
- What will your team revisit, and what will it add as an increment?
- What documentation, security, traceability, risk, or evidence considerations need separate attention for this project?
- How will you tell whether the selected practices remain useful as the work proceeds?
Experimenting with practices and reviewing their effectiveness is a way to consider whether they support collaboration and continuous improvement. Keep the review tied to your project’s aims and constraints; a framework is a structure to work with, not a guarantee of compliance, security, or success.
If your team is evaluating a regulated fintech or healthcare software project, bring its delivery goals, feedback needs, and constraints into the planning conversation. A qualified professional should determine how particular regulatory obligations apply to your work.
What should regulated teams clarify about Agile?
How should a team handle stakeholder feedback that conflicts with project constraints?
Treat feedback as input to a decision, not an automatic instruction. Consider it alongside the software’s purpose and the project’s constraints, then decide whether it should change the design or later work.
Does a working increment demonstrate that regulated software is compliant?
No. An increment shows a portion of what has been built; it does not establish that the software meets applicable regulatory or security obligations. Consider those requirements and any needed evidence separately.
Does software agile development require managers to direct every task?
No particular management behavior follows from the Agile label alone. Agile emphasizes collaboration, feedback, and adaptability, but the team’s actual practices determine how work is directed. Assess the working arrangements rather than assuming a framework name specifies them.