Im Anfang war der Wert: Wie Agilität Bibliotheken verändern kann

1.1 Exkurs: Das Missverständnis von der One-fits-all-Lösung

Eine Organisation mag mit Methode X oder Framework Y erfolgreich sein und daher zur Nachahmung inspirieren. Es kann verlockend sein, etwa das Spotify-Modell einzuführen – schließlich hat Spotify damit Erfolg.^[3] Nachahmung wird jedoch in den seltensten Fällen Erfolg bringen. Agilität bedeutet immer, auf die Bedürfnisse der eigenen Kund*innen, der eigenen Mitarbeitenden und der eigenen Organisation einzugehen. Um abschätzen zu können, wie dies gelingen kann bzw. welche Methode oder welches Framework der Lösungssuche einen passenden Rahmen gibt, beginnt alles mit der Analyse der Situation oder eines Problems. Je nachdem, ob und wie klar sich eine Kausalität zwischen Problem und Lösung abzeichnet, bieten sich verschiedene Methoden an.^[4] Die bekanntesten sind, neben klassischen Projektmanagement-Methoden wie Wasserfall oder V-Modell, agile Ansätze wie Kanban, Lean oder Scrum. Dabei wird hier bewusst nicht zwischen Prozess- und Projektmanagement unterschieden. Letztlich lässt sich als Leitsatz definieren: Je komplexer eine Situation oder ein Problem ausgestaltet ist, je größer die Unsicherheit und die Anzahl der Stakeholder ist, desto agiler muss die Lösungssuche sein. Denn je mehr Faktoren unklar oder unsicher sind, desto vager sind auch die Anforderungen an das Ziel und die ideale Lösung. Nur Analysieren und Experimentieren und aus diesen Ergebnissen zu lernen bringt einen Schritt für Schritt einer Lösung näher. Die Analyse der Situation als Ausgangspunkt zeigt zugleich, dass es keine einzelne Methode gibt, die alle Probleme innerhalb einer Organisation lösen wird. Auch in einer maximal agilen Organisation kann es daher Sinn ergeben, bei einfachen Aufgaben mit klassischen, nicht-agilen Methoden vorzugehen. Umgekehrt gilt jedoch, wenn eine Organisation kein agiles Mindset hat, beschneidet sie sich selbst in ihrer Vielfalt an Optionen bei der Lösungssuche.

1.2 Die agile Organisation

Sowohl Haltungen wie Prozesse müssen stets zwei Ebenen beinhalten: die der Organisation als Ganzes, als auch die des einzelnen Individuums. Erst wenn diese beiden Ebenen zusammenspielen und sich gegenseitig unterstützen, wird Agilität in einer Organisation zum Erfolg.

Bei der Transformation einer Organisation in eine agile und lernende Organisation dürfen Framework und Methoden nicht im Vordergrund stehen. Vielmehr geht es um die Kultur, um generelle Führungsprinzipien, die Definition von Aufgaben, Verantwortungen und Kompetenzen und die organisatorische Entscheidung, wie selbstorganisiert und entscheidungskräftig Teams und Personen betrachtet werden sollen. Und ganz besonders geht es auch um die Kund*innen! Während sich eine klassisch hierarchische Organisation vermutlich primär fragt, wie sie ihre Produkte an die Menschen bringen kann, fragt sich eine agile Organisation, wer ihre Kund*innen sind, was diese benötigen und wie die Organisation sie bei der Befriedigung dieser Bedürfnisse unterstützen kann. Konsequenterweise lässt man denn auch alle Produkte und Services fallen, die die Kund*innen weder brauchen noch interessieren: „Im Kern geht es also darum, den Kunden zu erfreuen und immer besser zu verstehen (= Lernen), was es dazu braucht. Und dann die eigene Organisation so aufzustellen, dass die Mitarbeitenden dies immer wieder erreichen.“^[5] Dieser Wandel darf nicht projektbasiert betrachtet werden. Agilität führt man nicht ein, indem man ein Transformationsprojekt aufsetzt und sich nach Erreichen von SMARTen Zielen auf die Schulter klopft (Fazit: Wir sind jetzt agil und können zum Tagesgeschäft zurückkehren). Vielmehr muss der agile Wandel im Sinne der Empirie als dauerhafte Aufgabe und das ständige Lernen als Teil der eigenen DNA betrachtet werden.^[6] Die eigenen Prozesse, Werte und Fortschritte werden transparent gemacht, regelmäßig überprüft und nach Bedarf kontinuierlich und zielgerichtet angepasst. Es versteht sich von selbst, dass eine solche Transformation anstrengend sein kann und Zugeständnisse von allen Seiten erfordert. Und letztlich muss man sich bewusst sein, dass eine solche Organisation auch nicht das ideale Arbeitsumfeld für alle Charaktere ist, weshalb eine gewisse Fluktuation zu erwarten ist.

