An interview with, Lucerne Central and University Library (Lucerne ZHB)
When and how did you discover agile working for yourself and in the library context?
That was back in 2017 during my OPL (One Person Library) job in the special legal library of a large corporate law firm. The management tried to introduce agile methods “top down”, which meant that I came into contact with them during workshops. I was so impressed that I integrated agile values and methods into my own modest library work.
For example, I visualised all ongoing tasks/projects in my small library using post-its on an improvised Kanban board in the centre of the hallway at the law firm. This led to colleagues viewing my job in a more positive light (“Oh, you take care of this too?”) and often to colleagues drawing the attention of the partner responsible for me to the fact that I needed something from her:him , because I had pinned a note next to her:his name with “Waiting for …” on the board. In the end, I was even allowed to support entire legal teams in implementing agile working and became a kind of “agile coach”, without realising at that time that this job actually exists.
Later, as head of library IT at the ZHB Lucerne, I was able to use agile working throughout an entire team in order to implement IT projects – starting from more complex software updates to system migration projects, through to pilot projects to test entirely new (library) technologies. For a year now, I have been library director – a completely new challenge for me to live agile methods, roles and values in the entire, cross-team and cross-departmental organisation of a library from this position.
Why is agile working useful for modern libraries?
Libraries are not so fundamentally different from other institutions or companies in an agile context. A library is just as interested in “external agility” (PDF, German) as Google or Tesla – it wants to be as successful as possible for as long as possible. You can see this by using measurable outputs such as high number of loans, a large amount of search requests and e-media hits, numerous entrances to the building, excellent occupancy of the study stations, many new registrations, a high number and quality of events including those with lots of participants, a positive media presence, high satisfaction of the users and sponsoring organisations, growing budgets, etc.
This means that libraries need to be innovative, to adapt swiftly to changing contexts and challenges and to always offer those products and services that are in particular demand from their users and partner organisations. This is precisely where agile values and methods can help and promote so-called “inner agility” (PDF, German) by improving internal communication and cooperation through more transparency, a positive error culture as well as flat hierarchies, flexible roles and self-organisation, and by continuously integrating user feedback into the work process.
On the other hand: in many places, the structures which have developed in libraries over a very long period of time often seem to be somewhat rigid and cumbersome. How can agile working function here in spite of this?
By trying it out on a small scale initially. Projects for introducing new services, offers or products are particularly useful in this regard, and ideally those which the library colleagues themselves do not know exactly how to implement in the first place because, for example, the starting situation, the approach and/or the expectations and needs of the users are still unclear.
Furthermore, this working method can be launched particularly successfully if all colleagues involved are integrated and are allowed to contribute to the decision-making process when it comes to implementing agile methods, rituals and principles. Last but not least, you need to obtain the agreement of the manager who has been responsible for the line organisation of the project up to now: agile working can only succeed if this person is prepared to share its knowledge, expertise and responsibilities with the entire project team.
After the initial, hopefully successful and inspiring agile projects (although non-implemented pilot projects can also be regarded as successful ) this working method can also be fundamentally and permanently established in individual teams, for example by meeting all of the team’s annual targets in an agile manner; by having regular, agile discussion formats that characterise communication in the team; and by implementing retrospectives that allow all colleagues to evaluate and adapt the collaboration within the team.
Several agile teams can be combined into larger agile organisational units at a later stage. Here in Lucerne at the ZHB for example, we have merged all departments from the fields of e-media, IT and Open Access / research and publication support into “Digital Services”. At the TIB Hannover there is an interdisciplinary team that takes care of the agile further development of the AV portal. We are also enviously eyeing the Zurich´s Central Library (ZB Zürich), where the organisational unit “IDE” (information expertise, digital services and development) agilely develops service offerings in the user area (German).
To what extent does the Lucerne Central and University Library actually work in an agile way? Do you have a few examples?
We are still quite a long way off claiming that the entire ZHB Luzern works in an agile way. But in recent years we have been able to gather a great deal of experience with agile projects, for example when we tested, adapted and later introduced our Seat Navigator across all locations (German). This precisely measures how many of our study stations are occupied down to each individual seat.
The example of the Seat Navigator
The starting position was that our location at the uni/PH building was in high demand, particularly during examination periods. Students were practically fighting over the available seats in the library and had developed creative reservation techniques (German).
We weren’t able to offer more places just like that, but we had the idea of using IoT sensors at each seat to measure exactly whether it was occupied or free.. We are able to make the total number of available study stations at all locations visible online, and if the occupancy is too high at one location, to spread it more evenly. In this way, users should be able to quickly find a free place in the building and also decide at home to go to the library location that currently has the most free places.
If we hadn’t approached this pilot project using the agile method (= quickly testing a small-scale prototype to get targeted feedback from users and taking adjustments into account whilst still in the project phase), we wouldn’t have been able to find out as quickly that the system can only function with a break mode which, as well as showing free (green) and occupied (red) seats also shows those that have been left temporarily for a break (yellow). It was only following this feedback and the respective adjustment that we were able to lay the foundation required to operate the system at all four ZHB locations with over 700 sensors.
The example of the Lucebro AI Software
We also selected a similar agile approach when testing our “Lucebro” AI software (German), with which we wanted to (partly) automate recurring questions & answers in the daily communication with our users. Alongside pilot tests, continually gathering feedback and relevant adjustments to the software, in this case it was predominantly the complete transparency of all project steps as well as the involvement of all employees in the implementation which provided a good example of agility. Despite the tricky issue of automated advice, in the end 75% of all employees actively helped in training the AI software to handle frequently asked questions & answers from the information service. Even if the project was not ultimately implemented in a productive manner, owing to a poor cost-benefit ratio, it was a complete success in terms of in-house collaboration and experiences gained in comparison to classic project management.
The example of the “Luzi” Pepper Robot
The deployment of our Pepper robot (German) also demonstrates how even failed projects can be seen as successful in the context of positive (= agile) error culture. Instead of investing a great deal of time and money in AI software and developing this, at best, without considering the needs of our users, we have learned that these kinds of solutions need to be as low-threshold as possible, in order to be accepted by library users.
This means that the training data from the Lucebro project are now being used to teach our Pepper robot “Luzi” the most frequently asked questions & answers about the library. It is then very easy to speak to Luzi directly and personally on site, and she patiently explains all day long how to access the Wifi or how you register for the first time. Naturally we are also continually asking our users for feedback in this regard, as to how Luzi could help them further, and we are developing her continually.
You were responsible for the introduction of the swisscovery library platform throughout Switzerland. Is it right that you used agile methods to develop and improve the platform? Which ones exactly? Were you successful?
Well, it was certainly not due to me alone: swisscovery was launched as a joint network of 475 libraries and a national research platform in December 2020 (German), and this required many years of dedication and enthusiasm from over 2000 library colleagues from all over the country. I was only actively involved in the introductory project for the ZHB Luzern as group coordinator for the integration of our network of Central Switzerland (higher education institution) libraries into swisscovery.
However, things only really became agile after the launch, when our national research platform came under criticism (German). The senior management of the Swiss Library Service Platform (SLSP), which operates swisscovery for the libraries, reacted to this by switching the further development of swisscovery to agile working methods, which had been planned anyway, in order to respond more quickly to the most pressing criticisms of our library users.
Ever since, I have been able to incorporate the perspective of the 15 shareholder libraries behind SLSP AG to the agile project team made up of SLSP and library colleagues (PDF, German) and work on specific improvements to the search interface.
We rely on Scrum as a framework and jointly maintain a backlog with all adaptation requests that we generate from interviews with users, from support tickets in SLSP and from direct feedback on Twitter. We pool adaptation requests according to topic and priority into month-long sprints, during which we develop solutions together, before updating them directly in the national overview of swisscovery. After every sprint we review the adaptations achieved and plan the next sprint. Compared to the previous frequency, the agile procedure is a complete success. In six months we were able to fix the most urgent problems, decisively improve the user friendliness of swisscovery and even enjoy a little praise now and then.
Your favourite tools or methods for agile working?
I am a big fan of Kanban because it allows you try things out rapidly, and uses fewer strict rules, rituals and time limits compared with Scrum. On a Kanban board, the pending to-dos for a team or a project can be easily made transparent for all who are interested. With this important foundation in place, it is possible to try out further agile principles such as daily/weekly stand-ups and a step-by-step transition towards self-organisation of the team. If virtual Kanban boards such as Trello, MeisterTask or Stackfield are used, everything can be achieved regardless of time and location, which became an important element over the past two years of the pandemic.
Scrum, on the other hand, has the advantage that it contains a complete framework and not just one method and, in addition to the rituals and practices, raises awareness of the fact agile working must be underpinned by fundamental values and a cultural change; without this, no tool, no matter how exciting, would bring any positive effect at all to the collaboration.