We are now into the final few months of the SPRUCE Project and we're beginning to complete some key outputs from the project. A key aim has been to encourage and support digital preservation activity in the UK from both a technical and business perspective. So we wanted to support practitioners in bringing in the funding they need to make preservation happen. To that end, we've produced a toolkit that guides them through the process of writing a business case focused on digital preservation:

 

 

Rather than taking the usual report writing approach to creating this resource, we thought we'd follow some of the agile principles we'd been championing on SPRUCE and run a "book sprint". This approach was originally suggested by Neil Grindley, the man holding the funding reigns for SPRUCE at Jisc. This was quite an exciting proposition, but also a worrying one. We now know a thing or two about running a mashup, but we'd not applied this approach to writing a whole lot of text. However, with backing from Neil we felt a bit more confident about trying out an experimental approach, and in retrospect I'm really glad we did.

 

We invited along the project team, as well as a few volunteers who we thought would make a good contribution, and locked ourselves away in a room for 3 days with the aim of writing as much of the toolkit as possible. I faciliated the event along with Bo Middleton from the University of Leeds and SPRUCE.

 

Starting with only a very high level plan and quite a bit of uncertainty about what the finished toolkit should look like, we began with some brainstorming to come up with the chapter titles. Each group brainstorm resulted in some very different approaches and after we'd failed to draw them together (which worried me quite a lot on the first day) we realised that this could in fact be very useful. So the resulting toolkit tackles the business case challenge from 3 main perspectives. Firstly, a step by step guide on the process of putting together a business case. Then an in depth guide to writing the main content of a business case, structured in the form of a generic business case template. And thirdly, a set of questions in the form of a kind of an FAQ that would help users address sticking points in the process or work through tough issues.

 

We then began to fill out how each of our chapter headings would look. We started with high level bullet points, created by small teams who would focus on a section for a short amount of time. We'd then do a switch around and get the groups to review each others work. Crucial sections had reviews completed by all of our 13 sprinters, ensuring that the really important parts of the guide had some really thorough input from all of our experts. By this stage I was feeling much happier about where the sprint was heading and the content that the sprinters were churning out was starting to look very good.

 

A third stage took us into the process of expanding the initial bullet points into more detail. A this point a useful format for the pages that make up the business case template section emerged, and we began to replicate this across other sections and pull our somewhat randomly shaped ideas into something more coherent.

 

During the initial stages of the event we ran quite structured sessions, but at this point we decided to go free form, and allow the sprinters to work more or less on whatever they wanted to. This middle phase of the event injected a slightly different dynamic and allowed the sprinters to get their teeth into areas that they had particular interest or expertise in. Some steer was still required from us faciliators, particularly in ensuring that some of the more mentally taxing sections were covered. Costing was not the most popular chapter to say the least! We also had to try and avoid editing clashes, as we were writing straight into the DPC's new mediawiki.

 

As we moved into the final day we used an evolving checklist on a flipchart to ensure we had all the main tasks covered. We now went back into a slightly more structured format, and allocated tasks as sprinters became free.

 

A challenge we hadn't encountered while running our mashup events, at least in quite the same way, was participant fatigue. Our mashups have an almost narrative-like structure. With an event progressing reasonably fluidly throughout the 3 days, we work the mashers hard and they get tired, but there hasn't been a need to keep them motivated (bless em!). With the book sprint, it was a little different. Hacking out words rather than code is quite different. Writers aren't always used to tapping the keyboard into the small hours, with only the briefest (if frequent) thoughts of pizza and/or caffeine. Speaking personally, sometimes I can sit down at a keyboard and churn out a blog post or report. Other times I can't get past the first sentence. On top of changing "writing moods" we were also tackling some tricky business case problems. Real "think til your head hurts" kind of problems….

 

Everyone at the sprint had times when they were flagging. I hit my own wall of mental inertia in the last hour of the second day. I was driving a keyboard for a group of 3 sprinters when I realised I was about 5 minutes behind anything my fellow writers said. It was time to pass on the keyboard. And that was probably the most vital book sprint principle we employed. Running out of steam? Change the pace, work on a different section, change the groups, shake things up. Did I mention coffee? If only I wasn't intolerant to caffeine…

 

On the morning of the final day the group as a whole was still doing fabulous work but the tiredness was setting in. We'd been joking the evening before (in our "rest and recouperation session" in the pub) about a new digital preservation training tool we should put together. Our sprinter, Rachel MacGregor from the Library of Birmingham, had come up with the idea of top trumps for digital preservation (if you didn't live in the UK in the 1970s, its a sort of themed card game!). In the more sober light of the sprint room the next day, everyone was still loving the idea. So we spent a bit of time coming up with some ideas for it, and beginning to draft out how it might look. We didn't finish it, and it's not really a formal output from the project, but as a way of energising everyone before getting back to some serious book sprinting it worked perfectly.

 

Another aspect that helped to encourage the writers was the involvement of a former mashup attendee and now an illustrator, Tom Woolley from Curve. Tom joined us for the first two days of the event and spent his time sketching out some beautiful illustrations that would help to visualise some of the concepts in the toolkit and enliven what would otherwise be some pretty dry looking pages of text. Everyone interacted with Tom as he sketched away, and when we started to receive the first of his colourised and completed images on the final day of the sprint, there was again a buzz about what we were creating. Getting some brightly coloured images in there might be looked upon as a bit of a cynical marketing tool, and maybe it just is! Digital preservation is not always the most lively or visual of topics, so the illustrations do seem to help to make an impact. Like our Danish colleagues who released their wonderful DP illustrations for wider re-use, we've also put Tom's images out there under a CC license, and I hope others in the community will be able to make use of them.

Over the last hour or two of the sprint I was focused on reviewing as many of the pages we'd created as possible, looking for gaps and picking up on jobs we still had to do. I was again struck by just how good the content was. 13 minds were definitely a lot better than one. After the sprint had finished I would spend another week back in the office doing some thorough editing, removing inconsistent formatting, plugging gaps and adjusting some of the language. But this would mainly be a polish job not a rewrite. This said a lot about the hard work of our sprinters during the event.

 

Despite all being rather tired at the end of the 3 days I was quite surprised to see how excited everyone was about what we'd created and (I think most strikingly) about the process we used to get there. We spent the last 40 minutes of the event chatting about how the 3 days had gone, what we could learn from the experience for next time, and where we should go next. There were lots of positive comments from the group about the book sprint process, summed up nicely by William Kilbride of the DPC when he contrasted how things would have gone had we not taken the book sprint route. Suffice to say, the end result would have been of significantly lower quality, and we wouldn't have had the buy in and ownership of the entire team in the way that the book sprint naturally ensured we did.

 

So the book sprint experience was quite a fascinating one. We didn't actually write a book. And we certainly didn't do any sprinting (perhaps the odd swift walk to the pub after a long day of writing). But the end result has already had ten times more impact on twitter than any of our other SPRUCE work, with 10000 hits on the wiki. I'm hoping the toolkit will have a significant impact and make it easier for our digital preservationists to get at least some of the cash they need to make their preservation work happen.

 

Thanks to all the sprinters and everyone who contributed to the toolkit!