Agile development for museums

By: Dr Lynda Kelly, Category: Museullaneous, Date: 20 Apr 2011

We’ve been thinking lots about agile / rapid development models as we begin to delve into the wonderful world of apps. But, what is it and what does it mean for museums? 

Jurassic Lounge Sketch 2

Jurassic Lounge Sketch 2
Photographer:  © Australian Museum

Are museums ready for agile?
Museums are strange beasts. Often slow to respond, working within a model of exhibition development based on large project teams, long timelines and (sometimes) big budgets. This has resulted, I believe, in a mindset that is not attuned to the idea of agile / rapid development of projects, where an iterative process is the key, resulting in releasing a product that may only be half-finished. Again, this is often anathema to museum folk brought up on the exhibition development model. Even though we often talk about the exhibition not being finished the day it opens, how often do we make changes and updates, as well as accepting that not everything has to be “perfect” on opening day?

So, how to do it?
Of course, Wikipedia was first port of call, with their article about agile software development, with this really useful diagram demonstrating that the process of agility is strategy, release, iteration, daily, continuous.

Actually the first point of call was Twitter and the very wonderful #mtogo group to the rescue. This paper Agile Methods for Project Management by Ellis, et al (2008) is a must-read. They state: “… agile methods directly address the roles of the customer in the planning and development process, as well as the probability of changes in assumptions and requirements that will undoubtedly occur in most projects.” They quote the agile software development manifesto which states that they value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Ellis et al describe their collaboration around developing, detailing the following ideas:

  • Set and focus on milestones
  • Use epics: “Epics are useful in walking the team through the things that occur when a user follows the steps required to make something happen”
  • Break epics down into stories
  • Estimating timeframes: “One of the most difficult parts of successfully managing complex projects involves the estimation of how long any particular set of work will take. Agile project methods address this difficulty by working in short development cycles that result in usable software at each iteration of the cycle”
  • Take baby steps, commit to producing a workable product at the end of each cycle
  • Test, test and test
  • Take regular ‘sanity checks’ – ensure the product really meets your needs and if not be agile and change it!
  • Take time to reflect [this is critical and we don’t do this enuf!] – they used a series of exercises. Me? I’d just take good notes and blog them

One thing that struck me was this comment: “... adhering to such a structured method of working together requires discipline and persistence from the team” – this suggest that while you need to be agile, you also need a set of underlying processes and structures in order to do this.

What could we do?
We’re going through a deep thinking process, with a final approach that might look something like this:

  • Focus on a small achievable product
  • Find a small dedicated, key audience, work with them, then expand outwards
  • Use only 5% of budget to launch, then another 5% to update, then another etc etc
  • Test often, iterate as needed
  • Bring in an external critical friend to help guide, critique and keep you on-target

What has to change?
This does mean however, that the traditional exhibitions model described above won’t work in the agile approach, but what we need to remember is to:

  • downgrade our expectations of what is produced
  • realise that the first release (and second and third, and so on…) is a prototype and will change
  • be incredibly audience-focused
  • be more open-minded and willing to celebrate and learn from failure (and successes of course!)
  • be willing to not worry about getting a large sample to test on, but getting the right sample
  • be willing to focus on this for a set time period with no other interruptions (well, this may not be realistic but is a good target to have – it’s all hands on deck a few weeks out from an exhibition opening, why not for an app?)

I also think this model can be used across a broader range of museum processes and am keen to get started!

BTW I am indebted to Russ and Jen from the webteam who came up with the final approach and changed my thinking, any errors or misunderstandogs in this blogpost however are my own.


JanetB - 1.05 PM, 02 May 2011
This sounds great. You make a really interesting point about the vast difference between an exhibition process and software development - definitely sounds like a unique challenge. I like your point about the need for robust process. Sometimes people assume that because Agile eschews large amounts of documentation etc that it is somehow easier or less process-oriented. Agile is hard, and it requires real commitment to the process in order to make it work, but when it works it is hugely effective. On your point re: taking time to reflect, this is definitely a very important part of the Agile process. Taking notes is great, but I would definitely recommend doing regular 'retrospectives' (at the end of each sprint). These are an extremely effective way to ensure that you are continually improving your process, and that any concerns the team has are addressed. I could keep rambling on, but I won't leave a ridiculously long comment here! Feel free to get in touch on twitter (@janakin) if you'd like me to go on about transparency and self-organising teams :)
Lynda Kelly - 6.04 PM, 20 April 2011

@Russ, the cynic in me says "no we can't" but  I don't see why not. Imagine if we'd have done that for a project a large as the new permanent exhibitions or the website dev?

I'm thinking tho that the best model for large-scale developments maybe lies somewhere in between perhaps? I don't think our industry is quite ready for such a radical change yet!

Russ Weakley - 5.04 PM, 20 April 2011

 A great recap of the overall strategy. It would be great to see if the Museum could adopt this more widely. It seems some areas have done it very effectively with successful rapid response displays etc. Can we do it on a larger scale?

Lynda Kelly - 4.04 PM, 20 April 2011

Here's also a really useful post Planning an iPhone app - where to start.

Report misuse