• Blog home

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
© 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 steve.museum, 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.