1.3 Der agile Mensch

Menschen tun sich durchaus schwer mit Wandel. Hat man sich in einem Arbeitsumfeld eingerichtet, in dem die eigene Arbeit Tag für Tag sehr klar und die Prozesse einfach zu bedienen sind, ist das für das menschliche Gehirn sehr angenehm. Das bedeutet jedoch nicht, dass sich Menschen nicht engagieren oder etwas verändern wollen. Es muss nur klar werden, was der Nutzen dieser Veränderung sein wird.^[7]

Der Wandel beginnt also im Kopf, im eigenen Mindset. Als Führungsperson etwa, die ebenso ein agiles Mindset entwickeln muss, wendet man sich ab von der klassischen hierarchisch-autoritären Führung hin zu einem Verständnis von der Führungskraft als Coach. Vergleichbar ist diese Rolle durchaus mit der Funktion eines Coaches für ein Sportteam. Coach und Team haben ein gemeinsames Ziel, das sie verfolgen. Der Coach erarbeitet dafür Strategien, unterstützt die Teammitglieder bei der persönlichen Weiterentwicklung und der Entfaltung ihres Potenzials und entwickelt ein Gespür dafür, was das Team braucht, um erfolgreich zu sein. Währenddessen liefern die Spieler*innen ihre Leistung auf dem Feld und sorgen mit ihren individuellen Charakteren für eine ganz eigene Prägung der Strategie. Natürlich ist das stark vereinfacht ausgedrückt, findet sich aber durchaus in heutigen Führungstheorien wieder (vgl. etwa Modelle wie Servant Leadership bzw. Dienende Führung^[8] oder der lösungsfokussierte Coaching-Ansatz^[9]). Darüber hinausgehend könnte man sagen, dass die Aufgabe von Führung nicht mehr ist, Vorgaben zu machen, sondern den Rahmen für Selbstorganisation zu schaffen – und diese aktiv zu fördern.^[10]

Nimmt man die Empirie, also das Lernen aus Erfahrung und das Fällen von Entscheidungen auf Grundlage von Beobachtungen als Organisationsgrundsatz, wird von allen Beteiligten ein hohes Maß an Transparenz und Kommunikation gefordert. Denn nur durch diese sind Beobachtungen und ein gemeinsames Lernen möglich. Damit wird zwangsläufig auch Offenheit gefordert – gegenüber Veränderungen, neuen Lösungsansätzen und dem Mitteilen von Erkenntnissen und damit eine Abkehr vom Pflegen der persönlichen Wissensinsel (auch bekannt als Silo- oder Gärtchendenken).

Verbindet man diese Anforderungen – persönliche Weiterentwicklung und gemeinsames Lernen, Selbstorganisation, Transparenz, Kommunikation, Offenheit – zu einem Ganzen, kann das einzelne Menschen durchaus überfordern und der Weg zu einem solchen Mindset ist anspruchsvoll. Den Mut, den es braucht, diesen Weg zu beschreiten und unterwegs die wichtigen Misserfolge und Lerneffekte mitzunehmen, werden unter Umständen nicht alle aufbringen wollen. Wohl aber lohnt der Versuch, die einzelnen Menschen als Organisation zu begleiten und den nötigen Rahmen zu setzen, damit diese Entwicklung stattfinden kann. Schritt für Schritt. Zu beachten ist aber, dass es nicht „den agilen Wertekatalog“ gibt, an dem man sich orientieren kann.^[11] Während wir in dieser Publikation Werte wie Offenheit, Transparenz und Kommunikation auf Ebene der Gesamtorganisation besonders hervorheben, bringen agile Frameworks wie Scrum eigene Wertekataloge mit (Fokus, Offenheit, Respekt, Courage und Commitment).^[12] In den nachfolgenden beiden Kapiteln werfen wir daher aus verschiedenen Winkeln einen Blick auf eigene Beispiele von Agilität im Alltag – zuerst aus Sicht der Organisation, dann aus Sicht von Teams und Individuen.

