‚Arbeitskulturen‘ im Wandel Erfahrungen und Entwicklungen in 20 Jahren DH-Praxis

Einleitung

Im ‚Zeitalter des Druckes‘ war die Entstehung des kulturellen Gedächtnisses von Individuen und Autoritäten geprägt, das Buch Ziel und Ergebnis der (scheinbar) finalen Forschung (u.a. Burdick et al. 2012). Im Gegensatz zum traditionellen Forschungsprozess stehen die DH für ‚Teamwork‘ und ‚Kollaboration‘ sowie für eine Art und Weise zu forschen und zu publizieren, die eher ‚prozessorientiert‘ als ‚produktorientiert‘ ist (Griffin u. Haylor 2018: §1, Tabak 2017: §6). Um die skizzierten Paradigmen des digitalen Forschungsprozesses in der Praxis zu verinnerlichen und zu adaptieren, hat TELOTA (kurz für „The Electronic Life Of The Academy“),¹  die DH-Abteilung der Berlin-Brandenburgischen Akademie der Wissenschaften (BBAW), in seiner 20-jährigen Geschichte mehrfach die eigenen Arbeitsstrukturen evaluiert und überarbeitet. Ausgehend davon wird der Vortrag eine seit etwa 2020 etablierte Organisationsstruktur, die Team, Projekte und Forschungssoftwareentwicklung umfasst, vorstellen sowie Erfahrungen in der Umsetzung reflektieren. 

Da die DH nicht nur für geisteswissenschaftliche Forschung mit digitalen Methoden, sondern auch für einen Wandel des Forschungsprozesses selbst stehen, zählt der Themenbereich ‚Organisation und Workflows‘ zu Kontext und Bedingungsrahmen, in dem das kulturelle Erbe digital erschlossen wird, und bildet rund um die Frage nach DH-spezifischen ‚Arbeitskulturen‘ ein spannendes Diskussionsfeld zu „Kulturen des digitalen Gedächtnisses“.

Kontext

In den letzten Jahren gab es auf den DHd-Konferenzen vermehrt Beiträge zu verschiedenen Formen von Arbeitsorganisation in den DH, die vor allem den Aufbau neuer DH-Standorte thematisiert haben (Roeder et al. 2020, 2019a u. 2019b). Entgegen der Annahme, vor allem Standorte, an denen ‚DH from Scratch‘ betrieben wird, sähen sich mit „institutionellen, organisatorischen, personellen und technischen Anforderungen“ (Roeder et al. 2019b) konfrontiert, gilt dies auch für langjährig gewachsene DH-Abteilungen, die zum Teil auf über zwei Dekaden des Bestehens und Arbeitens zurückblicken.²  Aus der Phase des Experimentierens herausgewachsen stehen sie vor ganz anderen Herausforderungen: So hat die Etablierung der DH als Methode und Fach im Allgemeinen vor allem im letzten Jahrzehnt einen regelrechten ‚Boom‘ an digitalen Forschungsprojekten ausgelöst. Abgesehen von stetig neuen Projekten haben die Standorte ‚mit Vergangenheit‘ bereits eine ganze Generation von nicht mehr finanzierten Legacy-Projekten in Betrieb zu halten. Das Wachstum an Projekten hat aus ehemals kleinen Standorten mit geringer personeller Dichte und Lab-Charakter in relativ kurzer Zeit große Teams mit vielen und vielfältigen Mitarbeiter/innen gemacht. In der Konsequenz funktionieren althergebrachte, auf wenige Projekte und auf ein kleines Team ausgerichtete Workflows und Arbeitsstrukturen nicht mehr und müssen neu gedacht werden. Orientierungspunkte einer Restrukturierung von Arbeitsprozessen in den DH können dabei u.a. Methoden aus der Softwareentwicklung (Usher et al. 2020, Agile Business Consortium 2014, Rubin 2012) sowie - teilweise davon abgeleitete - DH-spezifische Ansätze aus dem internationalen Kontext bilden (Smithies u. Ciula 2020, Smithies et al. 2019, Ferraro u. Sichani 2018, Tabak 2017, Reed 2014).

Hintergrund: 20 Jahre TELOTA

