Auch in der Intertextor-Entwicklung setzen wir Verfahren des agilen Projektmanagements mit mehr oder weniger Erfolg um. Das Scrum-Element des Daily Meetings haben wir auf höherer SCDH-Ebene, dort spielt der Intertextor (als ein Entwicklungsprojekt neben sehr vielen vom SCDH begleiteten Forschungsprojekten) nicht jedes Mal explizit eine Rolle. Statusmeetings (von Kremer et al. 2024 zweimal wöchentlich empfohlen) finden bei uns einmal wöchentlich mit explizitem und ein zweites Mal mit möglichem Intertextorbezug statt (in Anwesenheit des Product-Owners); zusätzlich haben wir ein wöchentliches Treffen von Scrummaster und Entwicklern. Der Scrummaster ist zusätzlich Systemarchitekt des SCDH und als solcher ebenfalls Stakeholder des Intertextors (neben den Forschungsprojekten, die konkrete methodische Anforderungen an das Tool haben). Wir haben ein Product-Backlog mit Userstorys und ein Sprint-Backlog (in Form priorisierter Userstorys), sodass inkrementorientiertes Arbeiten mit hoher Autonomie des Teams in den Arbeitsphasen möglich wird. Die große Herausforderung bleibt, die unterschiedlichen Geschwindigkeiten der Projektlogiken (s. beispielhaft u.) auf der einen und der dauerhaften generischen Lösungen auf der anderen Seite zu vereinen (vgl. auch Neubert 2020, 71f.). Kremer et al. (2024) betonen die gute Passung von Scrum zu Entwicklungsprojekten von Forschungssoftware-Prototypen. Die darin implizierte Schnellschussmetaphorik, die „Projektifizierung geisteswissenschaftlicher Forschung in kurzzeitige Einheiten“ (Cremer et al. 2024) könnte ein Grund sein, der einer langfristigen generischen Lösung, einem lauffähigen und dauerhaft durch eine Institution der Forschungsinfrastruktur betriebenen Forschungstool entgegensteht. Spezifische Bedarfe, die an das generische Tool gestellt werden, werden im Folgenden beispielhaft anhand eines der Stakeholderprojekte, dem Ijob-Projekt, illustriert.