I think there is a fundamental difference between old-school exhibitions on one side and agile web development on the other.

The exhibition process basically goes like this:

  1. plan the exhibition (behind closed doors)
  2. produce the exhibition (behind closed doors)
  3. build the exhibition (behind closed doors)
  4. Done! Then: open exhibition to the public.

While the typical agile web project is more like this:

  1. Plan the web experience (behind closed doors)
  2. Build prototype/beta (behind closed doors)
  3. Open the web to the public.
  4. Test & analyze, then go to step 1

or, more generalized:

curating:

  1. build
  2. launch

web:

  1. launch
  2. build & repeat

The difficulty with involving curators in digital media is, in my personal experience, that they feel quite uncomfortable to do the “curating” in public, letting the audience see & try out the unfinished projects. Also, they feel dissatisfied that you cannot “close the book” and finish a project, but that web pages require continuous attention. This also identifies the main problem with most “web exhibitions” produced so far – they are static products, permanent presentations. In comparison with the surrounding web – interactive, ever-changing – they feel a bit dull and misplaced and would often fit better into a book format. The exhibition web often happens to be the exhibition catalogue, with added multimedia.

As a curator myself, I have grappled with these problem and think that a solution might be found in actually revising “finished” exhibitions, to continue to edit them, let visitor interactions become part of the exhibition, etc. I think communication is changing towards more dialogue and less broadcasting, without losing the authority of the museum voice.

A big problem, though, is that agile development is quite hard to achieve within the framework of Swedish governmental authorities. To avoid corruption and streamline the procurement process, we have to make detailed requirement specifications for every project of a particular size, and then offer the project to a selected shortlist of vendors/suppliers – that is, extremely “inagile”. (Note to the reader: I am quite new in this government-run museum world, and I suppose there are ways to do this procurement efficiently without having to plan an entire project start to end. Please let me know!)

You Swedish curators out there – does this feel familiar? Is there something to learn from the coders, or am I on the wrong track here?