1 Einleitung

Im alltäglichen Lebensvollzug werden immer mehr Entscheidungen vom Einflussbereich des Menschen auf den Wirkbereich von Maschinen verlagert. Dieser Transformationsprozess bleibt im öffentlichen Diskurs nicht ohne Kritik (vgl. Zweig 2019; Precht 2020). Im interdisziplinären Diskurs gilt moralischen Fragestellungen ein besonderes Augenmerk, da insbesondere KI-basierte Anwendungen vermehrt in Entscheidungsprozesse eingreifen und deren Resultate mit moralischer Verantwortung verknüpft sind, die nur Menschen – nicht Algorithmen, Anwendungen und Maschinen – zuzuschreiben sind (vgl. Hübner 2021).

Im übertragenen Sinne lässt sich damit die Verantwortung nicht mehr dem unmittelbar Handelnden bzw. Ausführenden attestieren, sondern dem Designer und Entwickler von Prozessen, Produkten oder Dienstleistungen. Neuartig in der Geschichte der Philosophie ist hieran, dass moralische Entscheidungen jetzt a priori im Design von Prozessen, Produkten und Dienstleistungen berücksichtigt werden müssen. Eines der bekanntesten Beispiele ist das vom MIT entworfene Projekt Moral Machine, in dem Menschen mit der Frage konfrontiert worden sind, welche moralische Entscheidung eine intelligente Maschine in bestimmten Situationen treffen sollte (vgl. MIT 2016).

Der vorliegende Beitrag geht von der Theorie aus, dass moralisches Verhalten und wirtschaftlicher Erfolg Hand in Hand gehen können. Dieser Gedanke ist nicht neu: Er findet sich in der europäischen Kulturgeschichte im Bild des ehrbaren Kaufmanns wieder (vgl. Wegmann et al. 2009). In Anlehnung an den Münchner Wirtschaftsethiker Karl Homann lohnt es sich für Unternehmen aus Wettbewerbsgründen moralisch zu handeln (vgl. Homann 2003). Homanns Position erscheint aktuell. Verstärkt lässt sich beobachten, dass Konsumenten durch ihr Kaufverhalten Anreize für Unternehmen schaffen, moralische Anforderungen verstärkt in den Blick zu nehmen (Beispiele: vgl. Fairphone 2021; Share 2021). Vor allem die sogenannte Generation Z konsumiert bewusster und hat dabei ein Augenmerk auf Klimaschutz und faire Herstellungsbedingungen etc. (vgl. Springer Professional 2019). Laut der Otto-Trendstudie zu ethischem Konsum im Jahr 2020 ist das Konsumieren ethischer Produkte in Deutschland bereits zum Mainstream avanciert (vgl. Otto Group 2020).

Geht es um Unternehmen der Information- und Technologiebranche, welche Künstliche Intelligenz einsetzen, kommt hinzu, dass es innerhalb der Europäischen Union mit einer hohen Wahrscheinlichkeit in Zukunft zu staatlichen Regulierungen kommen wird. Im aktuell von der EU-Kommission veröffentlichten Proposal für einen „Artificial Intelligence Act“ wird die Integration moralischer Aspekte hervorgehoben (European Commission 2021). Gestalten Unternehmen bereits heute ihre Entwicklungs- und Designprozesse dahingehend, dass moralische Anforderungen gezielt Berücksichtigung finden, kann dies einen Wettbewerbsvorteil darstellen. Nicht zu unterschätzen, bleibt der Präventionsgedanke: Risiken von Imageschäden, die im Zusammenhang einer moralisch fehlerhaft agierenden Künstlichen Intelligenz auftreten, können mit entsprechenden Entwicklungsprozessen minimiert werden.

Blickt man auf den öffentlichen Diskurs (vgl. Zweig 2019; Precht 2020) und die Forschung (vgl. Mittelstadt 2019) besteht offensichtlich ein dringender gesellschaftlicher und wirtschaftlicher Bedarf, moralische Anforderungen bei der Entwicklung von KI-basierten Anwendungen verstärkt zu berücksichtigen.

Mit Rückgriff auf publizierte Frameworks und Guidelines widmet sich dieser Beitrag der Anreicherung des industrieweit anerkannten Vorgehensmodells Scrum durch gezielte Berücksichtigung moralischer Anforderungen bei der Entwicklung einer KI-basierten Anwendung.

Im Beitrag werden folgende Forschungsfragen untersucht:

  • Wie lassen sich moralische Anforderungen in konkrete Anwendungsfälle „übersetzen“?

  • Wie können moralische Anforderungen bei der Erstellung von KI-basierten Anwendungen auf einfache Weise im Design- und Entwicklungsprozess berücksichtigt werden?

  • Welche methodischen Ansätze lassen sich im agilen Vorgehensmodell Scrum nutzen?

Im Beitrag wird gezeigt, wie sich moralische Anforderungen innerhalb der einzelnen Phasen eines Scrum-Projektes in den Entwicklungsprozess einbeziehen lassen. Dies wird u. a. durch den Einsatz von Moral-Stories ermöglicht, welche dem Entwicklungsteam helfen, moralische Anforderungen aus Nutzersicht zu formulieren und umzusetzen. Der vorgestellte Ansatz wird mit Anwendungsfällen aus einem realen Entwicklungsprojekt, der Implementierung eines KI-basierten Lerntagebuchs für Jugendliche, veranschaulicht.

