Agile Development in Non-Agile Museum

 

“As agile website development product owners, we navigate between the development team and the museum bureaucracy in order to produce the best possible website for the audience to enjoy.” This is the scrum user story I and my colleagues at the Finnish National Gallery might write. During the development of the museum’s new website we have encountered issues arising from the clash of cultures and paradigms – and solved them. I present a selection of issues and their sometimes surprising solutions from our museum’s first ever agile development project.

Speaker

Taika Dahlbom
Web Producer
Finnish National Gallery

This presentation was filmed at the MuseumNext Digital Summit in Autumn 2019.

Taika Dahlbom: That’s what I’m going to talk about, agile development in non-agile museum. Let me first start by asking everyone here a few questions. Is your organisation bureaucratic and/or hierarchical? Hands up. Quite a few of you. Who here has gone agile or would like to go agile? Almost half of you. Who here has gone agile or is thinking about it, thinks it might be a bit of a challenge at your organisation? Right there with you. It was, and it has been, but it can be done, which is something I would like to talk to you more about.

First, I’m going to talk about, a little bit, on what we were trying to do with this agile development project, our first one at the museum. Our vision was to excite people about arts in the internet, where the Instagram lives. A bit of a tall order, and to do this successfully, we asked our audience what they wanted from our site. You know what they want? 91% of our general audience wants to see pretty pictures. Then there are the art lovers, and they would like to understand art and really get there, and connect with art and culture, and even each other.

So, in 2016, my colleagues decided that they would go there, but also by going with the audience’s needs first. The first thing to get this done was to convince the 130-year-old organisation and its three museums that agile would be the way to go there. I’m going to show you four of the three most important magic ingredients that were needed in order to make the agile happen in the first place. Then I’m going to go and show you the third magic ingredients that helped out while we were doing our first agile project.

Now, I mentioned audience needs, and this is something that is the first magic ingredient. You need to focus on the needs of the audience and not on the museum’s wishes and demands, sometimes where there were demands. This is something that the museum is already a little bit used to, because of service design thinking. So it’s not that far to begin with, but agile takes this a lot further. Because everything in the development phase is based on scrum stories and Instagram stories, the question, “Why do you need this particular thing is” is substituted with “Does the audience need it?” Oftentimes, the audience does not need it.

If the answer is, “Yes, the audience needs it,” you have to be able to articulate why the audience needs it. This is something our organisation struggled a bit at times, but it became the ultimate selling point of the whole agile thinking at our museum, because of money. This might come as a surprise to you, but a museum area, field, business, not made of money. If you do a new website, like we set out to do, it means project, and project means that money must be spent, which is unfortunate.

The old waterfall type of development process, where the museum first thinks what we want, and then it plans how to get there, then it executes those plans meticulously, and then it publishes the site, and the last bit, it wonders, “Why does the audience not, like, enjoy it? Like, why do they not come?” The agile process circumvents that by going towards audience needs first. That’s the idea, anyway. How do you get the money in the first place to do your agile thing? That’s going to be ingredient number three, because ingredient number two is figuring out in what particular ways, in your institution, the way of doing things differs from the agile way of doing things, and where the worst gaps lie.

Because your institution is not going to go fully agile just because you’re working on a website, it’s not going to happen. It’s going to stick to its ways, and the agile ways, there’s no sense in changing them to fit the organisation, because otherwise you’ll be just doing what you’ve always been doing before, and it doesn’t really work. So, first you need to think about the worst gaps between the museum way of doing things and the agile way of doing things. Take the idea of a project in the first place. At the museum, a project has a beginning, it has an end, and it ends with a finished products. Agile thinking is that programming never ends. It ends when it takes stuff online, that’s when development ends.

That’s a problem at the museum context, because of budgeting. The museum has an annual budget, at least ours does, but the agile people do budgeting by sprint. In our case, sprint is two weeks. There’s a year of budgeting to do, then there’s two weeks, and another two weeks, and another two weeks. That’s a bit of a gap there. This is where you sit or stand, or run or do your thing. You detect the gaps and you negotiate your way around them, so that these two different ways of doing things can co-exist and produce something lovely in a fruitful way.