2.1 Kanban-Boards für mehr Transparenz

Für das Sichtbarmachen von Prozessen eignet sich z. B. Kanban, da es im Vergleich zu anderen Frameworks mehr Freiheiten in der eigenen Gestaltung erlaubt.^[15] Ein Kanban-Board als ein wichtiger Baustein dieser Methode visualisiert dabei im Sinne einer gemeinsam geführten To-Do-Liste in einer Spalte („Backlog“) die anstehenden Aufgaben, z. B. in einem Projekt. Diese können nach Priorität oder inhaltlichen bzw. zeitlichen Abhängigkeiten gemeinsam von Führungsperson und Team definiert sowie sortiert werden. Darüber hinaus bieten Kanban-Boards i. d. R. beliebig erweiterbare Spalten, um zu veranschaulichen, wer an welchen Aufgaben derzeit arbeitet. Dies oft verbunden mit einem klar definierten Work in Progress (WIP) Limit, um zu erreichen, dass Teammitglieder sich nicht zwischen zu vielen Problemlösungen gleichzeitig verlieren. Zusätzliche Spalten können transparent machen, bei welchen Aufgaben noch auf Rückmeldungen, Zuarbeit oder Freigabe gewartet werden muss und welche bereits erledigt sind. Insbesondere diese Spalte kann dabei helfen, Engpässe in bestehenden Abläufen, Entscheidungsfindungen und Kompetenzverteilungen aufzudecken und zu deren Verbesserung einladen (Stichwort Lernende Organisation). Ein Kanban-Board lässt sich dabei mit einfachsten Mitteln wie z. B. Klebezetteln an einer freien Wand umsetzen.

Das Board sollte für alle Beteiligten stets sichtbar und leicht zugänglich sein und dient vor allem in regelmäßigen Treffen („Daily“ oder „Weekly“) des Teams als Gesprächsgrundlage: Was wurde erledigt? Woran wird gerade gearbeitet und wo gibt es allenfalls Probleme, Unterstützungsbedarf oder Verbesserungsmöglichkeiten? Gleichzeitig können auch interessierte, aber nicht direkt beteiligte Kolleg*innen einen Blick auf das Board werfen, um zu erfahren, wo ein Projekt derzeit steht.

In der konkreten Gestaltung gibt es viele Freiheiten. Auf einem Kanban-Board können z. B. mit unterschiedlichen Farben auch mehrere Projekte oder Arbeitsabläufe parallel visualisiert werden. Mit zusätzlichen Zeilen kann auch die Zusammenarbeit mehrerer Teams an ein und demselben Projekt veranschaulicht werden.

Abb. 2:

Kanban-Boards-Farben bzw. -Zeilen für mehrere Projekte / Teams.

Selbstverständlich gibt es auch virtuelle Kanban-Boards, die sich orts- und zeitunabhängig abrufen, pflegen und bearbeiten lassen. An entsprechenden Tools herrscht glücklicherweise kein Mangel.^[16]

Auf der Ebene von einzelnen Projekten, Teams und Abteilungen wird dieses Bestreben zu einer transparenteren Arbeitsweise zunehmend populärer und bewährt sich insbesondere in interdisziplinär angelegten Teams bzw. Projekten wie die Beispiele der TIB Hannover^[17] und ZB Zürich^[18] belegen, wo auch bereits die Zielgruppen mit einbezogen werden und fortlaufend neue Anforderungen in die Projekte einbringen können.

2.2 Die agile Bibliothek