Der Beitrag setzt sich aus fünf Teilen zusammen. Nach diesem Einleitungskapitel (Kap. 1), wird in Kap. 2 der Stand der Forschung zur Berücksichtigung moralischer Anforderungen in der Softwareentwicklung vorgestellt. Kap. 3 bildet den Hauptteil: Hier werden die einzelnen Scrum-Phasen (Projekt-Initialisierung, Sprint-Planung, Sprint-Durchführung und Sprint-Retrospektive) angereichert, um moralische Anforderungen im Entwicklungsprozess gezielter zu berücksichtigen. In Kap. 4 wird der vorgestellte Ansatz evaluiert, bevor Kap. 5 mit einer Zusammenfassung und einem Ausblick abschließt.

2 Stand der Forschung

Geht es um die Integration moralischer Anforderungen in die Softwareentwicklung im Allgemeinen und die Entwicklung KI-basierter Anwendungen im Speziellen, so sind in Theorie und Praxis aktuell vor allem zwei Ansätze anzutreffen: Guidelines und Frameworks. Im Folgenden werden entsprechende Beiträge vorgestellt, die sich im wissenschaftlichen, staatlichen und wirtschaftlichen Kontext einer hohen Beliebtheit erfreuen.

2.1 Guidelines

Ein Blick in die Praxis zeigt, dass Unternehmen und institutionelle Einrichtungen derzeit überwiegend mit Guidelines zu Künstlicher Intelligenz arbeiten. Jobin et al. (2019) veröffentlichten eine Analyse zu publizierten Guidelines und Prinzipien für Künstliche Intelligenz. Ihre Analyse umfasst insgesamt 84 entsprechende Beiträge, die überwiegend aus der privaten Wirtschaft, von Regierungsbehörden, von wissenschaftlichen Institutionen oder nationenübergreifenden Organisationen stammen. Alle untersuchten Guidelines sind inhaltlich ähnlich. Die Autoren identifizieren dabei elf ethische Prinzipien, die besonders häufig in den Guidelines zu finden sind: Transparency, Justice & Fairness, Non-maleficience, Responsibility, Privacy, Beneficence, Freedom & Autonomy, Trust, Sustainability, Dignity und Solidarity.

Die Listung und Beschreibung moralischer Leitlinien wirft gewisse Kritik auf, da sie oft aus einem akademisch geprägten Kontext stammen und der Transfer in die Praxis offenbleibt (vgl. Hagendorff 2020; Mittelstadt 2019). Vor allem große Konzerne wie Microsoft oder IBM haben diese Herausforderung identifiziert und nutzen in Ergänzung zu den Guidelines Programme wie „Putting principles into practice“ (vgl. Microsoft 2021) oder „Everyday Ethics for Artificial Intelligence“ (vgl. IBM 2019).

2.2 Frameworks

Frameworks sind im Gegensatz zu den Guidelines auf einer praktischeren Ebene angesiedelt und zeigen, wie sich moralische Anforderungen im Arbeitsprozess integrieren lassen. Die vorliegende Auswahl beschränkt sich auf zwei Beispiele aus dem wissenschaftlichen Kontext: einen im IEEE Transactions on Technology and Society publizierten internationalen Beitrag (Responsible Design Process-Framework) und einem deutschen durch das Bayerische Forschungsinstitut für Digitale Transformation herausgegebenen Beitrag (EDAP-Schema). Ergänzend wird ein in der Wirtschaft beliebtes Framework – das Solution Canvas – mit moralischer Anreicherung gezeigt (Ethics Canvas Manual).

Responsible Design Process-Framework

Peters et al. (2020) modifizieren unter anderem den Double Diamond aus dem Design Thinking, um einen Responsible Design Process zu kreieren. Der aus fünf Phasen bestehende Double Diamond (Research, Insights, Ideation, Prototypes, Evaluation) wird mit moralischen Anforderungen angereichert. Im Zentrum des Design Prozesses steht das „human wellbeing“ (vgl. Peters et al. 2020).

Dieser Ansatz ist zur Orientierung in Entwicklungsprojekte als praxisnah zu beurteilen, da der Double Diamond ein gängiges und bekanntes Framework des UX-Designs darstellt (vgl. Design Council 2021). Fragen zur konkreten Ausgestaltung der einzelnen Phasen im Entwicklungsprozess beantwortet das Framework allerdings nicht. Auch die Realisierung bzw. Anbindung an industriell anerkannte Vorgehensmodelle der Softwareentwicklung wird nicht weiter skizziert. Anwender müssen hier entsprechende Anpassungen vornehmen und Umsetzungsstrategien entwerfen.

EDAP-Framework

