Agile software development is a way of building software in short cycles, where the team ships working pieces, collects feedback, and expects the plan to change. It is often called the agile methodology for software development, and it grew out of a 2001 statement of values. This guide explains what it is, how an iteration runs, and when it fits a custom software development project.
What is agile in software development?
Agile is a set of values and practices for building software in small increments and adjusting the plan as the team learns. Each increment is working software that someone can use or review.
Agile is an umbrella over several methodologies. In TekRevol’s summary, Scrum and Kanban put its values into practice, and they differ mainly in how they schedule work.
Agile in software engineering is best read as a way of managing uncertainty. In TekRevol’s reading, when nobody can describe the finished product in advance, short cycles let the team learn from real use before committing more money.
Where agile came from
Agile was named at a meeting of seventeen practitioners at the Snowbird ski resort in Utah in February 2001. They came from lightweight methods such as Extreme Programming and Scrum, and they signed the Manifesto for Agile Software Development.
The meeting grew out of an earlier gathering in Oregon in spring 2000, where attendees backed lighter methods but made no formal decisions. The Manifesto itself is short: four values and twelve principles.
Agile principles: the four values, read plainly
The Manifesto sets four values, and each one prefers one thing without dropping the other. The authors say the items on the right still have value, but the items on the left are valued more. The table reads each value in practice, and it is TekRevol’s reading of the Manifesto’s wording.
| Value | What it means in practice | What it does not mean |
| Individuals and interactions over processes and tools | Talk directly to the people doing the work | Drop all process |
| Working software over comprehensive documentation | Show something that works in every cycle | Write no documentation |
| Customer collaboration over contract negotiation | Involve the customer throughout the build | Ignore the contract |
| Responding to change over following a plan | Adjust the plan when the team learns something | Work with no plan |
The twelve principles add detail. They ask teams to deliver working software every few weeks, welcome changing requirements even late, work with the business every day, and keep a pace the team can sustain indefinitely.
Some lists online, such as the “5 C’s of Agile”, are not part of the Manifesto. The Manifesto lists four values and twelve principles.
The agile life cycle: how one iteration runs
An agile project repeats one short cycle until the product is done, so the agile development process is a loop. In Scrum, the cycle is called a Sprint, and the 2020 Scrum Guide caps it at one month or less. The Agile Manifesto’s range is between a couple of weeks and a couple of months, with a preference for the shorter timescale.
The agile life cycle runs the same phases as the software development life cycle, only in small loops instead of one long pass. Each loop plans, builds, tests, and reviews a small slice of the product.
| Step | What happens | Output |
| Backlog refinement (ongoing) | The product owner orders the list of work, and the team clarifies the top items | An ordered backlog |
| Sprint planning | The team agrees a sprint goal and picks the items it can finish | A sprint goal and a sprint backlog |
| Daily work and daily check | The team builds and tests, with a 15-minute daily check on progress toward the goal | Working software that grows each day |
| Sprint review | The team shows the result to stakeholders and gathers feedback | Feedback and backlog changes |
| Retrospective | The team reviews how it worked and identifies the most helpful changes | Changes to try in the next sprint |
The steps follow Scrum. In TekRevol’s summary, Kanban works on continuous flow, with limits on work in progress instead of fixed cycles, and the idea of short feedback loops is the same. Work that does not meet the team’s Definition of Done cannot be shown at the review, and it returns to the backlog.
Roles on an agile team
A Scrum team has three accountabilities, and the Scrum Guide says a team is typically ten people or fewer:
- Product Owner. Maximizes the value of the product and manages the product backlog.
- Scrum Master. Helps the team follow Scrum and removes obstacles.
- Build the product, keep to the Definition of Done, and adjust their plan every day.
On an outsourced project, the client usually supplies the Product Owner. TekRevol’s custom software development process includes a Discover stage, a Validate stage with an MVP, and two-week agile sprints with sprint reviews.
An example of agile delivery: a booking app in two sprints
TekRevol’s illustration: a clinic asks for an appointment booking app. The team and the clinic’s office manager, who acts as product owner, write the backlog as short user stories, such as “a patient can book a free slot” and “staff can see the day’s appointments”. They order the list by value and agree on the first sprint goal: a patient can book an appointment.
At the end of the two-week sprint, the team shows a working booking screen on a test server. At the review, the office manager says staff also need to see cancellations as they happen, because empty slots cost the clinic money. That request was not in the first backlog.
The product owner moves cancellations to the top of the list, and sprint two delivers them. Nothing already built is thrown away, and the clinic has a usable booking flow after the first sprint.
In a plan-first project, the same change would need a change request. In agile delivery, it is a normal reordering of the list.
Agile methodologies: Scrum, Kanban and Extreme Programming
Agile approaches fall into two groups: those that schedule work in fixed cycles and those that move work through a continuous flow. In TekRevol’s judgment, Scrum is the best-known cycle-based methodology, and Kanban is the best-known flow-based one. Kanban uses a visual board and limits on work in progress.
In TekRevol’s summary, Extreme Programming adds engineering practices such as test-driven development and pair programming. These agile development techniques can sit inside Scrum or Kanban, and in TekRevol’s reading, teams that follow agile best practices pair a planning methodology with these engineering habits. Our guide to software development methodologies compares the main approaches in depth.
Advantages of agile delivery
The main advantage of agile delivery is early, steady feedback on working software. The benefits below come from the short cycle, so they shrink when the cycle gets long:
- Working software early. A usable increment exists after the first cycle, so the client can judge real progress.
- Change is normal. The Manifesto welcomes changing requirements, so a new idea becomes a backlog change instead of a dispute.
- Visible progress. A review at the end of each cycle shows stakeholders what was built.
- Problems surface sooner. Defects and wrong assumptions appear while the work is small and cheap to fix.
- The team improves as it goes. Each retrospective identifies the most helpful changes to try in the next cycle.
Disadvantages of agile delivery
The main disadvantage of agile delivery is that it asks more of the client and gives less certainty about final scope and price. This list is TekRevol’s reading of the common failure points.
- Client time. A product owner must be available, because an open decision blocks the sprint.
- Open scope. In TekRevol’s judgment, scope moves, so a fixed price needs a swap rule written into the contract.
- Documentation can slip. The values do not forbid documentation, but a team that reads them as permission to skip it leaves gaps at handover.
- Coordination at scale. Many teams on one product need a coordination layer, such as a scaling framework.
- Team maturity. Self-organizing teams need senior people who can estimate and decide.
When to use agile delivery
Use agile delivery when requirements will change, users can give feedback, and someone can decide every week. The TekRevol Agile Readiness Check turns that into five questions. The check is TekRevol’s judgment.
| Question | Ready for agile | Not ready yet |
| Are the requirements likely to change? | Yes, users will react once they see the product | No, the scope is fixed and agreed |
| Can one person decide each week? | Yes, a named product owner has the time | No, decisions take weeks |
| Can you accept a capped budget with flexible scope? | Yes | No, a fixed scope and price are required |
| Can the team release small increments safely? | Yes, tests and deployment are automated or planned | No, each release is a large manual event |
| Do you have users who can give feedback? | Yes, within each cycle | No, feedback comes only after launch |
Four or five answers in the middle column point to agile. Mostly answers in the last column point to a plan-first approach, or to preparing the missing pieces first. Our agile vs waterfall comparison covers the choice between the two models.
Thinking about running your project the agile way?
If you want to know whether your project is ready for agile delivery, bring your budget and the person who will own the backlog to a conversation. TekRevol is a software development company that delivers in agile iterations within a capped budget and states upfront which parts of a project are not negotiable. Start with a Free Consultation.
