Agile in a museum?
What does it really mean to be agile at a museum? Do you risk shipping half-baked products if you adopt the principles of the lean startup? Can you ever be truly agile if you need to urgently address security issues midway through a sprint?
The trouble with the agile methodology is that everyone seems to interpret it slightly differently. Given the size and complexity of the V&A as an organisation, we have adopted some of the techniques from lean and agile, and discarded others.
In the end, it’s about figuring out what works to help you ship the best products. Below are seven things I can recommend and what we have learned along the way.
1. Get a ‘heartbeat’
We have found it very useful to build incrementally and commit to a short-term schedule. Our ‘agile heartbeat’ is a two-week period (sprint), which is made up of various ‘ceremonies’ that the tech team, stakeholders and the Museum commit to. On a base level, the tech team has daily stand-ups where we report on our progress, note our blockers (which are ideally resolved there and then), and the day starts.
The Website Steering Group (WSG) is a stakeholder committee here at the V&A to help us resolve blockers and prioritise. At WSG, and a related Website Delivery Group, our roadmap gets aligned and actioned with other departments’ roadmaps.
I’d definitely recommend a planning group or committee. It’s priceless to have a space dedicated to stakeholder alignment so that projects don’t incur unnecessary delays and misunderstandings.
V&A digital team’s ‘agile heartbeat’
2. Get prioritising
While building the new What’s On, despite having a clear business goal and set KPIs, some of the product scope and features needed to be amended as we went along. Why? Due to organisational challenges, siloed knowledge across departments, legal requirements and ticket pricing changes… the list goes on. Coming across such sizeable roadblocks can make building an MVP (minimum viable product) very challenging.
What’s the risk if you don’t accommodate for changes in the scope? You risk getting complaints from users, getting fined or bringing down online ticketing – our biggest online revenue machine. Can you afford to do that? You can – but only if you really don’t like your job.
With product scope changing and stakes being high, the best you can do in these situations is to re-prioritise sprint by sprint or delay the product timetable.
Sometimes, we need to accept that ‘change bombs’ are thrown into sprints too. Due to such occasions, we prefer not to commit to set launch dates.
Instead, we tend to plan short-term and use our business goals to navigate the long-term.
V&A’s digital backlog - organised around different projects
3. Get organising
Now that you’ve prioritised your workload and created your agile heartbeat, how do you break it down into tasks and keep track of it all? We’ve tried a number of tools including Trello, Jira, Confluence, Product Plan, Excel and Google Docs.
Here are our findings:
If you use more than one tool to communicate your work to the tech team and stakeholders, you are creating unnecessary admin workload for yourself (although there are plugins to connect them)
Jira is great for the tech team, but is clunky to use for stakeholder comms
Confluence is a great tool to create project spaces for documentation
Product Plan is the easiest tool to create visual roadmaps and an attractive way to share what we are doing sprint by sprint in our showcases
Excel seems to lend itself to very complex roadmaps (or maybe that’s just us)
Trello cards are an easy way to share what user stories the tech team are solving per sprint, but become tedious to keep updating.
Not everyone at the Museum has access to Google Docs, which often makes it impractical to edit.
ProductPlan lets you easily visualise your roadmap
After quite a lot of experimentation, we decided to discard all tools except for Jira and Confluence, not least because they are interconnected. After all, the key is to decide what you need the tools for and ensure you’re not duplicating your workload. For us, the essential tools are for:
Keeping track of our workload (Jira)
Keeping track of our decisions (Confluence)
Chatting, updates and GIFs (Slack)
Keeping track of the CRM team’s workload (Microsoft Teams)
4. Get sprinting
Part of our job in Digital Media is to resolve issues as they occur. If a high priority organisational problem is thrown into a sprint, we have to accept that our sprint plan will fall apart. The same goes for when tasks get blocked by another system. This can be frustrating for our tech team.
Why work in sprints if we can rarely achieve a sprint goal? Why not work in a day-to-day continuum? Despite the organisational challenges, we found there are huge advantages to working in sprints. Agile is good for:
Focusing everyone on one achievable goal.
Ring-fencing the team.
Giving each stakeholder their sprint/slice of a sprint.
Building a team.
Presenting a very clear view of what the tech team is really doing (not often the case as non-tech people don’t understand or engage with devs, and vice versa).
Producing something contained for the showcase at the end. Sprints can quickly achieve momentum because they go by relatively fast.
Looping in stakeholders quite quickly (‘Hey, will you present at our showcase tomorrow?’) and when it works, it’s a great tool for winning hearts and minds.
Working in a very considered way – it’s not just a mad race to a finish line as the name suggests.
And lastly, but perhaps most importantly….
You can’t do much damage in one sprint.
So when a ‘change bomb’ is thrown your way, and when things get blocked, just remember: it’s still a museum, not a startup. It’s a massive organisation. Sometimes things need to happen fast and other times, things need to wait. In the meantime, you can be confident that you are not making things worse off. Sprint on.
5. Get reflective
Does your process work? Is the team getting frustrated or demotivated? Are we worried about our back-end supplier? After our fortnightly showcase, the tech team gets together for a retrospective in the format of ‘what’s worked?’ and ‘what can we improve?’ via a pile of post-its and a bouquet of sharpies. As opposed to the showcase – where we share what we did – the retrospective focuses on how we work.
Though at times retros might feel like a ‘soft approach’ chore, they can be surprisingly action-packed. Good things have come from our retros, like using Fractal – a ‘lego block toolbox’ to help us build efficiently and consistently. It’s also an hour that brings me closest to the pulse of the team. Does anyone need an opportunity to vent frustration? Do we need to call things out? Are we celebrating what continues to work? In this format, frustrations can become practical and actionable.
Example of our retrospective
6) Get religious (kind of)
…about documentation. From a UX perspective, good software shouldn’t need documentation in order to be used (the app should intuitively teach you). However, product logic decisions and rules need to be documented. Why? The moments that slowed us down the most was when we found that years ago, a product decision had been made but not documented, and we needed to run countless tests to discover it retrospectively.
Using Jira for tracking our workflow and Confluence to create spaces for projects, we put a lot of effort towards documenting product logic decisions, storing and updating diagrams, explaining API architecture, as well as storing our functional specs, and notes from retrospectives.
The space is accessible to all our stakeholders and proves to be an effective way of keeping track of decisions, as well creating an open space to share feedback.
So when you’re building a product, remember: every sprint will produce a series of rules and decisions that need to be documented. At the end of the day, it’s all about thinking in a future-proof way – if we document this now, will we waste less time in the future? If the answer is yes, I’d recommend it.
7. Get over it
After spending so much time and energy on a product, how do you get on with other projects? A product is ready to go live not only when it passes through a UAT script, but also when support is in place, a handover is prepared and documentation understandable to the product owner. Are all stakeholders trained on our content management system? Will they know how to report issues? Is the event set-up process in place and can admins use it as expected?
Based on these questions, we organise various support or training sessions to ensure products land softly and smoothly once in the care of stakeholders. This means that the handover itself – attended by the product owner and stakeholders – can focus solely on the next post-launch steps, product maintenance and AOB.
It’s important to have a formal closure of projects with stakeholders involved. It makes product ownership known and your time after launch protected, which you’ll definitely need for your next product challenge.
So all in all, should you go lean and agile at your museum?
Since What’s On has launched, it has enjoyed a healthy and stable life, selling around six tickets a minute. We looked after it in our Digital Media nest for about two weeks after it was born. During this time our Learning Academy courses for 2017/18 also went live and within the first day we had sold 207 courses, with sales peaking at £20,000 in the first 3 hours.
Can you attribute this success to agile?
I have no idea, but it has certainly led us towards launching something that’s, well… not fragile.
This post was originally published on the V&A Blog in September 2017.