How do you get the money to do all this? You find allies, preferably allies with money, but all allies count. If you have allies with money, the assumption is that they all obviously want to give you the money, because they like you and they think you’re on a good path, doing good things. The more allies you have is the better. The higher up in the organisation, always better. My colleagues at the museum, [inaudible 00:07:57], who are with me here today, and also would like to talk to you after the presentation about your solutions, they convinced our general director about the benefits of agile and the need for money.

It has worked wonders. Once you got the general director in, everybody else follows. A bit slowly sometimes, but they do follow. You need those allies too, you need them everywhere. How you get all the other people to come in, if they are not drawn in by the general director, you do a demonstration project. Before you do your actual agile project, you start with a small something that works in the agile way. My colleagues… I wasn’t even working at the museum at the time, I was still a journalist then… they devised a demonstration of the agile way.

They experimented with the museum people while doing this, because they had this idea that there should be some sort of a conceptualization project for this website. They organised workshops where people from our museum participated. It took six weeks, two months, and there they transformed the idea of the website they were having into a 130-page concept with visuals and functionalities, and everything. Because some people were participating in it, they could see that this worked, but then they went everywhere, the museums, and showed the 130-page concept, and people saw that, yes, this could work, we have done this.

Those were the four magic ingredients that brought this decisions potion about. There was the demonstration, there were the allies with the money, there was an understanding of how our ways and the agile ways are different, and what to do maybe sometimes when they are clashing. Of course, there was a strong understanding of what the audience needs. That was really important. This brought us into a dawn of a new agile era.

What about the daily work with agile? What were the magic ingredients there, and how we circumvented some of the problems that would arise between our people and the development people? The first magic ingredient is connection. You have to connect with everyone, preferably more people than you can handle. The agile people love to talk about breaking the silos. In museum context, breaking stuff, not a good choice of words. So in the museum, I talk about connecting.

It’s not only within our organisation that we’ve connected. We’ve connected there, but we’ve connected with developers. We connected with other people doing agile in Helsinki and elsewhere, because you never know where a really good insight or an idea, or a helpful pair of hands, is going to come from. So connecting is really, really important. We have about 300 people in our siloed organisation. With them, we have connected by having workshops. We have A/B-tested the layouts before there was anything else to show.

During development, there has been a biweekly demo where we have invited key people to come in. We would have invited more, but our working space is very small, but we invited everyone who can fit in. We have let, early on, people see and use and comment on the unfinished product, the website. Now, these are very normal things to do in agile development. They were not very normal things to do at our museum, but people have taken them in very well, and it has worked.

Also, we connected when we shopped for an agile development team. We knew we needed tech expertise, but ideas from them, but that was not enough because we needed to have a team whom we could trust and we could communicate with easily, and feel all-round comfortable around. That was one of the key metrics we had when choosing our team. We interviewed four teams that were offered to us by different tech companies, and asked them to do a benchmark demo. They sent us a couple of A4s with things they thought we would need, or we would like, at our website.

Then we had like an hour’s chat at our office with them. We found that some of the teams had the tech expertise, but it wasn’t comfortable being around them, or we weren’t speaking the same language, or there were problems. We found a team that we felt that they understood us, and that we understood them, and everyone was happy with the situation. It was a good match, and it has been a good match.

Then there is the way to connect to our colleagues, and a good way to support them with our special expertise when they are doing their digital projects. Currently, all our museums are thinking about doing new websites also. So we go there and try and offer help when they feel that they need some help, even if this project is going on. Creating opportunities for connection is also a way of connecting, so we have offered to go to different departments at our 300-people organisation, and tell them what’s going on all the time. They don’t necessarily take up on that offer, but it creates goodwill towards us. That’s why it also creates goodwill towards this agile development way of doing things. That has helped a lot.

Okay. Then there is understanding. There is general nervousness on doing things in a new way, and you have to understand that you are not only managing tech development, you’re also managing nerves, and you need to respect people’s feelings and listen actively. Like where do these feelings come from? We had one of those nervous episodes just before we started to develop the development room. I asked for advice on someone who had been doing agile for a long time at the university. He said, “Traffic lights.”

