Labs are transformative by nature. This chapter discusses how Labs bring about change, both on an institutional level and within services. It includes information on how tools are developed and a case study on how a bespoke tool was moved to an operational service.

Labs championing change

Generally speaking, most Labs are born out of the need to transform an aspect of, or introduce a new element to, an existing GLAM institution. If this is the case, embracing an innovation mindset in the Lab's vision and values is pertinent. To do this, setting conditions for experimentation, failure and risk-taking, are key.

There is no one-size-fits-all approach to how organisational transformation proceeds or how success is measured. Some Labs are focused on organisational transformation and others on service and product innovation. Both forms of transformation are equally valid and will be determined at the vision, values and getting started stages of setting up a Lab.

Organisational change

For Labs focused on organisational innovation, the main aims are embedding new practice, skills and mindsets into the organisation. These Labs may, by design, have a shelf life. Transformation can be measured by the shift of Lab activities and practices to business as usual.

Cultural transformation

Labs are small and agile units and experimental by nature. Their parent organisations are much larger, provide broad services, and commit to a long-term perspective. This naturally positions institutions as conservative and risk-averse. To roll out institution-wide experiments, Labs need to build internal trust and support by acknowledging the experience of other teams, staff members and managers and share credit. This is an effective strategy to win the needed trust and support in an organisation. The Lab-style way of working promotes collaboration, knowledge sharing and draws staff out of isolation.

The growth of Labs addressing cultural transformation of an organisation can be seen as a response to current challenges, as institutions are under pressure to reimagine themselves and redefine the ways they create value for their communities. Labs often ask and answer questions about the internal issues they face — how they operate, structure and organise, how and for whom they deliver programmes, how they create exhibitions and online services, and more broadly how they engage their users and visitors.

The concentration of digital expertise and mindsets in a Lab, setting the conditions for working and failing quickly, embracing risk, engaging with online audiences, and sharing of skills, knowledge and expertise are hallmarks of a Lab working towards digital transformation.

Product innovation

A main aim of a Lab could be to transform service delivery models, develop products and thereby ensure constant iteration and evaluation of new technologies before embedding them into existing teams, processes and services. In these Labs, teams continually scan technological, cultural and social horizons, learn from and work with communities of practice, staff and users.

Service transformation

In all areas of innovation and transformation, it is important to remember that technical change is easier to achieve than social and organisational change. Labs that focus on the development of new products and services can be seen as initiators of a specific type of digital and cultural transformation that is consumer-orientated. Libraries, in particular in the GLAM sector, are quite advanced in transforming their digital service delivery models through established and embedded Labs. Digital collections, collections as data, experimentation with new tools and products, working with users to understand their needs, and inter-disciplinary approaches that draw together technologists, curators, collections specialists, creators and researchers are hallmarks of a Lab focused on service transformation.

The Lab Process

Experimentation and innovation occurs in a setting where there is room for exploration and risk-taking, and a mandate to improve the status quo. This starts the transformation and the Lab process grounds it. By taking in ideas, services, questions and contributions, through an iterative process of development, experimentation, collaboration and finally innovation, the Lab produces improvements in tools, data, methods and skills and finally, Change.

From prototype to practice

The primary aim of Labs is to enable innovation to happen, using technology which may often require the development of new tools and alteration of existing ones. When successful, these tools go from Lab prototypes to embedded organisational tools. This process is never linear, and many aspects have to be taken into consideration when shifting from prototype to practice. Approaching this in a structural manner can result in successful outputs for institutions. Several Labs have been successful in the implementation of Lab projects in the organisation which have later contributed to the development of services, such as the LOOM Project of the DX Lab and the KB Labs case study at the end of this chapter.

Example: LOOM Project, DX Lab
LOOM was the DX Lab's first collections experiment, creating serendipitous discovery of collections online. Conceived as a small single-stage project, through the design process and subsequent iterative development it grew into a three-staged approach to delivering multiple ways of discovering this digital collection. The project was successfully received by users, and the impact strategically demonstrated to the institution; its findings have influenced the State Library of New South Wales's Collection Experience Programme. DX Lab LOOM project

Developing tools

Working with and developing tools in a structured way expedites easy integration. Since there is no one-size-fits-all for Labs, best practices around the preparation, creation and sustenance of tools can be helpful in determining the Lab's approach. Working with existing standards provides fertile ground for rapid and productive software development and enables others to build upon Labs' work.

Preparing tools

