Agile Software Development

How we actually run delivery

Agile has accumulated a great deal of vocabulary, and most of it matters far less than four habits: work is cut small enough to finish, it goes somewhere you can see it working, progress is visible without anyone having to ask, and the plan changes when reality does. Every framework below is a different arrangement of those habits. We fit the arrangement to the project rather than announcing a methodology on day one.

What we hold constant regardless of framework: a single prioritised backlog rather than several competing lists, a definition of done that includes tested and deployed rather than “works on my machine”, short feedback loops with whoever will actually use the software, and written decisions so a choice made in week three can still be explained in month nine.

Scrum

Scrum organises work into fixed-length sprints — typically two weeks — each producing something demonstrable. A product owner keeps the backlog ordered, the team commits to a slice, and a review at the end shows working software rather than a status report. A short retrospective decides what to change next time.

Scrum suits projects with a genuine product owner available for questions, a scope that will evolve, and stakeholders who benefit from a predictable rhythm. It suits maintenance and support work considerably less well, because unplanned interruptions destroy sprint commitments and the ceremony starts to feel like theatre. If your work arrives unpredictably, read the next section instead.

Kanban

Kanban drops the sprint. Work flows continuously across a board, each column has a limit on how many items may sit in it, and the team’s discipline goes into finishing things rather than starting them. Explicit limits are the whole mechanism: when a column is full, nothing new enters, so bottlenecks become visible instead of accumulating quietly.

This is our default for support and maintenance, for platform and infrastructure teams, and for any work where priorities are re-sorted weekly. The metrics that matter are cycle time and throughput — how long a task takes from start to done, and how many get done — which are more honest indicators than velocity, and much harder to game.

Scaled Agile Framework (SAFe)

Once several teams depend on each other, coordination stops being free. SAFe adds structure above team level: planning across a longer increment, explicit dependency mapping between teams, and shared architectural direction so two teams do not solve the same problem twice, differently.

It is a heavier framework and it earns its overhead only at genuine scale. For one to three teams it usually adds process without adding clarity, and we will say so. Where it does fit — a larger programme, regulated delivery, or several vendors working on one product — the value is in dependency planning rather than in the certifications.

Which one fits your project

• New product, evolving scope, engaged product owner → Scrum.
• Support, maintenance, platform work, shifting priorities → Kanban.
• Several interdependent teams or a regulated programme → SAFe, or the parts of it that pay for themselves.
• Small, well-defined, fixed deliverable → a plain milestone plan. Not every project needs a framework, and pretending otherwise wastes your money.

Agile across time zones

Distributed delivery changes the mechanics: fewer synchronous meetings, more written communication, and overlapping hours reserved for the conversations that genuinely need to be live. How we handle that in practice — working hours, handover, tooling, code review — is covered on our remote software development page, and the two engagement shapes are described under outstaffing and web development outsourcing.