Traffic lights is a daily email I sent to all the key people. Then if it’s green traffic lights, everything is good. If it’s red, everything’s bad. If it’s yellow, then you add a few lines, like why there are maybe some concerns. We have never yet sent a red traffic light email, thank goodness. We might. We’re measuring progress, and we are measuring resources, and we’re measuring budget, so that’s a nervous-ey thing.

Then there is sharing. We share our workspace with the developers. They have come to our office. At the beginning of our project, we spent a lot of time there with them. Everyone of the four of us was there with everyone, the four or five of them, all the time, because they were asking a lot of questions, and we got the things started much easier and much faster because we were there to answer their questions.

Remember those gaps I mentioned before? Lots of them in project management, because in our museum, there is hierarchy, and distinct roles and boundaries. When you’re in the project teams, everybody does their thing. In agile, the teams are totally self-organising and everyone can do a bit of everything else, else’s thing. Our patch was here, that our team members have their special responsibilities, but we try and share so much info on the goings-on in the project that everyone could do a bit of everything. Everyone could try and answer a question that the developers had, but this needed boundaries. It’s, again, around money.

A post-it on a Kanban wall means that money will be spent. The project manager must be asked before sticking a post-it on a Kanban wall. It’s a simple solution, but it really, really worked to get our nervousness levels down. Then there was another gap that forms around changes to plan. Agile, they’re very reactionary, quick reactions to new plans, right? Our ways is to organise a meeting, chat a bit, make maybe some further inquiries, have another meeting. Quick solution to that was, just fill our calendars with meeting slots. We didn’t even know what we are meeting about at that time, but the occasion came, every time something happened.

The product owner… which is in agile like the project manager maybe, it should be one person decides on everything… is there present all the time. We could not do it that way, because our product owner was our boss and she had everything else on her plate. So we shared that product ownership in four-people museum teams, we’re there as a proxy PO. We had these meetings and we solved issues. We made decisions, had the actual developers work on that. Most of the time, it was quite okay to our actual product owner. So sharing is very vital to making it happen.

Then there’s the final ingredient, which is developing. Budgeting gaps. You just have to develop everything, the tech, obviously, the website, but also the way in which you organise, and the way in which you work, the way in which you interact with people, it’s all over development. I’m going to skip a bit to the end, because what we have done here is gel together the agile way and the museum way, with developing and understanding, and sharing and connecting. Now we’re going towards the phase where we’re going to be keeping all this together for as long as the agile development takes.

Our main ally, the general director, has found out that this is a very nice way, actually, to do things. So it’s going to be the strategic goal for the whole of our organisation for next year, to try and develop our working ways. If you want to see what we have actually done thus far, you can go to prod.fng.fi and dabble around a bit. We, all of our team, would really, really like to share and talk, and interact with you here today, and later on in emails, social things. Thank you very much.

Sarah: Thank you, Taika. Very interesting. We were at MuseumNext London. We also spoke about changing the museum or changing the future. Actually, it also starts with the people who work there. Very inspiring to hear you talk about the agile development. There was one question in Slido. If you could summarise for us, what is the basic principle of agile development? Can you just name a few bullet points on what it is?

Taika Dahlbom: Okay. Agile development, it wants to do software, but it can be adapted to also other things that are being developed. The point is to do only the necessary things to make a successful product. That’s the bottom line.

Sarah: Okay. Thank you very much. Then there was another question about how did you start? Did you have a scrum master and product owner? You spoke about the product owner, but maybe a scrum master, and have development sprints like every two weeks? How do you work in that?

Taika Dahlbom: I actually came to the museum like in January this year. They had gone all the way up to searching for a development team at that point. So I’m not quite familiar with the things they did originally, but it started with these people, you can ask my colleagues later on. It started from just figuring out how to make a successful website, and that’s where it started rolling.

Sarah: Great. All right. Thank you very much for your time and your presentation. Let’s hear it for Taika.