Das von Zuber et al. (2020) entwickelte EDAP-Schema sieht die Integration moralischer Aspekte in agile Softwareentwicklungsframeworks vor. EDAP steht für „Ethische Deliberation für agile Prozesse“. Dieses Framework stellt eine Systematisierung in acht Phasen dar und soll helfen, moralische Fragestellungen während des gesamten Entwicklungsprozesses zu berücksichtigen. Der Grundgedanke des EDAP-Schemas ist durchaus richtig, jedoch handelt sich hier um eine Lösung, die aus einem akademischen Kontext stammt: Ein Kritikpunkt, den Mittelstadt auch den Guidelines vorwirft (vgl. Mittelstadt 2019). Dies spiegelt sich hier vor allem in der Sprache wider. Die Beschreibung des EDAP ist stark von philosophischen Fachtermini (Deliberation, deskriptiv, deontologisch, konsequentialistisch etc.) geprägt, die eine gewisse Distanz zum Anwender hin aufbauen. Eine Anwendung im industriellen Kontext ist daher als schwerfällig einzuschätzen. Zudem ist das EDAP-Framework nicht intuitiv verständlich und einsetzbar. Ebenso bleibt es wenig konkret, wie genau es in anerkannten Vorgehensmodellen verwendet werden soll. Es werden lediglich moralische Fragestellungen aufgezeigt, welche in einer bestimmten Phase des Entwicklungsprozesses zu stellen sind. Wie sich die genaue Umsetzung der moralischen Fragen im Hinblick auf die zu entwickelnde Software gestaltet, bleibt offen.

Ethics Canvas Manual-Framework

Das Ethics Canvas Manual von Lewis et al. (2017) ist ein am Business Model Canvas orientiertes Framework „that can be part of the solution to the problems that ethics in research and innovation faces“. Es soll dabei unterstützen beim Brainstorming moralische Herausforderungen in einem Projekt zu identifizieren und passende Lösungen zu entwickeln. Positiv hervorzuheben ist hier, dass dieses Framework intuitiv verständlich und einsetzbar ist. Es baut auf einem im industriellen Kontext bekanntem wie bewährtem Framework auf. Das erleichtert den Gebrauch und baut Hemmschwellen ab. Eine kostenlose Download-Möglichkeit macht es den Nutzern leicht zugänglich. Jedoch verhält es sich hier ähnlich wie im oben vorgestellten Responsible-Design-Process-Framework, es bleibt auf der Ebene der initialen Konzeptionsphase stehen.

7000-2021 IEEE Standard Model Process for Addressing Ethical Concerns during System Design

Dieser Standard definiert einen konkreten Prozess, welcher eingesetzt werden kann, um in den Projektphasen „Initialisierung, Analyse und Software-Design“ ethische Werte zu berücksichtigen. Hierbei handelt es sich um eine unternehmensnahe Ausführung, in welcher u. a. auch Schlüsselrollen und der Prozess der Definition moralischer Anforderungen Berücksichtigung finden. Zu den Schlüsselrollen gehören u. a. ein Value Lead und ein User Advocate (vgl. IEEE 2021).

Zum Value Lead ist folgendes zu lessen: „The Value Lead is not the person in charge of ethics in a project but contributes subject matter expertice and facilitative skills bridging gaps between engineeres, management and ethical values in a constructive way.“ (IEEE 2021, S. 33) Für KMUs oder Start-ups könnte es schwierig bis nicht realisierbar sein, eine derartige Rolle, die über Fachwissen in Ethik erfordert, zu besetzen. Die Rolle läuft auch Gefahr, missverstanden zu werden: Verantwortlichkeit könnte an sie „ausgelagert“ werden, sodass in der Praxis tatsächlich eine „person in charge of ethics“ geschaffen wird. Die beschriebene Rolle des User Advocats, welche die Interessen der Anwender vertritt, ist grundsätzlich als wertvoll zu erachten. Allerdings sollte auch hier angestrebt werden, die Rolle nicht personell, sondern durch pragmatischen, rationalen wie empathischen Diskurs zwischen den Entwicklern im Prozess selbst zu verankern, nach dem Motto: Es betrifft jeden, nicht nur eine dazu berufene Person.

Der Prozess zur Definition moralischer Anforderungen geht im IEEE Standard von der Perspektive der Risikovermeidung aus. Die Motivation für das richtige Handeln wird hier also durch die Vermeidung des Risikos auf Bestrafung gestiftet (vgl. Kohlberg 1995). Die Autoren des vorliegenden Beitrags gehen über diese Motivation hinaus und definieren die moralischen Anforderungen etwa aus der Notwendigkeit für eine funktionierende Gesellschaft (vgl. Kohlberg 1995) und zu Gunsten des wirtschaftlichen Erfolgs.

3 Integration moralischer Anforderungen im Vorgehensmodell Scrum

Dieser Beitrag will folgende methodische Ansätze zusammen denken: Scrum bildet das übergeordnete Vorgehensmodell zur Entwicklung von Software bzw. KI-basierten Anwendungen. Innerhalb dieses Vorgehensmodells werden Ansätze der Diskursethik und Methoden aus dem UX-Design eingewoben um moralische Anforderungen im Entwicklungsprozess gezielt berücksichtigten zu können. Scrum, UX-Design und die DiskursethikFootnote 1 haben im Charakter gemeinsam, dass sie als besonders dynamisch im Umgang mit Anforderungen gelten und dahingehend angelegt sind, Lösungen im Gespräch über einen Konsens im Team herzustellen.