Dasselbe Level an Transparenz auf die Ebene einer Bibliothek als Gesamtorganisation zu bringen, ist allerdings mit zusätzlichen Herausforderungen verbunden. An der Zentral- und Hochschulbibliothek (ZHB) Luzern werden z. B. die Ziele für das jeweils kommende Jahr für die gesamte Bibliothek in einem virtuellen Board gesammelt. Alle Mitarbeiter*innen sind jeweils während der individuellen Jahresendgespräche und Zielvereinbarungen im Oktober / November aufgerufen, zusammen mit ihren Vorgesetzten auch Jahresziele für die gesamte Bibliothek einzubringen. Diese müssen zwar zu einem der übergeordneten Strategiefelder der Bibliothek passen, sind ansonsten jedoch bewusst offen gehalten. Nach der Eingabe werden in einem transparenten Prozess die eingebrachten Ziele durch die Geschäftsleitung zusammen mit allen Beteiligten bei Bedarf konkretisiert und die Verantwortlichkeiten für die Umsetzung geklärt.^[19]

Für Jahres- bzw. Strategieziele gelingt dieses Vorgehen gut – der Prozess ist mit seinen Verantwortlichkeiten normalerweise auf der Leitungsebene angesiedelt und kann mit Zustimmung nur weniger Führungspersonen für alle Mitarbeiter*innen der Bibliothek in allen Standorten, Abteilungen und Teams geöffnet werden. Die gesamte Arbeit in einer Bibliothek auf diese Weise transparent zu machen, ist jedoch anspruchsvoller. So gibt es an der ZHB Luzern einerseits zahlreiche Abteilungen und Standorte, die ihre Abläufe und Projekte mit großer Begeisterung auf solchen Boards teilen und für Rückfragen, Hinweise und Verbesserungsvorschläge durch interessierte Kolleg*innen offen sind. Andererseits erschließt sich der Mehrwert (noch?) nicht für alle Abteilungen, wobei es gewinnbringend sein kann, die Ursachen genauer zu beleuchten. Sind die Abläufe und Problemlösungen in den betroffenen Bereichen so klar, unveränderlich und in sich abgeschlossen, dass kein Bedarf an einer agileren Vorgehensweise besteht? Gibt es Vorbehalte oder gar negative Vorerfahrungen bei Führungspersonen oder Mitarbeiter*innen gegenüber einem transparenteren Vorgehen? Besteht allenfalls eine technische Zugangshürde im Umgang mit einem Kollaborationstool, in dem zahlreiche Teams, Abteilungen und Standorte in mehreren Projekträumen zusammenarbeiten und eine womöglich überfordernde Anzahl an Informationen und Benachrichtigungen generieren?^[20] Besonders wertvoll ist in diesen Fällen der Austausch mit Berufskolleg*innen, die in ihren Bibliotheken bei der Umsetzung von agilen Prinzipien vor ähnlichen Herausforderungen und Fragen stehen, oft aber bereits auch Lösungen gefunden haben.^[21]

Abb. 3:

Virtuelles Stackfield-Board für die Jahresplanung der ZHB Luzern.

2.3 Platz schaffen für gemeinsames Lernen

Gelingt es hingegen, ein Vorhaben gleichermaßen transparent für Mitarbeiter*innen und Benutzer*innen zu machen und diesen von vornherein die Möglichkeit einzuräumen, Feedback in die Umsetzung zurückzuspielen, rücken das gemeinsame Lernen sowie die Offenheit und der Mut zu ungeplanten Lösungen in greifbare Nähe. Besonders anschaulich lässt sich dies am „Seat Navigator“ Pilotversuch der ZHB Luzern zeigen.^[22] Hier wurde das Problem der Platznot in der Bibliothek, insbesondere zu Prüfungszeiten, von vornherein mit allen Beteiligten angegangen.

Ein von der Alumni-Organisation der Universität Luzern gefördertes Vorprojekt kam dabei zu dem Ergebnis, dass ein sensorbasiertes System die Situation verbessern könnte, sofern es die aktuelle Auslastung sitzplatzgenau sowie im Vergleich zu anderen Bibliotheksstandorten webbasiert anzeigen kann. Die standortübergreifende Darstellung könnte zudem dazu beitragen, dass sich die Auslastung gleichmäßiger auf alle Bibliotheken verteilt.