2021 feiert TELOTA seinen zwanzigsten Geburtstag. Anfänglich eine eher strategische Initiative, begann die Arbeit im Bereich der Softwareentwicklung etwa 2005. TELOTA bestand damals aus einer Leitung, zwei Mitarbeiter/innen und zwei studentischen Hilfskräften und hatte einen stark experimentellen Charakter. Die Phase der technischen Professionalisierung setzte ab etwa 2008 ein, als die Fokussierung auf einzelne Projekte um die Perspektive der projektübergreifenden Standardisierung erweitert wurde (Grötschel u. Neumann 2011). Ab Mitte der 2010er Jahre führte das steigende Interesse der Vorhaben der BBAW an der Umsetzung digitaler Projekte sowie von externen Projektpartnern an der Nachnutzung der von TELOTA entwickelten Werkzeuge zu einem starken Anstieg an neuen Projekten, wodurch sich auch das TELOTA-Team vergrößerte: 2015 bestand das Team noch aus einer Leitung, fünf wissenschaftlichen Mitarbeiter/innen und vier studentischen Hilfskräften. Im Juli 2021 umfasst TELOTA eine Leitung, eine Koordination (beide Autor/innen dieses Beitrags), achtzehn wissenschaftliche Mitarbeiter/innen (die allerdings nicht alle Vollzeitstellen besetzen) sowie drei studentische Hilfskräfte. Zum TELOTA-Portfolio, das Forschungssoftware wie digitale Editionen, Objektsammlungen, Webservices, Frameworks und Tools umfasst, zählen rund 30 aktuell laufende bzw. in der Entwicklung befindliche Projekte sowie ca. 30 Legacy-Projekte, die verfügbar gehalten und in regelmäßigen Abständen überarbeitet und migriert werden. 

Die Arbeitsorganisation bei TELOTA war und ist von jeher vom ressourcentechnischen Umstand geprägt, dass es mehr Projekte als Mitarbeiter/innen gibt, wobei die Differenz kontinuierlich steigt, denn jedes nicht mehr finanzierte Projekt bleibt ein Projekt bzw. eine Publikation, die weiterhin gewartet und verfügbar gehalten werden muss. Dieser Tatsache ist es maßgeblich geschuldet, dass sich die Teamstruktur und Projektbetreuung bei TELOTA im Laufe der Zeit wie folgt entwickelte: Jede/r Mitarbeiter/in arbeitete kontinuierlich und meistens alleine an ein bis drei Akademienvorhaben und ggf. mit weiteren Stellenprozenten in Drittmittelprojekten. Diese Arbeitsweise war für die Entwickler/innen auf Dauer belastend, da die Entwicklungszeit und -konzentration sowohl durch die über mehrere Projekte verteilte Aufmerksamkeit als auch durch die gleichzeitige Übernahme von koordinatorischen Aufgaben beeinträchtigt wurde. Erschwerend kam hinzu, dass Wissen über Projekte oft bei einzelnen Entwickler/innen lag, wodurch der ‚Bus-Faktor‘ (oder auch ‚Truck Factor‘; Williams u. Kessler 2002: 41) gleich “1” war, was bedeutet, dass jedes Teammitglied über Spezialwissen verfügt und ein Ausfall (z.B. durch Kündigung) das Projekt zumindest für eine gewisse Zeit lahmlegen könnte. 

Herausforderungen

Die allgemeinen Herausforderungen der Arbeitsorganisation kann anhand einer vertikalen und einer horizontalen Skalierungsebene skizzieren. Die vertikale Ebene beschreibt die wachsende Komplexität der einzelnen digitalen Projekte von der Datenmodellierung über Datenspeicherung, Programmierschnittstellen und Visualisierungen bis hin zur Publikation, Langzeitverfügbarkeit und -archivierung. Die Kompetenzen, um dieses Aufgabenspektrum abzudecken finden sich nur in den seltensten Fällen in einer Person, so dass es in einem Projekt nicht mehr ausreicht, auf eine/n Digitalspezialisten/in zurückzugreifen, sondern auch hier die Aufgaben auf ein Team verteilt werden müssen. 

Die zweite Ebene ist die horizontale, die schlicht die Menge der in den Einrichtungen parallel umzusetzenden digitalen Projekte beschreibt, sowie die Bedarfe und Einzelanforderungen dieser Projekte, die wiederum Einfluss auf die vertikale Ebene haben. Betreut ein DH-Team viele Projekte parallel, können in diesen Projekten nicht alle Anforderungen in einer kurzen Entwicklungszeit umgesetzt werden. Umgekehrt bedeutet dies, dass wenn komplexe Projekte bearbeitet werden, wenig bis keine parallelen Projekte betreut werden können. 

Da die Schnittmenge beider Ebenen in den letzten Jahren deutlich gestiegen ist, konnte die oben beschrieben Arbeitsweise (siehe „Hintergrund“) nicht mehr fortgeführt werden. Nachdem verschiedene Modelle der Restrukturierung der Arbeitsorganisation bei TELOTA evaluiert und erprobt wurden, ist seit 2020 ist eine Organisationsstruktur im Einsatz, die ganzheitlich gedacht auf Personen, Projekte und Software ausgerichtet ist.  