„Scrum ist ein Framework für das Management komplexer Projekte“ (Wirdemann 2016, S. 25) und gilt als das derzeit am meisten verbreitete agile Vorgehensmodell im industriellen Kontext (vgl. Tell et al. 2021). Der Entwicklungsprozess bei Scrum lässt sich im Kern in fünf Phasen unterteilen: Initialisierung, Sprint-Vorbereitung, Sprint-Planung, Sprint-Durchführung und Sprint-Review (in Anlehnung an Wirdemann 2016). Die einzelnen Phasen werden im Folgenden kurz skizziert und um spezifische Elemente zur Integration moralischer Anforderungen angereichert (Abb. 1). Die Anwendung an einem Praxisbeispiel veranschaulicht die Umsetzung. Dabei handelt es sich um eine mobile Tagebuch-App für Jugendliche im Alter von 14 bis 16 Jahren, die aktuell an der Hochschule Worms entwickelt wird. Ziel der Anwendung ist die Dokumentation von Tätigkeiten an projektbasierten Bildungsangeboten, die durch Sprachaufzeichnungen der Teilnehmer über einen Zeitraum von 12 Wochen festgehalten werden. Durch den Einsatz KI-basierter Algorithmen und Komponenten zur Sprachanalyse sollen Erkenntnisse über die Kompetenzentwicklung der Teilnehmer anhand von Veränderungen des Wortschatzes bezüglich des Wordings und der Fachterminologie gewonnen werden. Die App wird die Jugendlichen „begleiten“ und über Feedback-Mechanismen zusätzliche Motivationsimpulse und Anreize setzen.

Abb. 1
figure 1

Scrum-Phasen mit Anreicherung. (Eigene Darstellung)

Full size image

3.1 Projekt-Initialisierung

Framework

Scrum-Projekte starten mit einer Produktvision. Die Produktvision beschreibt die Ziele und Einsatzszenarien, den übergreifenden Geschäftswert für den Auftraggeber und die anvisierte Zielgruppe sowie die Differenzierungsmerkmale zu bereits etablierten Produkten auf dem Markt. Der Product-Owner analysiert und diskutiert diese Produktvision mit dem Auftraggeber, um ein Verständnis für die Produktanforderungen zu entwickeln. Durch gezielte Rückfragen, Workshops, Interviews und Feedbackschleifen werden Unklarheiten und Missverständnisse in der Kommunikation zwischen Auftraggeber und Product-Owner ausgeräumt. Die Anforderungen werden vom Product-Owner in Form von ersten User-Story-Entwürfen ausgearbeitet bzw. dokumentiert, priorisiert und ins Product-Backlog eingestellt. In User-Stories werden Anforderungen an eine Anwendung aus Sicht des Nutzers beschrieben. User-Stories sind per Definition zu Beginn vage Aussagen, eben Geschichten, die im Zuge des Entwicklungsprozesses konkretisiert, d. h. weiter ausgearbeitet werden. Sie haben u. a. die Aufgabe, die Kommunikation zwischen den Projektbeteiligten anzuregen und im aktiven Austausch die richtige Lösung für die Umsetzung einer Anforderung zu finden. Mit zunehmender Nähe zur Sprint-Planung müssen die hoch-priorisierten User-Stories mit am Projekt beteiligten Stakeholdern detailliert ausgearbeitet werden. Ziel der Phase ist ein initialisiertes und priorisiertes Initial-Backlog, mit dem das Entwickler-Team den ersten Sprint angehen kann (vgl. Wirdemann 2016).

Anreicherung

Der Product-Owner diskutiert bereits bei der Initialisierung des Projekts moralische Fragestellungen des geplanten Produkts mit dem Auftraggeber und leitet Anforderungen ab. Liegen beim Auftraggeber ethische Leitlinien vor, die unternehmensweit bzw. produktunabhängig zu berücksichtigen sind, fließen diese als Anforderungen unmittelbar in die Diskussion ein. Die bedeutende Rolle des Product-Owners, die sich im weiteren Entwicklungsprozess festigt, wird bereits bei der Initialisierung von Projekten ersichtlich. Ohne fundierte Kenntnis und Erfahrung in der Bearbeitung und Diskussion moralischer Fragestellungen kann der Product-Owner dieser Aufgabe nicht verantwortungsvoll nachkommen. Die dafür erforderlichen Fertigkeiten sind in der Ausbildung von IT-Fachkräften im Umgang mit Anforderungs- und Entwicklungsprozessen zu vermitteln und können in der Praxis von erfahrenen Fachkollegen im Team weitergegeben werden. Leider mangelt es bis heute an einer substanziellen Integration ethischer Methodenkenntnis in Bildung und Praxis. Ergebnisse und Festlegungen im Bereich moralischer Anforderungen sind Ergebnis eines rationalen, pragmatischen Diskurses der Beteiligten, die in Anlehnung an Stories im Scrum-Framework, als Moral-Stories festgehalten werden. Der Pflege der Kommunikationskultur gilt in Scrum-Projekten als wesentlich und begleitet das Projekt durch alles Phasen (vgl. Kuhlmann 1985). Ziel eines Diskurses ist ein Konsens, der in Scrum-Projekten auch als „commitment“ bezeichnet wird.

Praxisbeispiel

