These days, everyone wants to be ‘agile’. At root, it’s a project management discipline that fixes cost and quality, rather than scope – so you never face unexpected surprises at the end of a project (but may not end up with what you originally thought you wanted). That’s normally a good thing: after all, no battle plan survives contact with the enemy.

But like ‘evidence-based policy’ and ‘digital engagement’, it’s also a buzzword risking meaninglessness having been appropriated to mean simply ‘flexible’, ‘undefined’ or ‘cheap’. Used that way, it’s something that gets clients off the hook of having to write a specification up front; and which gives crafty suppliers the ability to skip out of onerous commitments if the going gets tough. So for some people initiating these kind of ‘agile’ projects, there may indeed be some unexpected nasties to come.

The other day, I found myself talking about agile digital projects with a public sector contact who explained she’d originally trained as an archaeologist. She wasn’t familiar with the terminology of agile projects (‘user stories’, ‘backlogs’, ‘sprints’ and so on) but grasped the big picture straight away.

“It’s just like archaeology,” she said. “You don’t really know what the f*** is under the ground until you start digging.”

These days, we find relatively few digital projects that start from a clean slate. A lot of the work we do involves re-developing and re-organising websites which have a history. While you can tell something from clicking around, there’s always more that lies beneath, like fragile bones or unexploded wartime ordnance. The Chief Executive’s pet blog. The unwieldy archive of documents important to a tiny but crucial group of stakeholders. The organisational politics involved in moving a site from one server to another.

I’m no archaeologist, but I can appreciate that the discipline, patience and tools that apply to excavating historic sites can teach digital agencies a thing or two about doing ‘agile’ in the right way:

  1. be prepared to use a range of tools to check out the lay of the land before you disturb a precious relic
  2. accept that rebuilding websites – like changing the culture of organisations – takes patience and humility, and recognise you don’t really know how complicated things will be until you start
  3. respect the past, while living in the present: people who have gone before us have wrestled with decisions over content, designs and stakeholders. We can learn from their struggles and conclusions without meekly inflicting the usability compromises of the past on the users of the future

And with that, I’ll get back to my trowel.

Photo credit: rich_pickler

Get notified of new blog posts by email


Love the analogy, as one who has worked with archaeologists a lot over the years. Archaeological excavation is a destructive process and so there is a principle of only digging when necessary and with some plan and budget for what to do with what is uncovered.
The projects I’ve worked on have included rather thorough desktop research and risk assessments first. They have used the latest technology to try to detect and analyse what is under the surface without digging. Then they might have tried a few test pits, which would give a better idea of the extent of the remains and their condition, and enable a more detailed plan, with phases and costings. If the remains were dug, latest technology was used to record and analyse them, and then to conserve them. It could take many years for the post-excavation report to be written up to share the results of the dig and connect it with other knowledge. Where I’ve worked, the budgets were quite tight and excavations were carried out within the budgetary constraints, and not all the phases of excavation would have been carried out if money were not available.
I’ve always thought of agile project methodology as more akin to how artists and designers work.