Um diese mögliche Lösung aber nicht am tatsächlichen Bedarf vorbei, sondern mit angewandter Empirie zu entwickeln, wurde keine klassische Umsetzung angestrebt, sondern lediglich ein Prototyp im Rahmen eines Pilotprojektes erprobt sowie die Studierenden unmittelbar um Feedback gebeten. Die ersten Umfrageergebnisse waren ernüchternd: Nur etwa die Hälfte befürwortete die campusweite Einführung. Glücklicherweise zielte das Pilotprojekt aber nicht auf die Einführung des Prototypen, sondern auf die fortlaufende Erhebung des Feedbacks. Somit ergab sich nicht nur die Chance, bei der ablehnenden Hälfte der Befragten nochmals nachzuhaken, sondern deren Kritik auch direkt in die Verbesserung des Prototypen einfliessen zu lassen.

Hier war Offenheit gefragt – nicht nur bei den Bibliotheksmitarbeiter*innen, die augenscheinlich negatives Feedback nicht als Scheitern, sondern als begrüßenswerte, empirische Beobachtung im Kontext des gemeinsamen Lernens erfuhren, sondern auch bei den Umsetzungspartnern, welche die somit gewonnenen Hinweise auf einen fehlenden Pausenmodus (= Plätze, die nur vorübergehend verlassen wurden, dürfen vom System nicht sofort wieder als frei angezeigt werden) auch unmittelbar in den Prototypen einbauten.

Am Ende konnte ein angepasster Prototyp mit einer Zustimmung von zwei Dritteln der Befragten überzeugen. Dank der gemeinsamen Umsetzung mit der Universität und der Hochschule Luzern konnte die ZHB den Seat Navigator 2019/2020 an all ihren vier Bibliotheksstandorten mit rund 800 Sensoren produktiv einführen und davon insbesondere zu Prüfungszeiten sowie während der Covid19-Schutzmaßnahmen mit Abstandsregeln und reduziertem Platzangebot enorm profitieren.^[23]

Abb. 4:

Seat Navigator – Standortübergreifend und sitzplatzgenau.

2.4 Schulungsangebote als Beispiel empirisch getriebener Serviceentwicklung

Nicht nur von neuen Technologien getriebene Entwicklungen profitieren von einem Vorgehen, das explizit auf Empirie fußt. Gerade auch bei traditionell-bibliothekarischen Produkten kann eine empirisch getriebene Vorgehensweise sinnvoll sein. Die Vermittlung von Informationskompetenz gehört z. B. für viele Bibliotheken zum Kerngeschäft. Dabei haben die letzten Jahre gezeigt, wie schwierig es technologische oder gesellschaftliche Veränderungen machen, einheitliche Schulungsangebote zu planen und neu aufzubauen. Vor allem die Lebenswelten junger Menschen sind immer häufiger schnellen Wechseln unterworfen – verstärkt durch neue Informations- und Kommunikationstechnologien. Im Hinblick auf diese Altersgruppe ist die Gefahr besonders groß, dass auch sorgfältig geplante Vermittlungsangebote noch während der Entwicklung veralten. Für Bibliotheken mit Schulungsangeboten für Jugendliche und junge Erwachsene können deshalb viele Faktoren in der IK-Vermittlung vermehrt unklar erscheinen. Auf der einen Seite versuchen neueste Informationskompetenzstandards dieser Wandelbarkeit mehr Rechnung zu tragen. Auf der anderen Seite verspricht aber gerade auch ein agiles Vorgehen – mit dem dazu gehörigen agilen Mindset – einen Weg, Unklarheit sowie Unschärfe in den Entwicklungsprozess einzubinden und damit Schulungsangebote zu gestalten, die direkt auf dynamische Veränderungen eingehen.

2.5 Eine neue Tradition entsteht – Entwicklung nach Scrum

Als die Zentralbibliothek (ZB) Zürich 2021 beschloss, die IK-Schulungen für den sekundären Bildungsbereich neu zu gestalten, wich man bewusst von einer längeren Tradition in der Entwicklung von IK-Schulungen ab. Anstatt Anforderungen der zu schulenden Kund*innen aus der eigenen Erfahrung bzw. dem eigenen Wissen zu antizipieren, wollte das Entwicklungsteam dezidiert agil und empirisch vorgehen.^[24] Als produktive Hilfe auf diesem Weg erwies sich Scrum. Wie bereits weiter oben ausgeführt wurde, ist die Gefahr groß, beim Thema Agilität zuerst an Methoden anstatt an ein Mindset zu denken. Scrum ist jedoch keine eigentliche Methode. Vielmehr ist es ein Rahmenwerk, das die Verankerung von Empirie in der Entwicklung von Produkten gezielt fördert.