In unseren Praxisbeispiel ist dem Auftraggeber die gesellschaftliche Teilhabe von Menschen mit sprachlichem oder körperlichem Handicap wichtig. Das Unternehmen engagiert sich seit Jahren mit Spenden und Events an Schulen und Vereinen in Deutschland, die Inklusion fördern und begleiten. Eine Barrierefreiheit der eigenen Produkte ist dem Auftraggeber ein zentrales Anliegen. Hier soll es unter keinen Umständen zum Widerspruch mit der eigenen Unternehmensphilosophie kommen. Mit Bezug auf die KI-basierte Sprachanalyse bei Jugendlichen sind im Produkt gezielt moralische Anforderungen zu berücksichtigen, die über eigene Moral-Stories im Initial-Backlog dokumentiert werden. In der Diskussion zwischen Product-Owner und Auftraggeber spielen die Grenzen der Barrierefreiheit der geplanten Anwendung eine wichtige Rolle. Das Team einigt sich darauf, eine Tagebuch-App zu entwickeln, die es Kurs-Teilnehmern ermöglicht, Sprachaufzeichnungen über das Smartphone aufzunehmen, die durch KI-basierte Komponenten analysiert werden und den Anwendern ein Feedback über die Entwicklung ihres Wortschatzes im Verlauf von Bildungsangeboten geben. Jugendliche mit Handicap sollen in der Lage sein, diese Funktion der Tagebuch-App ohne Einschränkungen zu verwenden. Stumme Jugendliche können statt Sprachaufzeichnungen über eine Tastatur Texte eingeben, die ebenfalls ausgewertet werden. Jugendliche mit Migrationshintergrund können die Anwendung mit deutschen Sprachkenntnissen auf Level A2 des Gemeinsamen Europäischen Referenzrahmen für Sprachen nutzen. Für die KI-basierte Analyse von Sprachaufzeichnungen auf diesem Sprachniveau stehen aus Sicht des Auftraggebers ausreichend stabile KI-Algorithmen und -Komponenten zu Verfügung. Es ist nicht geplant, eigene Komponenten für die Sprachanalyse zu entwickeln oder Forschungsarbeiten zu initialisieren. Abstand nimmt der Auftraggeber in einer ersten Version der Tagebuch-App von der Idee, eine multilinguale Tagebuch-App zu entwickeln, die neben Deutsch weitere Sprachen unterstützt. Die Anforderungen werden vom Product-Owner wie folgt festgehalten und ins Initial-Backlog übertragen:

A. USER-STORY

Als Kurs-Teilnehmer möchte ich die Aufzeichnungs- und Auswertefunktion der Tagebuch-App verwenden, um die Weiterentwicklung meines IT-Wortschatzes im Laufe des IT-Bildungsangebots im Auge zu behalten.

  • Akzeptanzkriterien:

    • Sprachaufzeichnung kann gestartet und beendet werden

    • Sprachaufzeichnung stoppt automatisch, wenn keine Eingabe über das Mikrofon erfolgt und informiert Anwender

    • Benachrichtigung an Anwender über erfolgreiche Speicherung der Aufzeichnung

    • Anwender kann Sprachaufzeichnung abspielen, löschen oder freigeben

    • KI-basierte Analyse der Sprachaufzeichnung startet nach Freigabe durch Anwender

    • Feedback/Bericht über die Entwicklung des Wortschatzes an Teilnehmer im Kontext der gesammelten Aufzeichnungen

A.1 MORAL-STORY

Als Kurs-Teilnehmer mit Stummheit möchte ich die Aufzeichnungs- und Auswertefunktion der Tagebuch-App verwenden, um die Weiterentwicklung meines IT-Wortschatzes im Laufe des IT-Bildungsangebots im Auge zu behalten.

  • Akzeptanzkriterien:

    • Eingabe von Aufzeichnungen ist über eine Tastatur möglich

    • Die KI-basierte Analyse ist auf Textdaten anwendbar

A.2 MORAL-STORY

Als Kurs-Teilnehmer mit Migrationshintergrund und deutschen Sprachkenntnissen auf Level A2 des Gemeinsamen Europäischen Referenzrahmen für Sprachen (GER) möchte ich die Aufzeichnungs- und Auswertefunktion der Tagebuch-App verwenden, um die Weiterentwicklung meines IT-Wortschatzes im Laufe des IT-Bildungsangebots im Auge zu behalten.

  • Akzeptanzkriterien:

    • Die KI-basierte Auswertung funktioniert auch bei Grundkenntnissen von Anwendern in der Sprache Deutsch [Level A2 nach GER]

    • Aufzeichnung reagiert tolerant auf kurze Unterbrechung(en) der Sprachaufzeichnung [kein Abbruch bei Verzögerungen]

    • App leitet Sprachaufzeichnung bei Problemen mit der KI-basierten Auswertung an Lehrende zur manuellen Überprüfung weiter

A.3 MORAL-STORY

Als Kurs-Teilnehmer mit einem Handicap [Amnestische bzw. Anomische Aphasie] möchte ich die Aufzeichnungs- und Auswertefunktion der Tagebuch-App verwenden, um die Weiterentwicklung meines IT-Wortschatzes im Laufe des Bildungsangebots im Auge zu behalten.

  • Akzeptanzkriterien:

    • Aufzeichnung reagiert tolerant auf Unterbrechung(en) der Sprachaufzeichnung [kein Abbruch bei Verzögerungen]

    • App leitet Sprachaufzeichnung bei Problemen mit der KI-basierten Auswertung an Lehrende zur manuellen Überprüfung weiter

3.2 Sprint-Planung

