Agile working was built for projects where the finish line can move. A release slips a fortnight, a feature drops out of the sprint, and the product still ships.
Other projects get one date and keep it. A charity walk, a city 10k or an outdoor festival happens on the day printed on the entry page, and if you are the one planning it, every piece of work has to bend around that date. I have found that the teams who handle this best stop debating whether agile fits and start sorting their work into two piles. In mass participation delivery, the field where Massive event services operates, the date is fixed months ahead and the permissions that make it legal arrive much later. The stretch between those two points is where an agile approach earns its place, and where it needs firm limits.
Draw a line across the backlog
Every backlog I build for a fixed-date project starts with a line drawn across it. Above the line sit the items with a legal or physical deadline: road closures, safety sign-off, venue access, the delivery of barriers and portable toilets. Below it sits everything that can be reprioritised, from the design of the finisher’s medal to the wording of the pre-event emails. Road closures show why the line matters. A local traffic authority closes roads for a special event with a temporary traffic regulation order, and where the closure runs longer than three days, or the same stretch of road has already been closed for an event that calendar year, the order needs approval from the Secretary of State for Transport. Government guidance asks authorities to seek that approval at least four weeks ahead.
That deadline sits outside any sprint, and your plan has to be built backwards from it.
Items below the line behave the way agile teams expect. You can reshuffle them every week, drop the weakest and pick up a better idea late in the day, which is what the second principle of the Agile Manifesto asks for when it tells teams to welcome changing requirements, even late in development.
Run stand-ups around the permission calendar
Stand-ups still work on an event project, with one change: the first question each time is about the items above the line.
I ask which permission is due next, who is chasing it, and what happens to the plan if it comes back with conditions attached. Progress on the flexible work comes second. That order stops a familiar drift. Creative tasks are visible and satisfying to report on, and a team can spend a whole week of stand-ups discussing the colour of the route signs while the application to the council sits unsent in someone’s inbox. If your stand-up opens on the fixed items every time, they stay in front of the people who can move them.
Bring the Safety Advisory Group in early
Larger events usually go before a Safety Advisory Group, which brings together the local authority, the emergency services and the organiser. HSE guidance on safety advisory groups describes them as non-statutory: they have no power to approve or prohibit an event, and the legal duty for public safety stays with the organiser. Their advice still shapes the plan, which is why HSE encourages organisers to engage with them from the outset.
In agile terms, I treat the group as a stakeholder with a fixed review slot in the calendar. Its comments go into the backlog like any other feedback, and anything it raises about crowd flow or emergency access moves above the line on the day it arrives.
Rehearse the day before you iterate on it
The closest thing an event has to working software is a rehearsal. I walk the route with the people who will steward it, time how long the barriers take to go up, and test every radio channel on site rather than in the office. Each of those turns a line on a plan into something the team has seen work.
The iteration comes afterwards. A retrospective held within a fortnight of the event, while the details are fresh, feeds the backlog for the next edition. I start that backlog with the stewards’ notes from the route walk, pinned to the top.
