How software projects are run: agile and Scrum
Agile is an approach named by a 2001 manifesto: split work into small pieces and show working software often. Scrum is its most common framework — the 2020 Scrum Guide defines three accountabilities (Product Owner, Scrum Master, Developers), five events (the Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective) and three artefacts (Product Backlog, Sprint Backlog, Increment). For a client it means seeing a working release every couple of weeks and being able to change direction.
- Short cycles instead of a long specification
- A working release at the end of every sprint
- The client sets the priority order
- Change is expected, not a failure
What is agile?
Agile was named by the Manifesto for Agile Software Development in 2001. Its four values and twelve principles prioritise working software, collaboration with the customer and responding to change over heavy documentation and rigid plans.
How Scrum works
Scrum is the most common agile framework, defined in the Scrum Guide, currently the 2020 edition:
- Three accountabilities: Product Owner (decides what and in what order), Scrum Master (removes obstacles), Developers (do the work).
- Five events: the Sprint (usually 1–4 weeks), Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.
- Three artefacts: Product Backlog, Sprint Backlog and the Increment — the working piece finished this sprint.
What it means for the client
- You see progress often. Each sprint ends with a demo; progress is shown on screen, not described in words.
- You set the order. Deciding what gets built first is the client's job.
- You can change direction. A change enters the next sprint rather than being refused as "too late".
Common misunderstandings
- "Agile means no plan." The opposite: planning happens more often, just over shorter horizons.
- "No documentation." Enough to explain the product, not enough to sit on a shelf.
- "No dates." Dates exist. The team and the time are fixed; the scope flexes.
- "Every team should run Scrum." Smaller teams are often better served by something leaner, such as Kanban.
How we run it
Full Scrum ceremony is heavy for a small studio. We keep the short cycles and cut the meetings: a release every week, a one-page priority list and a short weekly review. Our way of working is described step by step on the process page.
The point of agile isn't writing faster; it's noticing the wrong thing early.
Sources
Frequently asked questions
How long is a sprint?
Usually one to four weeks: a week on small projects, two weeks on larger products.
How is pricing handled?
Either fixed scope and fixed price, or time and materials. If scope is expected to move, the second is more honest.
Do I have to attend every meeting?
No. Two matter on the client side: planning and the end-of-sprint demo.
Does Scrum suit small teams?
Full ceremony can be heavy. A leaner setup works as long as the priority list and regular demos stay.