Die Sprint-Planung vollzieht sich in zwei aufeinander folgenden Schritten, die im Folgenden als Sprint-Grob- und Sprint-Feinplanung bezeichnet werden. In der Planungsphase werden die Weichen für einen anschließenden Sprint gelegt, in dem vom Team selektierte und ausgearbeitet Stories durch die Entwickler implementiert werden.

3.2.1 Sprint-Grobplanung

Framework

Der Product-Owner stellt dem Entwicklerteam die für die Implementierung in Aussicht stehenden User-Stories im Product-Backlog vor. Alle Beteiligten sollen ein klares Verständnis der Anforderungen an das System bekommen und den damit verbundenen Aufwand einschätzen können. Die Priorität und Ausgestaltung der User-Stories werden vom Team diskutiert, angepasst, bestätigt oder verworfen. Ziel der Sprint-Planung ist die Entscheidung, welche Stories in ein Selected-Backlog aufgenommen, im anstehenden Sprint implementiert und an den Kunden ausgeliefert werden.

Anreicherung

Bei der Diskussion der Stories bzw. Moral-Stories sind moralische Anforderungen explizit als solche zu benennen oder herauszuarbeiten. Das Team muss sich auf die Diskussion moralischer Fragestellungen einlassen; klassische Softwareentwickler bringen zu Beginn nicht immer die notwendige Sensibilität und Aufmerksamkeit für moralische Fragestellungen mit. Es ist Aufgabe des Product-Owners, den Geschäftswert einer moralischen Anforderung aus Sicht des Kunden zu erläutern. Der Scrum-Master unterstützt den Prozess, indem er ggf. notwendige Aufmerksamkeit einfordert und im Nachgang Einzelgespräche mit Entwicklern führt.

Praxisbeispiel

Bei der Vorstellung der Moral-Stories werden im Team noch Unklarheiten bei der Festlegung von Handicaps und/oder Krankheiten ersichtlich, die über das Gespräch im Team aufgelöst werden. Im Praxisbeispiel bestehen Unklarheiten bzgl. der Anforderungen an die deutschen Sprachkenntnisse auf Level A2 des Gemeinsamen Europäischen Referenzrahmen für Sprachen. Weiterhin ist das Handicap Amnestische bzw. Anomische Aphasie im Team unbekannt. Über den persönlichen Austausch mit zertifizierten Sprachlehrern und der thematischen Auseinandersetzung mit dem Handicap Aphasie können Unklarheiten beseitigt und Empathie für die Bedürfnisse der späteren Anwender aufgebaut werden.

3.2.2 Sprint-Feinplanung

Framework

Das Team führt einen Design-Workshop durch und erarbeitet für die ausgewählten Stories der Sprint-Grobplanung notwendige Domain‑, System, Architektur‑, Daten- und Verhaltensmodelle. Das Systemdesign entsteht iterativ. Ziel ist es, notwendige Bauanleitungen für die Implementierung durch die Entwicklung zu fertigen. Begleitend werden Stories vom Team in einzelne Aufgabenpakete (Tasks) zerlegt, die von den Entwicklern im Sprint implementiert werden (vgl. Wirdemann 2016).

Anreicherung

Für die Feinplanung ergeben sich mit Blick auf ethische Implikationen keine zusätzlichen Elemente. Das Team hat sich über die Grobplanung auf die Implementierung selektierter Moral-Stories „committed“; die Anforderungen und ihre Bedeutung für die Anwendung wurden (aus-)diskutiert. Entstehen während der Implementierung weitere Detailfragen, sind diese in den täglichen Teammeetings (Daily-Scrum) zu klären. Das grundsätzliche in Frage stellen von Moral-Stories ist in dieser Phase fehl am Platz, behindert den Erfolg des Entwicklungsprozesses und führt ggf. zum Abbruch des aktuellen Sprints. Eine entsprechende Aufarbeitung ist Diskussionsgegenstand der Sprint-Retroperspektive.

3.3 Sprint-Durchführung

Framework

In der Sprint-Durchführung setzt das Team selbstorganisiert (nach dem Pull-Prinzip) die im Sprint-Backlog festgehaltenen Stories um. Im Daily-Scrum-Meeting tauscht sich das Team täglich aus. Der Product-Owner steht während der gesamten Durchführung als Ansprechpartner und Repräsentant des Kunden zur Verfügung. Ist eine Story nach den vorher definierten Kriterien fertig (Definition-of-Done), kann sie jederzeit durch den Product-Owner abgenommen werden. Am letzten Tag des Sprints findet das Sprint-Review statt. Der Sprint wird damit beendet, dass das Team seine Ergebnisse vor einem größeren Kreis an Interessierten und Beteiligten des Projekts präsentiert. Hierbei soll ein Feedback von den am Entwicklungsprozess unbeteiligten, aber für das Projekt relevanten Personenvertretern, wie dem Kunden oder potenziellen Nutzern, eingeholt werden (vgl. Wirdemann 2016).

Anreicherung