Bei der Entwicklung mit Scrum steht die Schaffung von Wert für die Endkund*innen im Zentrum.^[25] Um den Kundenwert sicherzustellen, fördert Scrum die inkrementelle und iterative Entwicklung. Produkte werden schrittweise in kurzen Zeitspannen, sogenannten Sprints, entwickelt. In jedem Sprint wird ein Teilprodukt fertiggestellt, ein Inkrement, das anschließend von Kund*innen und anderen Stakeholdern getestet und von ihnen evaluiert wird. Diese Evaluation gibt dem Entwicklungsteam direkte Hinweise darauf, wie es im nächsten Sprint weiter Wert schaffen kann. Auf diesem Weg kommt ein Produkt schrittweise zusammen, bis es den Wert erreicht hat, welcher vom Entwicklungsteam angestrebt, bzw. von den Endkund*innen gewünscht wird.

Dadurch, dass der Prozess der Überprüfung und Anpassung während der Entwicklung immer wieder durchlaufen wird, ist Scrum strikt empirisch. Wissen wird aus Erfahrung gewonnen und Entscheidungen auf der Grundlage von Beobachtungen gemacht.^[26] Dabei entsteht auch große Transparenz nach außen. Mit Scrum ist ein zu entwickelndes Produkt kein Geheimnis, sondern wird bereits während der Entwicklung aktiv in die Zielgruppe getragen. Nur so ist es möglich, früh zu reagieren und keine Zeit mit der Entwicklung von einem Produkt zu verlieren, das von ihr gar nicht oder ganz anders gewollt wird.

2.6 Eine Belohnung – aber für das Lernen

Wenn nach Scrum entwickelt wird, basiert der Produktwert nicht auf Annahmen, sondern auf effektiven Kund*innenmeinungen, die kontinuierlich abgeholt werden. Als an der ZB Zürich das Team IDE (Informationskompetenzvermittlung, Digitale Dienste und Entwicklung) eine Schulung für Abschlussklassen im sekundären Bildungsbereich überarbeite, starteten sie nur mit einem Produktziel („Eine IK-Schulung, die den Schüler*innen Spaß macht“) und einem Backlog an möglichen Anforderungen. Planungsdokumente wurden vorgängig keine erstellt. Man war sich bewußt, dass bestehendes Wissen über Informationskompetenz und Bibliothekspädagogik einen wichtigen Ausgangspunkt darstellt. Jedoch wurden solche Meinungen nicht als Orientierungspunkte für eine Planung betrachtet, sondern als Hypothesen, die es mit der Zielgruppe Schritt für Schritt zu verifizieren galt. Anstatt klassisches Reporting zu betreiben, wurden Produktinkremente nach jedem Entwicklungssprint den Stakeholdern gezeigt. Zudem war das Backlog immer einsehbar, sowohl für Mitarbeiter*innen als auch für Vorgesetzte. Input konnte von jedem jederzeit angebracht werden. Das Ziel war immer, so schnell wie möglich herauszufinden, ob die Entwicklung in Richtung Produktziel auf dem richtigen Weg war oder nicht.

Während der Entwicklung in sieben Sprints musste das wachsende Produkt oft angepasst werden. Ein gutes Beispiel dafür liefert die geplante Ausrichtung auf Gamification. Das Team war der Überzeugung, angeleitet vom Erfolg eines früheren Projekts, dass die Schulung ein Spiel mit übergreifender Story sein sollte. Eine Reihe von Rätseln sollten die Schüler*innen zu einer Kiste bringen, welche sie mit Codes öffnen konnten, die sie im Verlauf der Schulung erhielten. Darin befand sich als Belohnung ein Gästebuch, in das sich die Klassen eintragen konnten. Bereits in einem der ersten Tests wurde klar, dass ein thematisches Spiel für viele Personen in der Zielgruppe überhaupt nicht attraktiv war. Wie die testenden Schüler*innen unmissverständlich zum Ausdruck brachten, waren sie zum Lernen da, und nicht, um eine Geschichte zu erleben. Interessanterweise mochten aber viele die Idee einer Belohnung: ganz besonders die Möglichkeit, etwas am Ende der Schulung aufzuschließen. So wurden Truhe und Schlösser mit Codes beibehalten, aber die Entwicklung einer Geschichte komplett gestoppt.

