From contract to live in 3 months: A case study in keeping agile in an age of accelerating change.

by admin

If you think the world moves quickly now, don’t blink.  In a great TED talk a few years back, futurist and inventor Ray Kerzweil predicted:

“The paradigm shift rate, the rate of adopting new ideas is doubling every decade”.  

In the face of accelerating change, agile management practices have come to define the relevance of the systems that serve our communities.  In every sector, we see a growing gap between those who get “agile” – and those who are stuck to a more traditional model of extended planning and analysis cycles over the course of months (and sometimes years!).

There are many structural elements of public institutions like libraries that make “agile” doubly challenging. But we think our recent experience implementing a new discovery layer for the New York Public Library offers an encouraging case study:   yes, it is possible to move at the speed of light, even in Libraryland!

Or as a Dutch librarian recently tweeted in response to NYPL’s press release:

Zo'n project kan dus ook snel?!

(Which I’m told translates roughly as “So a project like this can be done quickly!”
di2lib himself tweeted his interpretation: “relatively fast considering timelines for dutch approach. Easy joke”…)

Here’s how things unfolded:

  • NYPL unearthed BiblioCommons in January; by month-end we’d presented to the library’s management team.
  • By March, a contract was in place for our core services, and for a variety of add-on modules currently under development.
  • By April, a validation site was live for the NYPL team to begin testing, complete with custom branding, custom navigation, and custom bibliographic mapping and circulation rules
  • Through May: the NYPL team validated mappings, configurations and ticketed away.   Back in Toronto, the BiblioCommons team focused on optimizing performance for the largest collection in the U.S., and on rolling out a slew of feature enhancements: the re-design of site messaging; critical availability display improvements (like for in-library use only; holds queue length); the re-design of serials holdings; the ability to self-select interest groups…
  • In early June we released to staff.
  • On Monday this week, June 20th, a preview of NYPL’s new BiblioCommons catalog was made publicly available to NYPL cardholders.  There’s a shiny new NYPL iPhone app available in the iTunes store as well (with Android and web browser versions to follow in July.)

Oh, and BTW, BiblioCommons did also launch 16 other libraries during these months – including CLEVnet, an 11 million+ item library), as well as major new functionality like a “microsites” module that various libraries like Santa Clara County have in beta this year, to tie their “Summer Reading” programs in seamlessly with the catalog and ILS log-in, and to allow for micro-site navigation that co-exists easily within the broader site.)

…and the NYPL team had a few other projects on the go itself. :)

Throughout these months, the NYPL and Biblio teams also worked through the terms of a unique investment (presented to and unanimously approved by the NYPL Board of Trustees) in BiblioCommons itself, over and above NYPL’s subscription agreement, to accelerate the development of features that NYPL deemed critical to its longer term strategy and that we agreed would be valuable to all participating libraries.   A huge win all round. 

So how do you go from contract to live in 3 months with a fully-featured “custom” catalog… ?

It’s a two part answer.

From NYPL’s side

Sure – they have a strategy office and resources that most public libraries only dream of.   But size is not the issue here – in fact, size can frequently be the enemy of agile.   From an outsider’s perspective, the most striking traits of agile were:

Organizational Culture:  There’s a clear bias to action that permeates all conversations – a sense that the costs of doing nothing far outweigh the cost of occasional mistakes, and an understanding that first releases are not forever; that iterative implementation is key.

Deadlines:  The week of June 20 was set by both back in February as our launch date, before we even had a contract, and rather than letting “ideal” requirements push deadlines, the deadlines drove what was possible.  These commitments were supported at the library by a driven and focused team at the library: sweating the details; collaborating closely.

Clear strategic direction: NYPL has been working toward a digital strategy for two years that puts community engagement with the collections at the centre.  We’re just one piece of that strategy – the platform that provides the scaffolding upon which to hang and connect many initiatives.  So there was consensus even at the most senior levels of the organization about general direction.  They knew what they wanted, but at the same time were great collaborators in making inevitable trade-offs as we went, and were open to new possibilities they might never have imagined.

Tight project management processes: The strategy team (led by the very talented Micah May) has implemented its own Kanban process (which, completely coincidentally, our dev team uses internally as well).   Importantly, clear authority was delegated to project members for designated areas of responsibility.  No committee decision making!

110622-Kanban board - NYPL
The Kanban board in the NYPL Strategy office

The key from our side?

None of the “custom” work is really custom. All BiblioCommons’ sites work off a single, shared code base that is easily and flexibly configured to account for varying practices in cataloguing, circulation rules / practices /policies, feature on/off preferences, content enhancement partners; labeling variations, etc

And even where we built new features or enhancements to accommodate new use cases that were critical for NYPL to accommodate the requirements of both the research and branch libraries, we built re-usability into each progressive phase of development as we always do – to ensure that the functionality would provide utility to all libraries.

Of course, it hasn’t always been this way for BiblioCommons.  Getting the architecture right to allow for this kind of nimbleness has been a multi-year adventure, that has largely paralleled the evolutionary stages described well in this post on the Maturity Model for SaaS.

Building for configurability takes longer the first time – but results in exponentially lower implementation costs with scale.  Ditto for an architecture that enables scaling-on-demand.  Many of our early libraries were the ones who endured the delays as we worked to get this right.  We’re grateful for their persistence.

Perhaps most fundamentally, from a user experience design perspective: we weren’t starting from scratch. BiblioCommons was building on a foundation of three years of iterative product design that has benefited from tens of thousands of pieces of feedback, and thousands of tickets by our early adopter libraries.

Huge thanks to our early adopter and new libraries alike for taking us here.   NYPL benefited from your contributions. Now you will benefit from theirs.

…and on we go.

Copyright © 2016 BiblioCommons