Teamstruktur

Wie bereits erwähnt waren zentrale Probleme der Teamstruktur, dass es eigentlich kaum Entwicklung in Teams gab, und, dass Personen mit mehreren Rollen belegt waren, zum Beispiel als Entwickler/in und DH-Koordinationsstelle eines Projekts. Die Restrukturierung von TELOTA umfasste daher zunächst einmal die Einführung einer Koordinationsstelle, deren Aufgaben – in Absprache mit der Leitung – Kommunikation sowie die mittel- und langfristige Entwicklungsplanung umfassen. Die Koordinationsstelle entwickelt und begleitet den neu etablierten Projektworkflow, unterstützt und berät die Projektpartner/innen bei der Planung der DH-spezifischen Ziele, koordiniert die Absprachen mit den Entwicklungsteams und schreitet vermittelnd ein, wenn sich Sackgassen auftun.

Eine weitere Maßnahme der Restrukturierung war die Zuordnung der rund achtzehn Mitarbeiter/innen zu kleineren Teams, die wiederum gemeinsam Cluster aus thematisch und technologisch ähnlichen Projekten bearbeiten, um möglichst große Synergieeffekte zwischen Projekten zu kreieren. Die sich dadurch ergebenden Teams bestehen aus rund 6 bis 8 Personen (mit unterschiedlichen Stellenanteilen), die jeweils zu zweit oder dritt ein Projekt bearbeiten. Während der Entwicklungsphasen (siehe “Projektworkflow”) sind die Entwickler/innen ebenfalls an Planungsaufgaben für die direkt anstehenden Softwareentwicklungstasks beteiligt, werden aber von größeren Aufgaben (z.B. Mitwirkung bei Antragstellungen, strategische Sitzungen u.Ä.) durch die Koordinationsstelle entlastet.

Projektworkflow

Die Entwicklungsarbeiten der oben erwähnten Teams erfolgt seit Anfang 2020 nach dem Modell der ‚Entwicklungsblöcke‘ (Abb. 1). Angelehnt an das Konzept von „Sprints“ aus der Scrum-Methodik (Rubin 2012), handelt es sich dabei um fest definierte Zeiträume, in denen ein Team aus Entwickler/innen ein zuvor geplantes Zwischenziel umsetzt.³  Die Zwischenziele werden iterativ, jeweils vor einem Entwicklungsblock, definiert, stehen mit der grundsätzlichen Roadmap eines Projekts im Einklang, bleiben aber nicht in starren und ausführlichen Vorab-Planungen verhaftet. Im Gegensatz zum klassischen Scrum-Sprint, der nach Features und möglichst kleinteilig konzipiert ist, handelt es sich bei den Entwicklungsblöcken um Arbeitspakete, die eine Menge an Features bzw. Tasks zusammenfassen, welche nach einer gemeinsam bestimmten Priorisierung bearbeitet werden. Durch dieses Vorgehen dauern die Entwicklungsblöcke mit 4-12 Wochen Laufzeit auch wesentlich länger als klassische Scrum-Sprints von etwa 2-4 Wochen.

Alle Teilziele, Tasks, Fehler und Featurewünsche zu einem Projekt fließen in ein von allen Beteiligten gepflegtes Projekt-Backlog ein (z.B. ein Issues in GitLab, Tickets in Redmine, oder Zeilen in einem Spreadsheet), aus dem eine Teilmenge im Vorfeld einer Entwicklungseinheit mit Blick auf die Roadmap des Projekts, die Aufgabenpriorisierung durch die Projektpartner sowie entwicklungstechnische Empfehlungen TELOTAs als Milestone definiert wird. Die eigentliche Entwicklungsphase startet mit einem Kick-Off-Treffen mit allen Mitarbeiter/innen des Projekts, bei dem Ablauf und Aufgaben noch einmal durchgegangen werden. In der Entwicklungsphase kann sich das Entwickler/innenteam voll und ganz auf die definierten Zwischenziele konzentrieren, neue Featurewünsche müssen zunächst mit der Koordinationsstelle, die in etwa der Rolle des „Product Owners“ in Scrum entspricht, abgestimmt werden. Ist die Softwareentwicklung gestartet, so wird regelmäßig Feedback eingeholt, u.a. in fest etablierten face-to-face-Meetings.