Ohne die Offenheit, eigene Annahmen durch Endkund*innen in Frage stellen zu lassen, hätten solche Situationen eher zu Frust als zur Verbesserung des Produkts geführt. Durch die häufigen Feedbackschlaufen, die in Scrum vorgesehen sind, fiel es dem Team einfacher, diese Offenheit zu leben: Das Scheitern zu akzeptieren und daraus zu lernen, wird dank den kurzen Feedbackschleifen zu einem Vorteil. Scrum ist aber nur effektiv, wenn eine Organisation gerne kommuniziert (sowohl extern wie intern) und Transparenz wertschätzt. Den internen Stakeholdern an der ZB Zürich musste klar sein, warum der Entwicklungsprozess so offen gestaltet wurde. Kurze Vorausplanung sowie das indirekte Reporting (via offenem Backlog) durften nicht als unzureichende Projektplanung wahrgenommen werden, sondern als Chance, besser mit Unsicherheiten und raschen Veränderungen umzugehen.

3.1 Wie Retrospektiven Offenheit und Respekt fördern: Gemeinsam New Work entdecken

Ein weiteres Beispiel gelebter agiler Werte ist die Diskussion des Umgangs mit dem mobil-flexiblen Arbeiten im Team. Auf Basis der sehr fortschrittlichen Regelungen des Kantons Luzern für mobil-flexibles Arbeiten^[27], die während der ersten zwei Jahre der Corona-Pandemie ausgiebig getestet werden konnten, traf sich ein Team im Rahmen einer regulären Retrospektive zum Schwerpunktthema „Künftige Arbeitsweise“. Darin stellte sich nicht nur die Frage, ob und wie viel Homeoffice die einzelnen Teammitglieder gerne hätten. Vielmehr ging es auch um Aspekte wie Präferenzen für virtuelle oder analoge Durchführung von Meetings unterschiedlicher Art oder wie künftig bei erhöhter Homeoffice-Quote und seltenerem physischem Beisammensein des ganzen Teams dennoch der Zusammenhalt und spontane Austausch sichergestellt werden kann. Und letztlich soll auch das Arbeiten vor Ort bewusst Vorteile bieten, die das Homeoffice eventuell nicht bieten kann, so dass der Besuch im Büro einen Mehrwert bietet. Das Fazit war, dass allseits eine starke Präferenz für Flexibilität und Virtualität vorrangig sein soll – das physische Büro aber eine optimale Ausstattung und Einrichtung für die analog-typischen Arbeiten bieten soll.

Damit ein solcher Austausch möglich wurde, brauchte es verschiedene Dinge:

• Flexibilität von der Organisation und die Möglichkeit, das Team selbst seine ideale Lösung finden zu lassen,

• Vertrauen in das Team, dass sie selbständig eine Umsetzungsweise finden würden, die sie ihre Arbeit optimal erledigen lässt und dennoch Flexibilität für individuelle Umstände lässt,

• gegenseitigen Respekt im Team, um offen persönliche Vorlieben zu kommunizieren, anzunehmen und bei Bedarf einen Konsens zu entwickeln und

• Mut im Team, um auch visionäre Ideen und Wünsche vorzubringen, zu diskutieren und gegebenenfalls auszuprobieren.

Tatsächlich lässt sich nach mehreren Monaten ein Zwischenfazit ziehen, dass die vom Team entwickelte Lösung weiterhin breit unterstützt und sogar außerordentlich geschätzt wird. In ersten Belastungsproben hat sie gut funktioniert und die Akzeptanz weiter gestärkt.

3.2 Wie aus Scheitern mit Mut etwas Neues entstehen kann

