We’re trying Agile in our museums so you don’t have to
(but you should)
When I get things done it always feels like an accident.
Out of the chaos of spinning plates, fire-fighting and meandering meetings somehow comes new galleries, new products, new blogs and me not getting fired. My work feels reactive and unorganised, and I rarely have time to reflect and plan.
I’m not a complete barbarian, though— I have a filing system, I date my documents in YYMMDD and exercise version control, I make optimistic to-do lists and, by god, I put things in my Outlook calendar.
But I’m fallible. To-do lists stack up and disappear under coffee mug stains. Actions are given at meetings, promises are given, and yet people get distracted and not much gets done.
So when I heard about ‘Agile’ at the AMA Digital Marketing Day last December, I sat up. Here was a way of tracking projects, communicating work more effectively and building in time to reflect on how we get things done.
Unfortunately Agile also involves a lot of jargon and buzzwords, befitting something which began as a way of managing software development. If you google it, you will find a lot of circular diagrams:
Essentially, Agile means working incrementally in ‘sprints’ and continuously reviewing your work. Working in an agile way means embracing the fact that plans don’t work out, projects are complicated and we need to know how to respond to change.
The problem with explaining Agile is that it always makes me feel like I’m selling a pyramid scheme. It has its own vocabulary, different ways of doing it and, from the outside, can look like a mess of post-it notes.
Admittedly, this is how it first looked to me. But at the AMA Digital Marketing Day we saw how Sara Devine from Brooklyn Museum had used Agile in her team to prototype and build their ASK app. She explored how they used Agile not just for software development, but also concept development and project workflow.
Belinda Waldock, an Agile Business Coach, then showed us how she had applied agile methods to businesses and how it can be adapted to any institution. To put that to the test, we invited her down to Reading to see if Agile would work for Reading Museum and the Museum of English Rural Life.
Her resulting presentation to all staff certainly hit a nerve, and those of us who attended the following workshop learnt more about how we could use the power of post-its to run our projects. We decided to trial what we learnt over the next month and see whether it would work for our museums.
We started using Agile in these ways:
Personal Boards
We each have our own personal agile boards, which look like this:
It’s essentially a more sophisticated To Do list.
If there is something to do, it’s on a Post-it. Tasks begin their life in Future Work, tasks to do this month are in To Do, things in the current weekly sprint are in Doing, and when they’re done they’re put in Done. When we’re waiting for someone else to do something, we put a task in Waiting, and if someone asks us to do something we didn’t expect (which is often), we put it into Inbox until we can decide if we have the capacity for it.
Boards don’t have to be physical either. Because I’m rarely in one office, I use Asana as my personal digital board:
Project Boards
Our Project Board operates on the same principles as personal boards, and the one below collects our broad tasks for the #digiRDG project.
Each of us has our own post-it colour and every week we review the board, add things, move things around and review what’s in our Inbox.
Getting together to do this is called a ‘scrum’, in Agile speak. We used to sit down and talk through our plans for the week, but our scrums are far more effective.
Since we began using the board, however, we realised that it worked great for communication and keeping track of work, but we weren’t doing much reflection. In future we’re going to start reviewing everything we put in the Done box at the end of each month and discuss what went well and what didn’t. One way of doing this is by drawing a boat (bear with me), identifying our destination/goal, and then writing down what we see as our anchors and what is the wind in our sails (i.e. what is holding us back and what is helping us). We then write Actions to resolve problems and boost what’s helping us.
We also make boards for specific, short-term projects, such as our upcoming Digital Takeover Late event:
Planning and setting up an event is always stressful, but this approach worked really well for us. When a project is so full of bitty things to do it helps to make sense of the madness, and the gradual filling up of our Done box is really satisfying.
Roadmapping(ish)
We also want to explore how we can use Agile to improve communication across an institution, so at Reading Museum we made a calendar which people could map out their year on.
It was intended as a way of showing what everyone was doing, opening up opportunities for colleagues to help each other but also to show when and why people were busy. The idea was that we’d review the calendar at the team’s monthly meetings, but the resulting board is too large and unwieldy (evidence below). We’re trying to find a more streamlined solution, and may move most of these tasks onto individual project boards.
So what are we doing next?
The way we’re currently using Agile is great for keeping track of what we’re all up to, ensuring nothings gets left behind and identifying bottlenecks and issues. What we haven’t done much of is using Agile as a tool for reviewing our efficiency in a specific task or project, but it is something we’re exploring next.
At Reading Museum we have an Agile working group which is exploring how we can use agile methods best in our work. At the MERL we’re going to seize the enthusiasm of colleagues who have expressed interest, and start setting up more workshops and training to see how we can be of best use.
However, I also hope that Agile is disseminated by example. It is not something that is immediately easy to pick up. It requires an investment of time and enthusiasm, but once it starts showing results for us (and it already has) we hope it will pique the interest of others. The end game is that our two museums work more effectively, waste less time and communicate better. We hope Agile helps us do that.