Die Entwicklungsphase endet mit einem Release der Entwicklungen, der gesamte Entwicklungsblock mit Reviewgesprächen innerhalb des TELOTA-Teams und mit den Projektpartnern. Die Demonstration der neu entstandenen Entwicklungen, die Evaluation der Zusammenarbeit sowie der Blick auf die Projektroadmap bilden die Grundlage für den nächsten Entwicklungsblock. 

Auch wenn das klassische Scrum-Modell der „Sprints“ aufgrund der personellen Ressourcen nicht in aller Konsequenz bei TELOTA durchführbar ist,⁴  kann die Forschungssoftwareentwicklung und die parallel erfolgende geisteswissenschaftliche Forschung von einigen Prinzipien der Methode profitieren. Das Konzept von ‚Time-Boxes‘, die intensive Bearbeitungen von Teilzielen und unmittelbare Releases wirken sich beispielsweise motivationssteigernd aus, weil man von Beginn an auf konkrete Resultate bzw. ‚sichtbare‘ Ergebnisse zusteuert. Gleichzeitig werden bei häufigen Releases frühzeitig Probleme erkannt und Kurskorrekturen möglich. Schließlich generieren die regelmäßigen Meetings, der Erfolgsmoment beim Release und die Feedbackkultur ein Gefühl der Zusammengehörigkeit aller Projektbeteiligten, der das „wir“ und „ihr“, das es oftmals in der Zusammenarbeit zwischen Forschungssoftwareentwickler/innen und Geisteswissenschaft/lern gibt, auflöst. 

Werkzeugkasten

Zentral bei der Neuorganisation der Softwareentwicklung ist die Verständigung auf einen gemeinsamen technologischen Werkzeugkasten, was u.a. durch die aufwendige Wartung vieler technologisch komplexer Legacy-Projekte dringlich wurde. Leitprinzipien des Werkzeugkastens sind u.a. möglichst nachhaltige und keine in ihrer Funktion redundanten Technologien zu verwenden. Unterschieden wird dabei zwischen ‚Primär‘- und ‚Sekundärtechnologien‘, wobei erstere beispielsweise Programmiersprachen, Datenbanksysteme und umfassende Framework-Plattformen, deren erstmalige Verwendung einen erhöhten Einarbeitungsaufwand bedeutet, umfassen. Die Neueinführung einer Primärtechnologie bedarf daher der Abstimmung mit Leitung, Koordination und Systemadministrator/innen sowie, wenn der Einführung stattgegeben wird, die Durchführung von Schulungen im Team. Unter Sekundärtechnologien fallen Libraries oder kleinere Frameworks, die ggf. auf einer bereits verwendeten Primärtechnologie basieren, leicht zu lernen sind, und deren Verwendung keiner Abstimmung bedarf.

Der Aufbau des Werkzeugkastens ist ‚produktorientiert‘, d.h. die Technologie-Stacks werden ergebnisorientiert vorgeschlagen.⁵  Mittels eines Flow-Charts bzw. Entscheidungsbaums (Abb. 2) wird veranschaulicht, wie man als Nutzer/in an den Werkzeugkasten herantritt. Für jedes Ergebnis ist eine User-Story definiert, die, abgesehen von User Story 1 („der Werkzeugkasten beinhaltet bereits eine passende Technologie bzw. einen passenden Technologie-Stack“), Szenarien und Prozeduren für die Neueinführung einer Produktkategorie oder Technologie definiert.

Ausblick

Jeder DH-Standort agiert und arbeitet unter spezifischen ressourcentechnischen, personellen und finanziellen Bedingungen, was es erschwert, von den vorgestellten Überlegungen und Ergebnissen allgemeine Empfehlungen für die Strukturierung von Teams, Projekten und Software zu abzuleiten. Grundsätzlich wird aber deutlich, dass die stärkere Reflexion und Konzeptualisierung der ‚Arbeitskultur‘ nicht nur bei sich im Aufbau befindlichen DH-Zentren, sondern auch bei Standorten mit langer Tradition und eher ‚eingefahrenen‘ Strukturen sinnvoll sein kann. Neben den hier vorgestellten Verfahren gibt es eine Reihe weiterer Punkte, die eine regelmäßige Evaluation und Überarbeitung der eigenen Arbeitsstrukturen sinnvoll erscheinen lassen und die zukünftig in den Blick genommen werden. Dazu gehört u.a. eine weitere Professionalisierung und Spezialisierung der einzelnen Teammitglieder auf bestimmte Technologien bzw. Technologie-Cluster, was neben einer Reduzierung des Risikos von Ausfällen auch zu einer stärkeren Fokussierung der Kompetenzen führt. Darüber hinaus sichert dies die Qualität von Forschungssoftware und damit die Langlebigkeit unseres „digitalen Gedächtnisses“.