Agile is an iterative approach to project management. The team delivers a working increment regularly and adjusts the plan based on feedback, rather than following a specification fixed in advance. Scrum, Kanban, and Scrumban are its main frameworks.
Agile in a web agency takes the shape of two-week sprints, four core ceremonies (planning, daily stand-up, review, retrospective), and a single decision-maker on the client side called the product owner. Each sprint works as a mini fixed-price engagement: both parties agree on the backlog at the start, and priorities are locked until the end of the cycle.
A sprint begins with a planning meeting where we agree on what will be delivered. The team works for ten business days, syncs daily, shows a working increment at the review, and runs a retrospective. The deliverable is a piece of the project that is ready to deploy and review.
What agile actually means in practice
Adopting agile starts with accepting that a project can never be fully captured in an upfront specification. Delivering early to learn from real users and adjust along the way works better than exhaustive upfront planning.
Frameworks like Scrum, Kanban, or Scrumban implement this approach, each answering a different question: Scrum sets the cadence and ceremonies, Kanban keeps work flowing, Scrumban combines the two.
| Framework | Cadence | Ceremonies | Best suited to |
|---|---|---|---|
| Scrum | 2-week sprints | Planning, daily stand-up, review, retrospective | Predictable scope, cross-functional teams |
| Kanban | Continuous flow, no sprints | No mandatory ceremonies, managed by WIP (work in progress) limits | Reactive work (support, maintenance) |
| Scrumban | Hybrid: continuous flow with periodic checkpoints | Lightweight planning, regular retrospectives | Projects mixing planned development and unplanned work |
Agile in a web agency: what changes when the team is external
When the agile team is external rather than internal, the engagement becomes commercial. A sprint commits the agency to the agreed backlog and the client to availability and stable priorities. Scope also drifts faster. The client is not in the room every day, so a request that would have been a five-minute conversation in-house turns into a formal requirement.
That is why we treat each sprint as a mini fixed-price engagement with a backlog locked at the start. New requests feed the next sprint, not the current one, which protects the quality of the work and the predictability of delivery.
This is different from staff augmentation, where the developer joins your team and follows your cadence. In a fixed-price agile engagement, our team runs the sprint with your product owner.
How we structure a sprint
A sprint runs two weeks and is organized around four ceremonies that pace the ten business days. At the start, a planning meeting sets out the work for the cycle; a daily stand-up keeps the team in sync throughout. The review with stakeholders marks the end, followed by an internal retrospective that prepares the next sprint.
The four ceremonies of each sprint:
- Sprint planning (1 to 2 hours, team and product owner): we agree on what will be delivered. The sprint backlog (the list of tasks selected for the cycle) is frozen at the end of the meeting.
- Daily stand-up (15 minutes, team): three questions, what I did yesterday, what I am doing today, what is blocking me. The format is asynchronous by default, unless a blocker needs an immediate response.
- Sprint review (30 to 60 minutes, team and stakeholders): we demonstrate the functional increment, that is, the part of the product completed during the sprint. No slides, a product that works.
- Sprint retrospective (30 to 60 minutes, team only): what worked, what did not, what we change for the next sprint.
The two-week cadence has become the norm in web agencies. It gives the team enough time to produce between two planning sessions, without letting a wrong direction last more than fifteen days before feedback corrects it. Three-week sprints work in some specific contexts.
The client's role in this model
The client is not a spectator. The client takes on the product owner role, which means setting priorities, making the call when the team needs clarification, and signing off the result at every review. Without a designated, available product owner, the sprint drifts.
In practice, "available" means roughly a 24-hour response time during working days, plus showing up reliably for the three ceremonies tied to the role (planning, review, retrospective). A product owner by proxy, who relays questions without authority to decide, is not a product owner but an additional channel that slows decisions down. When this authority is missing, decisions stall, sprint scope slips, and the team finishes the sprint without reaching its objective.
Where agile breaks down with an agency
Several recurring situations weaken agile in an agency context:
- Vague scope at the start. Without a solid requirements document, each sprint begins by renegotiating what was not decided during scoping.
- Distant or disengaged stakeholders. The team builds the right thing only if the people who know what the right thing looks like participate in the reviews.
- Validation chains longer than a sprint. When a deliverable sits three weeks waiting for sign-off, the sprint loses its momentum before the next cycle can pick it up.
- The sprint treated as a feature factory. If each sprint starts from scratch on scope, the team never builds on what it learned in the previous sprint.
When agile and fixed-price coexist
Many web projects combine both models. An agile team drives ongoing platform evolution (sprints, regular increments), while a fixed-price engagement takes on a project with locked scope (migration, redesign, specific integration). It works because each model plays to its strengths: agile handles uncertainty and learning, fixed-price delivers a defined output with a contracted budget and timeline. The two coexist as long as the boundaries stay clear: fixed-price does not absorb ongoing evolution, and agile does not pick up structural projects mid-stream.
A third model exists, in which the engagement stays fixed-price with a signed specification but execution is organized in sprints. The team breaks the requirements document into increments, delivers in short cycles, and keeps the ceremonies of planning, review, and retrospective. The client retains the safety of a contracted scope; the team retains the cadence and delivery quality of agile.
This model works when the specification is complete from the start. When it is not, sprint feedback can still evolve the scope, but only through a change order. On a recent project, after a few sprints delivered, the client realized that some specified features no longer matched the actual need. We did not fold the change into the current sprint. We escalated to the project sponsor, who signed a change order: an addendum to the specification covering the new features, with a revised budget and timeline.
Key takeaways
- Agile is an iterative approach; Scrum, Kanban, and Scrumban are the frameworks that implement it.
- In a web agency, a two-week sprint functions like a mini fixed-price engagement with a backlog frozen at the start.
- Four ceremonies structure each sprint: planning, stand-up, review, retrospective.
- The client takes on the product owner role: available, decisive, validating at every review.
- Agile and fixed-price combine well when the boundaries between uncertainty and locked deliverable stay clear.
Frequently asked questions
What is agile in web development?
Agile is an iterative approach that delivers a web project in short increments (typically two weeks) by integrating client feedback at every cycle, rather than aiming for a single delivery at the end of a fixed specification document.
How long is a sprint in a web agency?
Two weeks is the standard duration. One week generates too much planning overhead; three weeks delay feedback and let wrong decisions persist. In some specific contexts, three-week sprints work better.
What is a product owner in an agile engagement?
The product owner is the person on the client side who sets priorities, makes the call on open questions, and signs off the result at every sprint review. Without a designated, available product owner, the sprint loses its direction.
Is agile better than waterfall for a web project?
The question is poorly framed. The real question is whether your scope is stable or likely to evolve during the project. Agile suits projects whose scope will shift with learning and user feedback. Waterfall remains relevant when the scope is locked in advance and iterations would add little value (regulatory contexts, critical equipment).
What happens if the client is not available during the sprint?
Decisions stall, sprint scope slips, and the sprint objective is not reached. The team can flag that decision authority on the client side is missing, but it cannot substitute for it.
Can you combine agile and fixed-price?
Yes, and it is common on complex web projects. An agile team manages ongoing platform evolution while a fixed-price engagement takes on a project with locked scope. A third arrangement is to run a fixed-price engagement with a signed specification document where execution is organized in sprints, which assumes a well-defined specification from the start.
How does agile in an agency differ from agile at a product company?
In an agency, the sprint is a commercial commitment between two parties, where the agency commits to delivering the backlog while the client commits to being available and holding priorities stable. At a product company, these tensions are less pronounced because the team and the stakeholders belong to the same organization.
If you are evaluating agile in a web agency for your next engagement, our consulting and advisory service is designed for this phase. And if you are ready to start a web development project, contact us.
Keroberos supports web projects in agile mode. To discuss your needs, get in touch.