Im Kontext einer agilen Transformation braucht es nicht nur Mut für visionäre Ideen und Wünsche, sondern auch im Umgang mit Fehlern und Misserfolgen. Eine offene Fehlerkultur ist hierbei viel schneller eingefordert, als dass sie sich tatsächlich leben lässt, da sie ebenfalls ein anspruchsvolles Umdenken bei allen Beteiligten erfordert. Das fängt schon bei uns nur allzu vertrauten Begrifflichkeiten an. Ein auf wenige Monate angelegtes, agiles Pilotprojekt, auf welches keine produktive Umsetzung folgt, nehmen wir oft als „Scheitern“ wahr, als wäre es etwas negatives, schnell, unter kurzem Ressourceneinsatz und im fortlaufenden Dialog mit den Zielgruppen festzustellen, dass ein Prototyp nicht funktioniert, den beabsichtigten Bedarf nicht deckt oder eine grundlegende Weiterentwicklung benötigt. Dahingegen werden klassische und ressourcenintensive Großprojekte, die oft über Jahre zunächst alles in der Theorie konzipiert haben, ohne angewandte Empirie (Einbezug des Feedbacks von Early Adoptern, Befragungen, Usability-Tests etc.) einfach umgesetzt und allein die Tatsache des produktiven Betriebs bereits als „Erfolg“ verkauft. Dies selbst dann, wenn das Produkt im Praxisbetrieb nachweislich den Bedarf nur teilweise deckt, verfehlt oder vor dem keinesfalls seltenen Problem steht, dass sich die Nachfrage während der langwierigen, klassischen Konzeptionsphase komplett gewandelt oder gar erübrigt hat.

Als Beispiel kann hier das „Lucebro“-Pilotprojekt der ZHB Luzern dienen.^[28] Die Idee, wiederkehrende Fragen zur Bibliothek und deren Benutzung durch eine KI-Software teilweise zu automatisieren sowie die Antwortzeiten bei komplexen Fragen an Expert*innen zu reduzieren, wurde in einem agilen Pilotprojekt ausprobiert. Im Gegensatz zum klassischen Projektmanagement war es dabei nicht das Ziel, eine fertige Lösung (z. B. Chatbot, Kommunikationstool o. ä.) produktiv einzuführen. Vielmehr ging es darum, schnell und empiriebasiert Feedback von den Bibliotheksnutzer*innen einzuholen, ob eine KI-basierte Software eine Hilfe in diesem Anwendungsfall bieten kann.

Das Pilotprojekt lieferte dabei wertvolle Erkenntnisse. So konnte festgestellt werden, dass die fortlaufend im Pilotprojekt befragten Bibliotheksnutzer*innen dem Thema KI-Einsatz in Bibliotheken aufgeschlossen gegenüberstanden und auch die konkret eingesetzte Software „Starmind“ hinsichtlich gewahrter Anonymität, Usability, Schnelligkeit und Qualität der Antworten positiv bewerteten.^[29] Es war jedoch eine geringe Nutzung des Tools zu beobachten, die sich kongruent zur in Befragungen häufig geäußerten Kritik an der Registrierungshürde verhielt. Um die Software zu nutzen, war die Registrierung eines minimalen Benutzungsaccounts (E-Mail-Adresse und Passwort) notwendig, damit die Software Fragesteller*innen über Antworten benachrichtigen konnte. Der Account war zudem notwendig, damit interessierte Bibliotheksnutzer*innen im System auch selbst zu „Expert*innen“ werden konnten, wenn sie anderen selbst mit Antworten weiterhalfen.

Das Pilotprojekt hat jedoch nachgewiesen, dass die Zielgruppe insbesondere für kurze, wiederkehrende Fragen („Wann hat die Bibliothek geöffnet?“, „Wie kann ich mich anmelden?“) nicht bereit ist, sich zunächst mit einem Account zu registrieren. Intelligente Frage- / Antwortlösungen müssen im Bibliotheksbereich also deutlich leichter zugänglich sein. Ein wichtiger Lerneffekt, der direkt in einem Folgeprojekt nachgenutzt werden konnte – alle der KI antrainierten Fragen und Antworten beherrscht nun auch der Pepper-Roboter „Luzi“ der ZHB Luzern, den man direkt vor Ort in der Bibliothek einfach ansprechen kann.^[30]

Abb. 5:

Lucebro – Web- und KI-basiertes Frage- / Antwort-Tool.