Software development can become very personal, very quickly. Working in a team, or even with related colleagues or teams, requires a shared code of conduct for how to work together. Being honest, but kind, when collaborating ensures that expectations of interactions and modes of working are aligned. Furthermore, providing a clear framework for communication and methods of working, as well as shared goals, clears the way for successful collaboration. An example of this is the principle of shared code ownership: agreeing to this early on fosters tighter collaboration and ensures there are no disputes further down the line. Software licensing is part of the preparation stage. Choose a licence which is as open as possible but still meets the demands of your institution. Helpful tools are available for this, such as Choose a licence.

Existing skill sets and knowledge within a team inform the choice of a programming environment. However, for teams with a range of skills, certain software libraries are strongly related to the type of analysis needed. For example, there are a large number of Natural Language Processing (NLP) tools available in programming languages such as Python and Java, and computer vision is well-rooted in C++.

Creating tools

Writing documentation during the modelling process is important in the Labs environment: documentation should be part of the creation process as this provides transparency and context. Related to this is test-driven development, enabling bolder changes.

As with all software development, using an issue tracker is a helpful way to provide an overview of work and to triage development. Source code management is a system to track changes in the code base, and which allows collaboration — enabling multiple people to work on the same code base at the same time. This enables Labs work because:

Contributing to open source software requires use of source code management to make it possible for others to contribute to the code and help foster collaboration.
Tracking enables more radical changes to be made to code: there is less concern about the fragility of work, as it can always be rolled back.

Currently, Git is the industry standard for source code management, making it easy to branch out and experiment with code.

Continuous Integration / Continuous Deployment (CICD) means having a tool chain which automatically builds your product from your code and deploys it. This enables fast turnaround of features, as well as experimentation. It supports the ability to evaluate changes with users and an iterative approach to problem-solving.

Rapid prototyping / Minimum Viable Product (MVP) is central to the idea of experimentation and enables understanding of whether code works. It also allows work or projects to fail quickly, leading to the ability to move on, and therefore progress more rapidly. In an experimental environment, it isn't always clear where the project is heading; even a basic prototype is better than unordered thoughts, enabling iteration, development and improvement to continue. Rapid prototyping also helps to narrow down choices of programming language.

Sustaining tools

Sustainability is where everything falls into place. Choices of licence, source control management and shared code ownership have a big impact on the sustainability of your tools: planning for sustainability throughout tool creation is important. When developing new software, a Software Sustainability Plan could be used to design the output and built-in sustainable options. A good example of such a plan is the NL eScience Center Software Sustainability Protocol.

Publishing code for preservation and sharing should ideally be done on an open and sustained platform. Code published on Github, for example, can also be preserved in Zenodo, thus automatically adding a DOI to the code, again contributing to the sustainable nature of the software. The following flow chart suggests a method for evaluating tool sustainability.

Decommissioning tools

The tools that you are offering might be outdated at some point or might end up having just a few users. It is therefore recommended to re-assess the tools on an annual basis in order to either update or stop them. Communicate that development has stopped on a tool so others are able to continue development.

This checklist provides tips on what to think about when decommissioning a tool:

What type of tool needs to be stopped?
Are we required to keep this tool live? (This might be the case, for instance, when working with an external funder.)
Can / should the tool be absorbed into the parent organisation?
Who is involved in the development of this tool?
Who uses the tool?
Are there external links to this tool that need to be considered?
How should the tool be preserved?
What documentation is needed?
Who needs to know the development of this tool will be stopped?

Case study: From bespoke tool to service: Royal Danish Library's SMURF

A few years back, members of the IT Department at the Royal Danish Library participated in a workshop at Aarhus University. The subject was Digital Humanities. At the workshop, various tools and methods were demonstrated. The tools showed how researchers worked with statistics and datasets. One of the tools was an n-gram viewer. Since IT departments have a great knowledge of the collections and have strong competences in the development of frontend and backend systems, those who participated in the workshop decided to do a proof of concept of an n-gram viewer on the newspaper collection, and shortly after SMURF was created. The n-gram viewer was then demonstrated to selected university researchers who found the tool highly relevant and useful. The tool is applicable to teaching, but also to a more explorative approach to the study of subjects. At this point, the solution was still internal.

In order to make the tool available to students, subsequent collaboration was initiated with a legal advisor to clarify which data could be used from the collection. The process was long, but the dialogues and collaborative investigation of how to show data to the public was needed, and in the end was also fruitful, with SMURF being released in 2016. SMURF is now being used at several universities in Denmark, where SMURF graphs appear in teaching material and are integrated in different courses at the universities.

Because of the high usage of the tool, the IT Department is currently working on moving the tool out of the Lab.

Key points

Transformation:

Is at the heart of the Lab process.
Enables Labs to champion organisational, cultural and service change.
Promotes prototyping as a pathway to practice.
Enables both sustainability and decommissioning of tools.