Last week we spent 5 days with digital agency Clear Left exploring how we might develop new self-service machine software for libraries.
Here are a few observations about how Clear Left and a sprint work. It was certainly very useful for me, and you might find it interesting if you do any design work with clients, or you work with external agencies to explore any digital area. If you work in library IT read on to find out about what the future of self-service might look like.
We’re replacing the self-service machines customers use to check out and return books in libraries. The machines were installed about 8 years ago (in this respect libraries are years ahead of supermarkets).
A lot has changed in the last 8 years – in 2008 there was no such thing as an iPad and the world wasn’t quite as connected to the internet as it is now.
Over the last few weeks, the IT team has been discussing what a new self-service system might look like. We want something a lot more portable, cheaper, device agnostic and easy to manage than the current system. All this led us to conclude that some sort of web app might be the best approach, rather than, say, a Windows client or an Android app.
As there aren’t any software-only providers out there, we’d need to build it ourselves (or rather, get someone to build it for us).
At this stage we felt we needed an expert opinion. Was this really the right approach? If so, what might a web app look like? What problems might we run into? How do we go about this project?
There’s a longterm business advantage in keeping our hardware, software, library management system (LMS) and software decoupled (a word we used a lot during the week), and in extricating ourselves from the cosy LMS/self-service provider world.
As you can imagine, I was pretty excited to get Jeremy and James Bates into the library for a weeklong sprint. I got a stack of A3 sheets ready for Monday morning.
Making it up as you go along (and visualising it)
Before the sprint we sent Clear Left our own research and thoughts on self-service, including a report from a staff workshop we’d run a couple of weeks beforehand. We’d agreed some basic outputs we wanted from the week; namely, a feasibility report and perhaps some sort of sketch of what a web app could look like.
I’d also arranged for several staff members and volunteers to turn up on the Monday morning. What we were going to do I wasn’t sure.
Before the staff workshop, James helped us visualise the sprint by putting a diagram up on the wall. At the start, days 1-5 were pretty empty. That would change over the week.
The workshop helped define our self-service ‘problem’ and gave us a rough plan:
You’ve probably heard terms like agile, lean and sprint before: this was, I guess, agile in action. It’s a good process as you react to whatever you discover, rather than try to squeeze your findings into a predefined structure. You don’t want to simply reinforce your initial ideas, however attached you are to them; instead, you’re looking to test them and throw them out if necessary.
And a sprint has a definite end product. It avoids projects getting bogged down.
I was surprised at just how much James and Jeremy involved the IT team – and staff as a whole – in the work. At one stage we had library information advisors and the finance manager sketching interfaces alongside Jermey Keith and James Bates:
James and Jeremy based their war room in our Lab (a mediumsized room on the top floor of Ipswich County Library). The door was always open and staff and stakeholders were encouraged to pop in whenever they liked to ask questions and get involved. In fact, a lot of the research and testing took place in the library itself; James and Jeremy were very visible throughout the week.
I think there are some very solid reasons for taking this approach. Firstly, it recognises that anybody can have a good idea when it comes to a service they work with and/or use. Secondly, it gets people behind the project; it becomes something they feel a part of.
A lot of it’s actually teaching
Teachers will recognise the skills you need to run a successful sprint. There’s the basic organisation, the ability to express and elicit ideas using different learning styles and the knowledge of how to pitch and time activities. There was even a starter/main/plenary structure to some of the work.
James did most the facilitation, using a mix of visual and verbal activities, often strictly timed. For example, we were asked to note down 8 ideas for self-service, which could be as practical or science fiction as we liked (I rather liked my book wayfinding idea – one for the future, perhaps). We then chose two of these to sketch and got the rest of the group to critique them.
The final stage involved assigning all the sketched ideas points based on how important we felt they were. This gave us the basis for our proposed product, which Clear Left suggest we divide into minimal viable product (MVP), phase 2 and backlog sections:
Bringing it all together
I can’t recommend this kind of research sprint enough. We got a report, detailed technical validation of an idea, mock ups and a plan for how to proceed, while getting staff and stakeholders involved in the project – all in the space of 5 days.