Der während der Sprint-Durchführung anwesende Product-Owner hat ein besonderes Augenmerk auf die Moral-Stories. Diese werden im Daily-Scrum neben den allgemeinen Stories besprochen und Details erarbeitet. Der Product-Owner ruft die Wichtigkeit der Moral-Stories durch folgende Fragen ins Bewusstsein, die er mit dem Scrum-Team durchgeht:

  1. 1.

    Was habe ich bei den Moral-Stories seit dem letzten Daily-Scrum erreicht?

  2. 2.

    Was plane ich bei den Moral-Stories bis zum nächsten Daily-Scrum umzusetzen?

  3. 3.

    In meinen nächsten Moral-Stories halte ich es für „richtig“ (gemeint ist moralisch richtig), es so und so umzusetzen. Was haltet ihr davon?

  4. 4.

    Gab es etwas, dass ich nicht verstanden habe oder wo ich Hilfe benötige?

Die Diskussion der Moral-Stories im Daily-Scrum-Meeting verbindet Scrum mit Diskursethik. Es wird nicht von vorneherein festgesetzt, was richtig oder falsch ist. Was moralisch richtig ist, wird im Diskurs festgelegt. Mit Frage 3 wird hier bewusst etwas von den Daily-Scrum Regeln abgewichen. Hier geht es darum, dass sich das Team kurz und prägnant austauscht. Die Aufgabe des Scrum-Masters ist es, den Diskurs jedoch kurz und bei der entsprechenden Moral-Story zu halten. Ausufernde moralische Grundsatzdiskussionen sollten unterbunden werden, denn sie führen von der Sache weg. Der Product-Owner nimmt die Moral-Stories ab, wenn diese gemäß ihrer Defintion-of-Done erfüllt sind. Beim Sprint-Review werden dem öffentlichen Kreis auch die umgesetzten moralischen Anforderungen vorgestellt. Hier empfiehlt es sich, den Personenkreis für weitere Vertreter zu öffnen, welche die Diversität der Gesellschaft repräsentieren. Geht es um die Entwicklung KI-basierter Anwendungen eröffnet sich hierdurch u. a. die Möglichkeit noch nicht berücksichtigte Biases zu identifizieren.

Praxisbeispiel

In unserem Praxisbeispiel benötigt das Scrum-Team am Anfang noch etwas Hilfe bei der Diskussion der Moral-Stories. Verläuft der Diskurs bei Frage 3 noch etwas zögerlich, stellt der Scrum-Master ergänzende Fragen wie etwa: Wie würde ein Nutzer mit sprachlichem Handicap mit dieser Lösung zurechtkommen? Im Sprint-Review sind neben dem Auftraggeber zukünftige Anwender mit sprachlichem oder körperlichem Handicap anwesend. Sie können auf spielerische Weise bestimmte Funktionen ausprobieren und geben dem Team unmittelbar und erlebbares Feedback.

3.4 Sprint-Retrospektive

Framework

In Anlehnung an den Gedanken der kontinuierlichen Verbesserung dient die Retrospektive dazu, den Entwicklungsprozess und die Zusammenarbeit in der Sprint-Durchführung zu reflektieren und Aktionen für den nächsten Sprint abzuleiten. Der Scrum-Master moderiert die Retrospektive, die aus vier Einheiten besteht: Daten sammeln, Einsichten gewinnen, Entscheidungen treffen, Ziele formulieren sowie Aktionen planen (vgl. Wirdemann 2016).

Alternativ zur Durchführung allgemeiner Retrospektiven können von Zeit zu Zeit themenorientierte Retrospektiven durchgeführt werden, deren Ziel die Analyse und Verbesserung eines ganz konkreten Themas sind. (Wirdemann 2016, S. 218)

Anreicherung

Sind moralische Anforderungen neu für ein Sprint-Team, empfiehlt es sich, eine thematische Retrospektive mit diesem Fokus abzuhalten. Dies hilft dem Team sich in dem neuen Gebiet besser zurechtzufinden. Die vier Phasen sind entsprechend gestaltet:

  • Phase 1 – Daten sammeln: Daten werden gesammelt und an einer Timeline festgehalten. Folgende Fragen sollen dem Team helfen, das Projekt noch einmal mit der „ethischen Brille“ durchzugehen.

    • Welche Moral-Stories wurden umgesetzt?

    • Welche Moral-Stories sind liegengeblieben?

    • Was hat hinsichtlich Ethik genervt?

    • Was hat hinsichtlich Ethik begeistert?

    • Was war hinsichtlich Ethik neu?

    • Gab es ein besonderes Learning?

  • Phase 2 – Einsichten gewinnen: Wie in der allgemeinen Sprint-Retrospektive werden auch hier nun die Notizen von der Timeline in eine Positiv-Liste (So wollen wir weitermachen) und eine Delta-Liste (Entwicklungsmöglichkeiten) überführt (vgl. Wirdemann 2016).

  • Phase 3 – Entscheidungen treffen: Hier werden ebenfalls wie in der allgemeinen Retrospektive die einzelnen Punkte auf der Delta-Liste mit Hilfe eines Dot-Votings priorisiert (vgl. Wirdemann 2016).

  • Phase 4 – Ziele formulieren und Aktionen ableiten: Die Ziele und Aktionen werden positiv, realistisch und messbar formuliert (vgl. Wirdemann 2016).

Praxisbeispiel

In unserem Praxisbeispiel hat das Team insgesamt drei themenorientierte Sprint-Reviews durchgeführt, die sich mit den moralischen Implikationen befasst haben. Als Beispiel wird hier ein kurzer Einblick in das erste themenorientierte Sprint-Review gegeben. Hierbei wurde in Phase 1 und 2 festgestellt und in Phase 3 priorisiert, dass es den Entwicklern noch schwerfällt, die Bedürfnisse der Zielgruppe der „Jugendlichen mit Handicap“ richtig zu verstehen, um dann Entsprechendes auch umsetzen zu können. Daher wurde in Phase 4 sodann die Aktion geplant, drei Vertreter der Zielgruppe zu interviewen und daraus Personas abzuleiten, die den Entwicklern ein besseres Verständnis ermöglichen sollen (vgl. Jacobsen et al. 2019).

4 Evaluation

Das vorgestellte Vorgehensmodell wurde am Projektende mit Hilfe zweier kurzer Fragebögen evaluiert. Hierzu wurde das achtköpfige Scrum-Team sowie der Auftraggeber in jeweils zwei separaten Fragebögen befragt.

Die Befragung des Scrum-Teams zielte darauf ab, wie es mit dem angereichertem Vorgehensmodell zurechtkam. Im Ergebnis ist das Team gut bis sehr gut mit dem Vorgehensmodell zurechtgekommen. Auf die Frage „Hätten Sie ohne die Begleitung durch den Product-Owner und den Scrum-Master soziale und moralische Aspekte im Rahmen des Projektes überhaupt berücksichtigt?“ antworteten sieben Personen mit „vielleicht“ und eine Person mit „nein“. Dies Rückmeldung belegt in erster Näherung, dass die eingeführten Elemente dazu beitragen können, moralische Anforderungen im Entwicklungsprozess in den Blick zu nehmen und gezielt zu berücksichtigen.

Bei der Befragung des Auftraggebers stand das Gesamtergebnis im Vordergrund, d. h. wie zufrieden er mit der Lösung war und ob er die Umsetzung der moralischen Anforderungen für gelungen hält. Der Auftraggeber war zufrieden und denkt, dass die Lösung durch die Integration moralischer Aspekte erfolgreicher sein wird, als wenn diese nicht berücksichtigt worden wären.

Um das vorgestellte Vorgehen auszubauen und kontinuierlich zu verbessern, sollen im Rahmen der zukünftigen Projekte qualitative Interviews als zusätzliches Evaluationsinstrument dienen. Die Autoren versprechen sich dadurch tiefere Einsichten zur gezielten Berücksichtigung moralischer Anforderungen in industriell anerkannten Vorgehensmodellen.

5 Zusammenfassung und Ausblick

Facebook-Algorithmus verwechselt schwarze Menschen mit Affen – Der Social-Media-Riese hat Probleme mit der Künstlichen Intelligenz: Wer einen Clip über einen rassistischen Vorfall in den USA sah, bekam mehr „Videos über Primaten“ vorgeschlagen. Facebook entschuldigt sich. (Spiegel Online 2021)

Bei der Entwicklung KI-basierter Anwendungen passieren kontinuierlich Fehler, wie oben zitiertes Beispiel aus DER SPIEGEL aufzeigt. Auf diese Weise entstehende Imageschäden können groß sein und werden in der Presse diskutiert. Im Facebook-Beispiel wurde der Algorithmus sofort eingestellt und eine Unternehmenssprecherin entschuldigte sich für einen „eindeutig inakzeptablen Fehler“ (vgl. Spiegel Online 2021).

Eine Möglichkeit solchen Schäden besser vorzubeugen, besteht darin, moralische Anforderungen im Software-Entwicklungsprozess von Anfang an zu berücksichtigen. Im vorliegenden Beitrag konnte aufgezeigt werden, wie sich dies im industriell anerkannten Vorgehensmodell Scrum umsetzen lässt: Die einzelnen Phasen von Scrum wurde so angereichert, dass moralische Aspekte u. a. in Form von Moral-Stories mit entsprechenden Akzeptanzkriterien Eingang finden. Vorgesehene Diskussionen und Retroperspektiven begleiten den Prozess.

Damit ein Entwicklerteam vor Projektbeginn die vorgestellten Elemente lernen und einüben kann, wurde eine 120-minütige Ethik-Scrum-Schulung mit Gamification Elementen entwickelt. Hierbei wurde das beliebte Simulationsspiel von Alexey Krivitsky Lego4Scrum entsprechend modifiziert (vgl. Krivitsky 2011).

Berücksichtigt ein Unternehmen moralische Aspekte in der Softwareentwicklung, so könnte dies auch zu einer Steigerung der Arbeitgeberattraktivität beim Kampf um junge Talente führen. Die zukünftige Generation von Fachkräften wird einer moralisch-sinnvollen Ausgestaltung ihrer Tätigkeit, die sich dann in Produkten und Dienstleistungen manifestiert, zunehmend mehr Beachtung schenken. Der rein monetäre Aspekt beruflicher Selbstverwirklichung wird sich zunehmend um Aspekte von Achtsamkeit, Resonanz und Nachhaltigkeit erweitern (vgl. Zenjobs 2021).

In Rahmen weiterer Untersuchungen ist der vorgestellte Ansatz detaillierter auszuarbeiten und in der Praxis zu erproben und zu evaluieren. Die Handlungsempfehlungen der im Beitrag vorgestellten Guidelines und Frameworks sollen dabei systematisch in den eigenen Ansatz einbezogen werden.