Reifegradmodelle für Agile Methoden. Notwendigkeit und Erfolgsfaktoren der Entwicklung

Inhaltsverzeichnis

Danksagung

Abstrakt

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1. Einleitung
1.1. Einführung in das Thema
1.2. Problemstellung und Zielsetzung
1.3. Methodische Vorgehensweise

2. Reifegradmodelle
2.1. Einführung zu Reifegradmodellen
2.1.1. Der Modellbegriff
2.1.2. Abbildungsorientierter Modellbegriff
2.1.3. Konstruktionsorientierter Modellbegriff
2.1.4. Reifegrad und Reifegradmodelle - Definitionen
2.1.5. Charakteristika von Reifegradmodellen
2.2. CMMI - Capability Maturity Model Integration
2.2.1. Einführung in CMMI
2.2.2. Modelle und Grundstruktur von CMMI (v1.3)
2.2.3. Prozessgebiete und Komponenten von CMMI for Development (V1.3)
2.2.4. Fähigkeits- und Reifegrade im CMMI for Development (v1.3)
2.2.5. Einstufung eines Prozessgebietes
2.2.6. Ziele und Kritik

3. Agile Vorgehensweisen
3.1. Das Agile Manifest
3.2. Agile Prinzipien
3.3. Scrum – Ein Rahmenwerk
3.3.1. Einführung in Scrum
3.3.2. Rollen in Scrum
3.3.3. Artefakte von Scrum
3.3.4. Ereignisse in Scrum

4. Agile Reifegradmodelle
4.1. Agile Reifegradmodelle in der Theorie
4.2. Aktueller Stand der Forschung

5. Methodische Vorgehensweise
5.1. Auswahl der Forschungsmethode
5.1.1. Quantitative Forschung
5.1.2. Qualitative Forschung
5.1.3. Entscheidung über die Forschungsmethode
5.2. Experteninterview
5.2.1. Auswahl der Interviewpartner
5.2.2. Ausarbeitung des Interviewleitfadens
5.2.3. Durchführung der Interviews
5.2.4. Auswertung der Ergebnisse
5.2.5. Maßnahmen zur Qualitätssicherung der Ergebnisse

6. Darstellung der Ergebnisse
6.1. Zusammenfassung der Ergebnisse
6.2. Darstellung der Ergebnisse im Detail
6.2.1. Entwicklung von Reifegradmodellen in den letzten Jahren
6.2.2. Probleme und Herausforderungen bei der Einführung von Reifegradmodellen
6.2.3. Entwicklung der Anwendung von Agilität
6.2.4. Probleme und Herausforderungen bei der Einführung von Agilität
6.2.5. Notwendigkeit eines agilen Reifegradmodelles
6.2.6. Chancen und Risiken eines agilen Reifegradmodelles
6.2.7. Herausforderungen in der Entwicklung eines agilen Reifegradmodelles
6.2.8. Erfolgsfaktoren der Entwicklung eines agilen Reifegradmodelles
6.2.9. Möglichkeiten der Entwicklung eines agilen Reifegradmodelles
6.3. Zusammenfassende Aussagen der Experten zum Thema

7. Fazit, Handlungsempfehlungen und Limitierungen
7.1. Fazit
7.2. Handlungsempfehlungen
7.3. Limitierungen

Literaturverzeichnis

Anhang

Glossar

Danksagung

Ein Fernstudium neben dem Vollzeitjob erfolgreich abzuschließen ist schwer, wenn die nötige Unterstützung fehlt. Deshalb will ich zunächst einigen Personen danken.

Ich danke meinen Kolleginnen und Kollegen in der IT-Abteilung der Firma Völkl Sports GmbH, die immer ein offenes Ohr haben und auf die man sich jederzeit verlassen kann.

Danke an Dr. Mark Menzel für die Betreuung meiner Abschlussarbeit. Er hatte oft wichtige und hilfreiche Anmerkungen und begleitete die Arbeit stets mit einem offenen Ohr für Fragen. Weiterhin danke ich Dr. Bernhard von Guretzky, der die Arbeit als Zweitgutachter prüfte.

Ich danke den Experten, die sich für ein Interview zum Thema bereit erklärten. Herr S., Herr A. und Herr M. (sowie seine Kollegen) haben mir mit ihren konstruktiven und ausführlichen Meinungen und Erklärungen sehr bei der Erstellung dieser Arbeit weitergeholfen. Vielen Dank.

Weiterhin bedanke ich mich bei allen Korrekturlesern dieser Arbeit, die mir mit ihren Anmerkungen und Kommentaren wichtige Hinweise auf Verbesserungen gegeben haben.

Abschließend danke ich meinen Eltern und meiner Familie, ohne die ich nicht wäre, wer ich bin. Außerdem danke ich allen, die mich während der Studienzeit moralisch unterstützt haben und mich auf dem Weg zu dieser Abschlussarbeit begleitet haben.

Abstrakt

Agilität konnte in den vergangenen Jahren stetig an Bedeutung in Unternehmen gewinnen. Zuvor war lange Jahre die stetige Prozessoptimierung im Rahmen einer Bewertung mit Reifegradmodellen ein entscheidender Erfolgsfaktor. Aus der zunehmenden Beliebtheit agiler Vorgehensweisen lässt sich schließen, dass diese Erfolgsgeschichte auch in den folgenden Jahren anhalten wird. Nach aktuellem Forschungsstand sind wenige Modelle vorhanden, die die agile Reife eines Unternehmens messen und Empfehlungen für eine Verbesserung im Bereich der Agilität geben.

Diese Arbeit beschäftigt sich dementsprechend mit der Ermittlung der Notwendigkeit eines Reifegradmodelles für agile Methoden und versucht, erste Erfolgsfaktoren für die Entwicklung eines solchen Modelles herauszuarbeiten. Hierfür wurden qualitative Experteninterviews durchgeführt. Die Ergebnisse der Interviews bestätigen die Zunahme von Agilität in Unternehmen in den letzten Jahren und stellen dar, dass grundsätzlich die Notwendigkeit eines Reifegradmodelles für Agilität gegeben ist. Mögliche Erfolgsfaktoren sind eine Standardisierung des Modelles das Schaffen von Vergleichbarkeit zwischen Unternehmen. Es wird dennoch empfohlen, in weiteren Studien das Interesse von betroffenen Personengruppen zu ermitteln, da sich ein Modell nur durchsetzen kann, wenn ein breites Interesse vorhanden ist.

Schlüsselbegriffe: Reifegradmodell - Vorgehensmodell - CMMI - Agiles Manifest -

Agile Methoden - Scrum - Agiles Reifegradmodell

Abstract

In the last years, the importance of agility in companies increased. Before that, a continuous process-improvement by implementing maturity models has been a decisive factor of success. The increasing popularity of agility concludes that this story of success will remain in the next years. At this point of research, there are few models that can be used to measure the maturity of agility or give recommendations to improve it.

This thesis tries to determine whether a maturity model for agility is needed. It further tries to work out factors of success for the development of such a model. For this reason, qualitative research in form of expert interviews has been made. The results of this research are the confirmation that agility in companies increased over the last few years and that there is a need of a maturity model for agility in principle. Potential success factors are a standardization of the model as well as the creation of comparability between different companies. Another critical factor of success is the acceptance of the model in a wider audience. Therefore, further researches should determine the general interest in a maturity model for agility.

Keywords: Maturity model - Procedure model - CMMI - Agile Manifesto -

Agile methods - Scrum - Maturity model for agile Methods

Abbildungsverzeichnis

Abbildung 1: Zeit im Markt der Musikdistribution

Abbildung 2: Modelle von CMMI in der Version v1.3

Abbildung 3: Komponenten von CMMI-DEV

Abbildung 4: Darstellung von Fähigkeitsgraden in CMMI-DEV

Abbildung 5: Darstellung der Reifegrade in CMMI

Abbildung 6: Die Werte Agiler Softwareentwicklung

Abbildung 7: Der Scrum-Prozess im Überblick

Abbildung 8: Darstellung des "Cone of Uncertainty"

Abbildung 9: Themes, Epics und User Stories in Scrum

Abbildung 10: Kategorien von User Stories in Scrum

Abbildung 11: Leitfaden für das Interview mit Herr S. (Seite 1)

Abbildung 12: Leitfaden für das Interview mit Herr S. (Seite 2)

Abbildung 13: Leitfaden für das Interview mit Herr A. (Seite 1)

Abbildung 14: Leitfaden für das Interview mit Herr A. (Seite 2)

Abbildung 15: Leitfaden für das Interview mit Herr M. (Seite 1)

Abbildung 16: Leitfaden für das Interview mit Herr M. (Seite 2)

Abbildung 17: Unterschriebene Einverständniserklärung von Herr S.

Abbildung 18: Unterschriebene Einverständniserklärung von Herr A.

Abbildung 19: Unterschriebene Einverständniserklärung von Herr M.

Abbildung 20: Nachträglicher Kommentar von Herr M. bei der Überprüfung

Tabellenverzeichnis

Tabelle 1: Erfolgsquote von Softwareprojekten (aus The Standish Group, CHAOS Report, 2015)

Tabelle 2: Anfrage von Schlüsselbegriffen in Google Scholar

Tabelle 3: Darstellung der Anzahl von Reifegraden verschiedener Modelle

Tabelle 4: Auszug aus den Prozessgebieten des CMMI-DEV (v1.3)

Tabelle 5: Darstellung von Fähigkeitsgraden und Reifegraden in CMMI

Tabelle 6: Zu erfüllende Prozessgebiete für CMMI-Reifegrad 2 (Managed)

Tabelle 7: Generische Ziele und generische Praktiken in CMMI-DEV

Tabelle 8: Generisches Ziel GG 1 am Beispiel von Prozessgebiet Project Planning (PP)

Tabelle 9: Chancen und Risiken eines Agilen Reifegradmodelles

Tabelle 10: Übersetzungstabelle der zitierten Passagen in Fremdsprache

Tabelle 11: Alle Prozessgebiete von CMMI-DEV mit Kategorie und Reifegrad

Tabelle 12: Generisches Ziel GG 2 am Beispiel von Prozessgebiet Project Planning (PP)

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1. Einleitung

Zu Beginn dieser Arbeit soll eine kurze Einführung in das Thema erfolgen. Dabei wird vor allem auf die veränderte Marktsituation in den letzten Jahren und die Folgen für Unternehmen eingegangen. Es folgt eine Beschreibung der Problemstellung und der Zielsetzung der Arbeit, ehe abschließend ein Überblick über das methodische Vorgehen gegeben wird.

1.1. Einführung in das Thema

Unternehmen stehen in der heutigen Zeit vor neuen Herausforderungen wie dem globalen Wettbewerb und kürzeren Lebenszyklen von Produkten und Dienstleistungen. Neben dem immer weiter fortschreitenden technologischen Wandel führt vor allem auch ein Wandel im Bewusstsein der Kunden¹ dazu. Das Bewusstsein und Verhalten der Kunden verändert sich in den letzten Jahren deutlich und vor allem in kürzerer Zeit in verschiedenste Richtungen.² Die Folge dieser Entwicklungen für Unternehmen ist kritisch. Die Adoptionszeit³ verkürzt sich, was wiederum in einem geringeren Window of Opportunity resultiert. So bleibt Firmen weniger Zeit, um auf Veränderungen zu reagieren. Eine weitere Folge ist die Verkürzung von Lebenszyklen von Produkten und Dienstleistungen wie in Abbildung 1 am Beispiel des Marktes der Musikdistribution sichtbar ist. ⁴

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Zeit im Markt der Musikdistribution

In digital bestimmten Märkten kommt zu den oben genannten Veränderungen eine weitere Schwierigkeit hinzu. Es ist zu beobachten, dass dort in Bezug auf die Marktposition das Prinzip „The Winner takes it all“ herrscht. Der Marktführer besitzt einen signifikant höheren Marktanteil als die anderen Marktteilnehmer. Zum Teil liegt bereits ab der dritten Position der Marktanteil unter der wirtschaftlich kritischen Grenze, was in der Folge oft zu Marktaustritten führt. In traditionellen Märkten ist diese Entwicklung noch nicht angekommen, dennoch ist es ratsam zu handeln anstatt zu warten.⁵

Um in Märkten mit den oben genannten Einflussfaktoren bestehen zu können lässt sich ableiten, dass Unternehmen reaktionsfähig und innovativ bleiben müssen. Einer der Erfolgsfaktoren dafür ist die Agilität, die in den vergangenen Jahren einen stetigen Zuwachs an Interesse gewinnen konnte.

Agilität wird dabei „allgemein verstanden als die höchste Form der Anpassungsfähigkeit einer Organisation“ (Olbert, S. et. al., 2019, S. 100).

Bereits in den 70er und 80er Jahren war Tom Peters⁶ der Meinung, dass die Anpassungsfähigkeit einer Organisation ein Wettbewerbsvorteil ist. Große Popularität erlangte der Begriff Agilität im Zusammenhang mit dem Agilen Manifest für Softwareentwicklung. Seither ist ein wachsendes Interesse in sämtlichen Unternehmensbereichen zu beobachten.⁷

Vor allem aber in der Softwareentwicklung haben agile Vorgehensweisen mittlerweile großflächigen Einzug gefunden. Die Ergebnisse der Studie Status Quo Agile, bei der über 1000 Teilnehmer befragt wurden, belegen dies. So gaben 82% von 720 Befragten an, dass sie im Bereich der Softwareentwicklung auf agile Methoden zurückgreifen.⁸

Die Standish Group beziffert im CHAOS Report 2015 den Erfolg von Softwareprojekten mit Anwendung agiler Methoden bei 39%. Das klassische Wasserfallmodell kann bei Projekten aller Größen (über 10 000 Projekte wurden zwischen 2011 und 2015 berücksichtigt) einen Erfolg von 11% aufweisen. Doch auch wenn agile Methoden erfolgreicher als klassische Modelle scheinen, weist auch hier der Großteil der Projekte (52%) Schwierigkeiten auf oder es kommt zu Verzögerungen.⁹

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Erfolgsquote von Softwareprojekten (aus The Standish Group, CHAOS Report, 2015)

Der jährliche State of Agile Report von CollabNet und VersionOne führt auf, dass bei 74% der Befragten über die Hälfte der durchgeführten Projekte mit agilen Methoden erfolgreich waren (Vgl. VersionOne, 2017, S.11).

Das Agile Manifest wurde, wie bereits erwähnt, primär für die Softwareentwicklung verfasst. Wie die zuvor bereits zitierte Studie Status Quo Agile auch beweist, werden Agile Vorgehensweisen hauptsächlich dort angewandt. Trotzdem erfolgt die sukzessive Adaption in IT-ferne Bereiche.¹⁰

Lange vor der Popularität agiler Methoden haben sich Reifegradmodelle in diversen Domänen etabliert. Der Erfolg begann mit der Einführung des Capability Maturity Model im Jahr 1991, dessen Ursprünge ebenfalls in der Softwareentwicklung liegen. Es konnte sich jedoch in anderen Branchen ebenso etablieren.¹¹

1.2. Problemstellung und Zielsetzung

Lange galt die Prozessoptimierung in diversen Bereichen als erstrebenswert, wie durch die zunehmende Anwendung von Reifegradmodellen belegt wird. Reifegradmodelle dienten Organisationen dazu, ihre eigenen Prozesse zu analysieren und durch eine sukzessive Erhöhung des Reifegrades zu optimieren, was gleichzeitig das Ziel der Anwendung darstellte.¹² Unternehmen und deren Geschäftspartner hatten belastbare Beweise über die Produktivität und Qualität der Prozesse und konnten so erste Schlüsse auf die Qualität der Ergebnisse ziehen (dies entspricht im weiteren Sinn dem Grund für die Entwicklung des Capability Maturity Model).¹³

Durch die in der vorherigen Einführung genannten Einflussfaktoren auf Unternehmen scheint sich der Fokus vom Prozess jedoch in Richtung Produkt und Kunde abgewendet zu haben. Um innovativ zu bleiben, scheinen festgefahrene Prozesse das falsche Mittel zu sein, was den agilen Vorgehensweisen ihren Weg zum Erfolg ebnete. Wie später noch detaillierter beschrieben wird, ist einer der agilen Werte das Reagieren auf Veränderung statt Befolgen eines Plans.¹⁴ Bedeutet dies, das Organisationen die agile Methoden anwenden schlicht keinen Plan haben? Oder hat deren Plan weite Grenzen, innerhalb derer sich die Prozesse bewegen?

Beide beschriebenen Vorgehensweisen haben jeweils Vor- und Nachteile. Bei Reifegradmodellen steht die Standardisierung im Fokus, welche dazu dienen soll, Fähigkeiten von Organisationen vergleichen zu können. Grundsätzlich sind diese Modelle daher eher als starr anzusehen.

Agile Vorgehensweisen dagegen sind flexibler und bieten eine bessere Reaktionsfähigkeit auf geänderte Gegebenheiten. Eine Messung und Vergleichbarkeit scheint hier jedoch schwierig zu sein.

Es stellt sich die Frage, ob es deshalb sinnvoll ist, die Komponenten zu kombinieren und eine Art Agiles Reifegradmodell zu entwickeln. Bisher scheint noch kein solches Modell eine breitere Verwendung gefunden zu haben, was auch bedeutet, dass viele Organisationen zwar agil arbeiten, ihren Reifegrad und Erfolg bei der Anwendung agiler Methoden jedoch nicht messen können.

Diese Arbeit soll sich deshalb mit der folgenden Leitfrage befassen: Ist es notwendig, ein Reifegradmodell für agile Methoden zu entwickeln?

Aussagen und Antworten zu dieser Leitfrage sollen anschließend begründet werden. So sollen beispielsweise auch potenzielle Erfolgsfaktoren von agilen Reifegradmodellen ermittelt werden.

1.3. Methodische Vorgehensweise

Bisher scheinen agile Reifegradmodelle wenig erforscht. Dies machte auch eine Anfrage in Google Scholar deutlich, welches mit Stand 04.01.2019 folgende Anzahl an Ergebnissen liefert:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Anfrage von Schlüsselbegriffen in Google Scholar

Der Erfolg und das Maß der Anwendung agiler Vorgehensweisen lassen sich nach dem derzeitigen Stand der Forschung somit schwer messen.

Bevor jedoch mit der zu erwartenden zeit- und ressourcenintensiven Entwicklung eines solchen Modells begonnen wird, sollte die Frage nach der Notwendigkeit beantwortet werden. Es ist naheliegend eine solche fundamentale Frage mithilfe von Experten zu beantworten. Mit deren Fachwissen sollen auch mögliche Erfolgsfaktoren eruiert werden, die den Erfolg von agilen Reifegradmodellen unterstützen können.

Die vorliegende Bachelorarbeit kann dementsprechend in drei Teile gegliedert werden:

Im ersten Teil wird eine Literaturanalyse durchgeführt. Zunächst werden Modelle im Allgemeinen und Reifegradmodelle im Speziellen erläutert. Als konkretes Beispiel wird dabei auch detailliert auf CMMI, in der Literatur als de-facto-Standard geführt, eingegangen. Ähnlich wird im Anschluss mit Agilen Methoden verfahren. Es erfolgt eine Einführung in agile Vorgehensweisen und zur Veranschaulichung wird als Beispiel das Rahmenwerk Scrum, ebenfalls de-facto-Standard, detailliert vorgestellt.

Um einen Überblick über den aktuellen Forschungsstand in Bezug auf agile Reifegradmodelle zu erhalten werden die Gemeinsamkeiten und Widersprüche in der Theorie erläutert. Es erfolgt ebenso eine kurze Vorstellung bereits existierender Reifegradmodelle für Agile Vorgehensweisen.

Im zweiten Teil wird die Vorgehensweise bei der Datenerhebung dargestellt. Dabei wird auf qualitative und quantitative Forschungsmethoden eingegangen, die Entscheidung für die gewählte Methode erläutert und der Prozess der Durchführung beschrieben.

Im dritten und letzten Teil werden die Ergebnisse der Expertenbefragungen ausgewertet. Es erfolgt eine Präsentation der Kernaussagen und ein Fazit der Befragungen. Außerdem sollen abschließend Handlungsempfehlungen für zukünftig zu erforschende Fragestellungen gegeben werden.

2. Reifegradmodelle

In der Einführung wurde die Prozessoptimierung mit Reifegradmodellen genannt. In diesem Kapitel soll nun eine detaillierte Beschreibung zu Modellen im Allgemeinen und zu Reifegradmodellen im Speziellen erfolgen. Dazu wird der de-facto-Standard der letzten Jahre detailliert beschrieben. Dies ist das Capability Maturity Model Integration (CMMI).

2.1. Einführung zu Reifegradmodellen

Bevor auf den speziellen Typ des Reifegradmodelles eingegangen wird, soll ein allgemeines Begriffsverständnis geschaffen werden. Zuerst soll daher der Modellbegriff an sich erläutert werden, ehe auf zwei verschiedene Modellverständnisse eingegangen wird. Hier erfolgt auch der Übergang zum Begriff Reifegradmodell.

2.1.1. Der Modellbegriff

Der Begriff Modell wird in der Literatur häufig verwendet, seine Definition ist jedoch sehr uneinheitlich. Der allgemeine Modellbegriff hat gemäß Stachowiak drei konstituierende Merkmale:

- Abbildungsmerkmal: Modelle repräsentieren natürliche oder künstliche Originale. Dabei spielt es keine Rolle, ob das Original natürlich, künstlich hergestellt oder auf sonstigen Wegen gegeben ist. Das Modell steht mit dem Original in einer Abbildungsrelation.
- Verkürzungsmerkmal: Nicht alle Attribute des repräsentierten Originals werden auch auf das Modell abgebildet, sondern nur diejenigen, die dem Ersteller bzw. den Verwendern des Modelles als relevant erscheinen.
- Pragmatisches Merkmal: Ein Modell ist dem Original nicht eindeutig zugeordnet. Viel mehr erfüllt es die Ersetzungsfunktion nicht allgemein, sondern für ein bestimmtes Subjekt, in einem bestimmten Zeitintervall und unter Einschränkung auf einen bestimmten Zweck.¹⁵

Um eine sprachlich abstrakte Definition des Begriffes Modell zu erhalten, kann wieder auf Stachowiak zurückgegriffen werden. So sieht dieser ein Modell als mindestens fünfstelliges Prädikat und definiert den Begriff wie folgt:

„X ist Modell des Originals Y für den Verwender v in der Zeitspanne t bezüglich der Intention Z“ (Stachowiak, 1983, S. 118).

Unter Berücksichtigung der zuvor angeführten Merkmale sowie der sprachlichen Definition lässt sich ein erster Schluss auf die Funktion von Modellen ziehen. Sie repräsentieren spezifische Merkmale eines Originals der realen Welt und werden von Subjekten (wie Menschen) für den Verwender geschaffen. Außerdem ist die Abbildung des Originals auf eine bestimmte Zeit und einen bestimmten Verwendungszweck eingeschränkt, die ebenso subjektiv festgelegt sind.

Auf die Merkmale und die sprachliche Definition aufbauend können zwei grundlegende Modellverständnisse unterschieden werden. Dies sind der abbildungsorientierte Modellbegriff einerseits und der konstruktionsorientierte Modellbegriff andererseits. Neben diesen beiden Modellverständnissen können selbstverständlich noch weitere Begriffe unterschieden werden, wie beispielsweise der axiomatische Modellbegriff.¹⁶ Aufgrund der hohen Anzahl an Begriffsverständnissen soll im Folgenden jedoch auf die beiden eingangs erwähnten Modellbegriffe eingeschränkt werden.

2.1.2. Abbildungsorientierter Modellbegriff

Bei der Annahme eines abbildungsorientierten Modellverständnisses wird weder der Prozess noch das Ergebnis der Modellbildung hinterfragt. Bei diesem weit verbreiteten Verständnis wird implizit angenommen, dass unterschiedliche Subjekte immer zu der gleichen Abbildung gelangen. Das abbildungsorientierte Modellverständnis geht somit von einer direkten und eindeutigen Wiederspiegelung der Realität im Modell aus. Das zentrale Merkmal ist somit die Abbildung zwischen Original und Modell. Gleichzeitig wird unterstellt, dass das Modell immer einen Realitätsbezug hat, was dem Abbildungsmerkmal der Definition von Stachowiak widerspricht.¹⁷

Im Schrifttum der Wirtschaftswissenschaften ist dieses Verständnis als Standard anzusehen, da bereits frühe Arbeiten von dieser Auffassung ausgehen. Auch aktuelle Grundlagenwerke im Bereich (Wirtschafts-)Informatik folgen dieser Annahme und in weiten Teilen der Betriebswirtschaftslehre wird sie als grundständig angesehen.¹⁸

2.1.3. Konstruktionsorientierter Modellbegriff

Ein anderer Ansatz ist beim konstruktionsorientierten Modellbegriff zu sehen. Dieser Ansatz geht davon aus, dass die Wirklichkeit nicht objektiv existiert. Ebenso ist diese nicht objektiv zu erfahren. Daraus folgt, dass die Realität immer subjektgebunden ist.¹⁹ Dies impliziert, dass eine unterschiedliche Abbildung bei unterschiedlichen Subjekten vorhanden sein kann. Dies steht im Gegensatz zum abbildungsorientierten Begriffsverständnis.

Thomas beruft sich auf eine Definition von Schütte. Dieser sieht für die Konstruktion eines Modelles sechs Faktoren als entscheidend an. Zum einen sei ein Modell das Ergebnis einer Konstruktion durch einen Modellierer. Dieser repräsentiert ein Original für einen Modellnutzer. Diese Repräsentation erfolgt zu einer Zeit und wird mithilfe einer Sprache deklariert.

Das Original wird durch den Modellierer mithilfe einer Modellierungssprache in ein Modell expliziert. Die Modellnutzer sind diejenigen Subjekte, für die das Modell erstellt wird. Sie geben somit den Zweck des Modelles vor. Da sie des Weiteren an der Explikation mitwirken, ist eine Abstimmung zwischen Nutzern und Erstellern von großer Bedeutung.²⁰

Für die folgende Definition von Reifegradmodellen kann dementsprechend ein konstruktionsorientierter Modellbegriff zugrunde gelegt werden, wie auch Ahlemann et. al. durch die Aufführung von zwei Gründen belegen:

„(1) Die Konstruktion der Modelle erfolgt zumeist in einem konsens-orientierten Konstruktionsprozess, an dem eine Vielzahl von Subjekten beteiligt ist. (2) Die Anwendung der Modelle basiert meist nicht auf der Bewertung eines Einzelsubjektes sondern bezieht die Perspektiven einer Vielzahl von Subjekten ein“ (Ahlemann F. et. al., 2005, S. 11f.)

2.1.4. Reifegrad und Reifegradmodelle - Definitionen

In der einschlägigen Literatur ist für den Begriff des Reifegradmodelles, ebenso wie beim Modellbegriff, keine allgemeingültige Definition vorhanden. Das Software Engineering Institute (SEI) verwendet bei der Definition seines Reifegradmodelles CMM (Capability Maturity Model), dessen Nachfolger CMMI später in dieser Arbeit im Detail vorgestellt wird, eher Umschreibungen²¹:

„The CMM is a framework representing a path of improvements recommended for software organizations that want to increase their software process capability” (Paulk, M. C. et. al., 1993, S. 27) ²²

Der Reifegrad wird als das Potenzial des Wachstums von Fähigkeiten beschrieben. Er zeige unter anderem an, wie konsistent ein Softwareprozess in Projekten angewandt werde.²³

Ahlemann et. al. sehen ein Reifegradmodell als besondere Form eines Kompetenzmodelles. Ein Kompetenzmodell stellt dar, inwiefern betrachtete Objekte gewisse Anforderungen erfüllen. Diese Anforderungen seien für eine Klasse von Objekten allgemeingültig und beziehen sich auf die Qualität. Ein Reifegradmodell bringe die Erfüllung solcher Anforderungen durch sogenannte Reifegrade zum Ausdruck, die sequenziell aufeinander aufgebaut sind. Reifegraden werden die zu erfüllenden Anforderungen zugeordnet. Im Wortlaut definieren Ahlemann et. al. ein Reifegradmodell:

„Ein Reifegradmodell (Maturity Model) ist ein spezielles Kompetenzmodell, das unterschiedliche Reifegrade definiert, um beurteilen zu können inwieweit ein Kompetenzobjekt die für eine Klasse von Kompetenzobjekten allgemeingültig definierten qualitativen Anforderungen erfüllt.“ (Ahlemann, F. et. al., 2005, S. 13ff.)

2.1.5. Charakteristika von Reifegradmodellen

Betrachtet man die oben vorgeschlagene Definition lässt sich ableiten, dass ein Reifegradmodell in der Regel mehrere Ebenen besitzt, denen das betrachtete Kompetenzobjekt zugeordnet werden kann. Bei der Betrachtung existierender Reifegradmodelle bestätigt sich diese Beobachtung. Das bereits genannte CMM besitzt fünf solcher Reifegrade²⁴, ebenso der Nachfolger – das Capability Maturity Model Integration (CMMI)²⁵. Beide genannten Modelle sind ursprünglich für den Zweck der Prozessverbesserung im Bereich der Softwareentwicklung entstanden. Auch außerhalb dieser Disziplin sind Reifegradmodelle ähnlich aufgebaut. So besteht ein von Ferhat Demir im November 2018 veröffentlichter Vorschlag für ein Maturity Model for Innovation aus sechs aufeinander aufbauenden Reifegraden.²⁶ Das vom Project Management Institute PMI veröffentlichte Organizational Project Management Maturity Model OPM3 unterstützt Unternehmen bei der erfolgreichen Durchführung von Projekten und besteht aus vier Reifegraden.²⁷ Und auch das Modell von Hersey und Blanchard, anhand dessen der Reifegrad eines Mitarbeiters beurteilen werden kann, besitzt vier solche Reifegrade.²⁸ Zur besseren Übersicht wird die jeweilige Anzahl der Reifegrade der soeben vorgestellten Modelle nochmals dargestellt:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3: Darstellung der Anzahl von Reifegraden verschiedener Modelle

Bei allen betrachteten Modellen ist das Erreichen einer höheren Stufe das Ziel. Ebenso allen Modellen gemein ist die Vorgehensweise. Zunächst werden die betrachteten Objekte bewertet. Dies erfolgt meist anhand eines festgelegten Bewertungsbogens, mithilfe dessen eine Punktzahl bzw. Note vergeben werden kann. Anschließend wird das Betrachtungsobjekt entsprechend der Bewertung einem Reifegrad zugeordnet. Vorteilhaft ist, dass jeweils bekannt ist, welche Anforderungen für das Erreichen der nächsten Stufe erfüllt werden müssen. So kann eine Organisation die jeweils nötigen Voraussetzungen schaffen.²⁹

2.2. CMMI - Capability Maturity Model Integration

Nachdem der Modellbegriff und die Erklärung eines Reifegradmodelles in der Theorie erfolgt ist, soll im Folgenden ein Beispiel erläutert werden. Dieses Beispiel ist der de-facto-Standard der letzten Jahre, der in vielen Industrien Verwendung findet. Es handelt sich um das Capability Maturity Model Integration, kurz CMMI. Es erfolgt eine Einführung in die Geschichte von CMMI. Darauf folgt die Vorstellung eines speziellen Modelles von CMMI bevor am Ende die Einordnung in Reifegrade anhand eines Beispiels in CMMI vorgestellt wird.

2.2.1. Einführung in CMMI

Im Jahre 1987 begann das Verteidigungsministerium der Vereinigten Staaten (DoD) mit der Finanzierung des Software Engineering Insititute (SEI). Das SEI ist ein Forschungs- und Entwicklungszentrum an der Carnegie Mellon University (CMU) in Pittsburgh im US-Bundesstaat Pennsylvania.

Das DoD ist der weltweit größte Auftraggeber von Software. Diese Software ist meist kritisch, da sie z. B. als Teil von Waffensystemen verwendet wird. Eine termingerechte Lieferung in der geforderten Qualität ist unabdingbar.³⁰ Das DoD wollte deshalb potenzielle Software-Lieferanten vor der Erteilung des Auftrages bewerten und vergleichen können. Gleichzeitig wurde festgestellt, dass zu dieser Zeit Softwareprojekte häufig scheiterten oder mit einem extremen Verzug ausgeliefert wurden.³¹

Im selben Jahr (1987) beauftragte das DoD deshalb die Entwicklung eines Reifegradmodelles.

Als Folge entwickelte das SEI das Modell CMM (Capability Maturity Model), das eine Art Checkliste in fünf Stufen ist.³² Dieses ermöglichte, die gegenwärtige Prozessreife von Softwareunternehmen festzustellen, indem diese Reife einer der fünf Reifegradebenen zugeordnet wurde.³³

Im Jahre 1997 erfolgte die Weiterentwicklung von CMM, bei der verschiedene Module in einem Modell integriert wurden, ehe in den Jahren 2000, 2002 und 2006 weitere Versionen des sogenannten CMMI for Development (welches später vereinfacht als CMMI bezeichnet wurde) entwickelt wurden. CMMI steht hierbei für Capability Maturity Model Integration. Die Bezeichnung lässt ebenso Schlüsse auf den Grund der Entwicklung ziehen. Dieser ist die Integration mehrerer vorhandener Reifegradmodelle zu einem übergreifenden Modell. Im Jahre 2010 veröffentlichte das SEI die Version 1.3 von CMMI, die seither die größte Verbreitung besitzt.³⁴

Im Jahre 2012 gründete die Carnegie Mellon University das CMMI Institute, um die Weiterentwicklung des CMMI zu verbessern.³⁵ Anfang 2018 kündigte das CMMI Institute die Veröffentlichung von CMMI Development v2.0³⁶ an. Im Dezember 2018 wurde die CMMI V2.0 Product Suite um die Bereiche Services und Supplier Management erweitert.³⁷

Aufgrund bisher wenig verbreiteter Literatur zur Version 2.0 wird zur Erläuterung von CMMI auf die v1.3 zurückgegriffen. Diese war in den letzten Jahren der Standard für die Anwendung von CMMI.

2.2.2. Modelle und Grundstruktur von CMMI (v1.3)

Erste Modelle von CMMI waren das Integrated Product Development (1997), das in das Modell für Development (erste Version in 2002) integriert wurde und das CMM für Software Acquisition (2002). Die beiden letztgenannten Modelle wurden weiterentwickelt und bilden mit dem CMMI for Services den Kern der Version v1.3.³⁸

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Modelle von CMMI in der Version v1.3

Alle drei Modelle sind ähnlich aufgebaut. Sie bestehen aus sogenannten Prozessgebieten. Allen Modellen sind dabei 16 solcher Kernprozessgebiete gemein (sog. c ore process areas):

„All CMMI models contain 16 core process areas. These […] cover basic concepts that are fundamental to process improvement […]“ (SEI, CMMI for Development, 2010, S. 9)

Diese Kernprozessgebiete sind zwar in allen Modellen vorhanden, das Material ist jedoch nicht zwingend identisch aufgebaut.³⁹ Im Folgenden werden alle drei Modelle kurz beschrieben:

- CMMI for Development (CMMI-DEV): Das CMMI-DEV dient dem Anwendungsgebiet der Entwicklung von Produkten und Dienstleistungen⁴⁰. Es enthält fünf spezifische Prozessgebiete und eines, welches es mit CMMI-SVC teilt. Der Fokus liegt auf Aktivitäten von Organisationen mit Entwicklungsprozessen. Die enthaltenen Beschreibungen sind dabei unter anderem den Bereichen Projektmanagement, Prozessmanagement oder Hard- und Softwareentwicklung zuzuordnen.⁴¹
- CMMI for Services (CMMI-SVC): Das CMMI-SVC richtet den Fokus auf Aktivitäten des Dienstleisters. Es setzt sich aus sieben spezifischen Prozessgebieten und einem mit dem CMMI-DEV geteilten Prozessgebiet zusammen. Es beschreibt u. a. die Bereiche Kapazitätsplanung, Verfügbarkeitsplanung oder Problemlösung. Es richtet sich vor allem an Organisationen, die Dienstleistungen bereitstellen und deren Qualität sicherstellen wollen.⁴²
- CMMI for Acquisition (CMMI-ACQ): Beim CMMI-ACQ handelt es sich um ein Rahmenmodell für die erfolgreiche Akquisition von Leistungen. Es unterstützt Organisationen, Barrieren im Akquisitionsprozess zu verhindern. Es enthält sechs spezifische Prozessgebiete. Dies sind beispielsweise Vertragsmanagement oder Gestaltung von Lieferantenverträgen.⁴³

Im Folgenden wird exemplarisch für alle Modelle das CMMI for Development detailliert vorgestellt.

2.2.3. Prozessgebiete und Komponenten von CMMI for Development (V1.3)

CMMI-DEV besteht neben den 16 Kernprozessgebieten aus fünf weiteren Prozessgebieten. Außerdem beinhaltet es ein Gebiet, welches auch in CMMI-SVC vorhanden ist.

CMMI-DEV beschreibt Komponenten als Bewertungskriterium:

- Required Components müssen zwingend zur Erreichung einer Prozessoptimierung erfüllt werden und sichtbar im Prozess implementiert werden. Sie werden in CMMI als specific goals (dt. spezifische Ziele⁴⁴ ) und generic goals ( dt. generische Ziele) bezeichnet.
- Expected Components beschreiben Aktivitäten zur Erreichung eines required components und dienen daher als Leitfaden zur Implementierung. Sie können unterschieden werden in specific practices ( dt. spezifische Praktiken) und generic practices ( dt. generische Praktiken) . Ein Ziel gilt als erfüllt, wenn dessen Praktiken oder Alternativen erfüllt wurden.
- Informative Components dienen zum Verständnis für required und expected components. Dies können Beispielboxen, Detailbeschreibungen oder weitere hilfreiche Informationen sein. (SEI, CMMI for Development, 2010, S. 8f.)

Die zuvor erwähnten specific goals und generic goals sind wie folgt zu verstehen:

- Specific Goals beschreiben eindeutige Charakteristika. Diese müssen vorhanden bzw. erfüllt sein, um den Anforderungen des zugehörigen Prozessgebietes (process area) zu genügen. Sie helfen zur Feststellung, ob ein Prozessgebiet erfolgreich optimiert ist.
- Generic Goals können in mehreren Prozessgebieten essenziell sein. Sie beschreiben Charakteristika, welche vorhanden sein müssen, um einen Prozess implementieren zu können. Auch diese Komponente ist zwingend notwendig.

Zu den beschriebenen Zielen werden jeweils Praktiken beschrieben. Bei spezifischen Praktiken handelt es sich um Vorgehensweisen, die als wichtig erachtet werden um das zugehörige spezifische Ziel zu erreichen. Identisch sind generische Praktiken beschrieben. Diese können mehreren Prozessgebieten zugeordnet sein. Auch sie sind wichtig, um generischen Ziele zu erreichen.⁴⁵

Die folgende Abbildung soll den Zusammenhang von Komponenten veranschaulichen:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Komponenten von CMMI-DEV⁴⁶

Auf die weiteren Komponenten wird aufgrund des hohen Umfangs in diesem Zusammenhang nicht weiter eingegangen. Die Begriffsbestimmung der process areas scheint jedoch für das weitere Verständnis notwendig:

„A process area is a cluster of related practices in an area that, when implemented collectively, satisfies a set of goals considered important for making improvement in that area […]” (SEI, CMMI for Development, 2010, S. 11)

Dies bedeutet, dass ein Prozessgebiet mehrere Praktiken eines Bereiches zusammenfasst. Werden die Praktiken oder akzeptable Alternativen implementiert, gilt das Ziel als erfüllt. CMMI-DEV besitzt 22 Process Areas, die zur Identifikation jeweils mit einem Akronym versehen werden.

Prozessgebiete können einzelnen Kategorien zugeordnet werden. In CMMI-DEV existieren die Kategorien Support, Project Management, Process Management und Engineering ⁴⁷.

Folgende Tabelle zeigt die fünf für CMMI-DEV spezifischen Prozessgebiete und zwei weitere Kernprozessgebiete, die auch in den anderen CMMI-Modellen Verwendung finden⁴⁸.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4: Auszug aus den Prozessgebieten des CMMI-DEV (v1.3)

Prozessgebiete werden in CMMI bei der Betrachtung mit Reifegraden (s. a. 2.2.4.) nicht isoliert betrachtet. Einzelne Prozessgebiete stehen in Beziehung zu anderen. Sogenannte Related Process Areas sind aber nicht zwingend zum Erreichen eines Fähigkeitsgrad erforderlich⁴⁹.

2.2.4. Fähigkeits- und Reifegrade im CMMI for Development (v1.3)

In CMMI erfolgt eine grundsätzliche Unterscheidung zwischen Fähigkeitsgraden (capability levels) und Reifegraden (maturity levels). Den Begriff level definiert CMMI wie folgt:

„ Levels are used […] to describe an evolutionary path recommended for an organization that wants to improve the processes it uses […]“ (SEI, CMMI for Development, 2010, S. 21)

Fähigkeitsgrade betrachten ein einzelnes Prozessgebiet. Reifegrade betrachten mehrere Prozessgebiete im Zusammenhang. Dies führt im Hinblick auf die gesamte Organisation zu einem einheitlichen Reifegrad. Bei der Betrachtung mit Fähigkeitsgraden können diese je Prozessgebiet unterschiedlich hoch sein. Das SEI spricht von continuous representations bei Fähigkeitsgraden und staged representations bei Reifegraden. Bei beiden Betrachtungsweisen ist die Voraussetzung zum Erreichen eines höheren Grades das Erfüllen aller Ziele eines Prozessgebietes bzw. einer Sammlung von Prozessgebieten (SEI, CMMI for Development, 2010, S. 21f.) Die Modelle überschneiden sich, da Fähigkeits- und Reifegrade komplementär sind⁵⁰ (SEI, CMMI for Development, 2010, S. 23):

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 5: Darstellung von Fähigkeitsgraden und Reifegraden in CMMI

Bei der Betrachtung von Fähigkeitsgraden existieren vier Fähigkeitsgrade. Level 0 ist immer vorhanden. Diese Stufe ist der Startpunkt einer kontinuierlichen Verbesserung. Die Bezeichnungen und Merkmale der verschiedenen Fähigkeitsgrade werden wie folgt bestimmt:

- Incomplete (0): Ein Prozess wird nicht oder nur teilweise durchgeführt. Es wird eines oder mehrere specific goals nicht erfüllt. Generic goals sind auf dieser Ebene nicht vorhanden, da es keinen Grund gibt, einen nur teilweise durchgeführten Prozess zu institutionalisieren.
- Performed (1): Es ist ein Prozess vorhanden um Ergebnisse produzieren zu können. Die specific goals des Prozessgebietes sind erfüllt. Der Prozess kann jedoch verloren gehen.
- Managed (2): Ein Prozess ist vorhanden, geplant und wird in Abstimmung mit vorhandenen Regeln durchgeführt. Qualifizierte Mitarbeiter werden mit den nötigen Ressourcen ausgestattet um kontrollierte Produkte herzustellen und betroffene Stakeholder⁵¹ werden involviert. Der Prozess ist überwacht und kontrolliert und wird auf Revisionsfähigkeit überprüft. Ein Prozess der Stufe 2 kann auch in Zeiten von Stress kontrolliert durchgeführt werden.
- Defined (3): Der Prozess entspricht unternehmensweiten Richtlinien für Prozesse und wird regelmäßig geprüft. Der Unterschied zu Level 2 liegt in den Prozessstandards, der Prozessbeschreibung und den Vorgehensweisen. In Level 3 sind diese durch ein institutionalisiertes Prozessmanagement vorgegeben. Prozesse der Stufe 3 werden proaktiv geführt.⁵²

Das Erreichen eines höheren Levels setzt voraus, dass auch die Anforderungen der darunter liegenden Level erfüllt werden. Grafisch sieht die Betrachtung mit Fähigkeitsgraden wie folgt aus:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Darstellung von Fähigkeitsgraden in CMMI-DEV⁵³

Die Betrachtung mit Reifegraden erfolgt im Hinblick auf eine organisationsweite Optimierung. Jedem Reifegrad sind Prozessgebiete zugeordnet. Reifegrade werden erreicht, indem die Ziele aller dem Reifegrad zugeordneten Prozessgebiete erreicht werden. Jedes Unternehmen befindet sich automatisch auf Reifegrad 1 (Initial). Um Reifegrad 2 zu erreichen, muss ein Unternehmen die generischen und spezifischen Ziele der folgenden Prozessgebiete erfüllen⁵⁴:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 6: Zu erfüllende Prozessgebiete für CMMI-Reifegrad 2 (Managed)

Für einen höheren Reifegrad müssen auch die Prozessgebiete der vorgelagerten Reifegrade erfüllt sein. Die Reifegrade definieren sich wie folgt:

- Initial (Level 1): Prozesse werden chaotisch durchgeführt. Projekte sind nur aufgrund von einzelnen Personen erfolgreich. Projekte und Produkte funktionieren, überschreiten aber regelmäßig Budget und Zeitplan. Erfolg ist nicht wiederholbar.
- Managed (Level 2): Geplante Prozesse werden in Abstimmung mit vorhandenen Regeln durchgeführt. Der Reifegrad Managed entspricht der Definition des Fähigkeitsgrades Managed (2). Produkte sind zu bestimmten Momenten für das Management sichtbar (z. B. beim Erreichen von Meilensteinen). Stakeholder werden integriert und Produkte werden kontrolliert. Produkte erfüllen Prozessbeschreibungen, Standards und Vorgehensweisen.
- Defined (Level 3): Auch im Level 3 entspricht die Definition des Reifegrads dem zugehörigen Fähigkeitsgrad Defined. Prozesse sind strenger beschrieben und es sind klare Rollen, Messgrößen und Prüfkennzeichen vorhanden.
- Quantitatively Managed (Level 4): Für die Prozessqualität sind objektive Kriterien implementiert, die als Kriterien im Projektmanagement genutzt werden. Qualität und Performance sind wichtige Werte für Statistiken. Sie werden deshalb durch den gesamten Lebenszyklus von Prozessen beobachtet und erhoben. Unterprozesse werden statistisch analysiert. Der Zusammenhang zwischen Unterprozessen muss verstanden werden. Dies gewährleistet, dass die Statistik am Ort des größten Nutzens erhoben wird. Aufgrund der erhobenen Statistiken wird versucht, Vorhersagen zu treffen.
- Optimizing (Level 5): Auf dieser Ebene unterzieht eine Organisation ihre Prozesse einem kontinuierlichen Verbesserungsprozess. Es basiert auf einem quantitativen Verständnis der Geschäftsobjekte und notwendigen Performance. Die Organisation prüft den Prozess und sein Ergebnis quantitativ. Der Fokus liegt auf der kontinuierlichen Verbesserung. Dies wird durch eine Etablierung von Kennzahlen für Qualität und Performance gewährleistet. Der Unterschied zu Level 4 ist auf Level 5 die Betrachtung des Gesamtprozesses.⁵⁵

Um höhere Reifegrade zu erreichen ist eine sukzessive Optimierung auf Organisationsebene nötig. Unternehmen sollten zuerst ihren aktuellen Reifegrad ermitteln. Danach rücken die Prozessgebiete des nächsthöheren Reifegrades in den Fokus. Wurden diese erfüllt, kann die Konzentration jeweils auf den nächsthöheren Reifegrad gelenkt werden. Wird dies bis zum höchsten Reifegrad durchgeführt, etabliert sich ein kontinuierlicher Verbesserungsprozess.⁵⁶ Bei der Betrachtung mit Reifegraden ergibt sich eine stufenförmige Darstellung:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Darstellung der Reifegrade in CMMI

2.2.5. Einstufung eines Prozessgebietes

Jedes Prozessgebiet beinhaltet spezifische und generische Ziele. Generische Ziele werden übergreifend für alle Prozessgebiete definiert. Sie sind für die ersten drei Stufen definiert⁵⁷ und enthalten generische Praktiken. Sind diese Praktiken oder akzeptable Alternativen dazu erfüllt ist das generische Ziel erreicht. Generische Ziele werden mit dem Präfix GG nummeriert, während generische Praktiken mit GP nummeriert werden.⁵⁸ In CMMI-DEV existieren drei generische Ziele: ⁵⁹

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 7: Generische Ziele und generische Praktiken in CMMI-DEV

Ludewig und Lichter beschreiben die Einordnung wie folgt:

„[…] Eine Organisation erhält […] Reifegrad X, wenn für alle Prozessbereiche der Stufe X die generischen Ziele GZ 1 bis GZ X erfüllt sind.“ (Ludewig, J. & Lichter H., 2013, S. 243)⁶⁰

Das bedeutet, um Reifegrad 2 zu erreichen, müssen für alle Prozessgebiete des Reifegrades 2 die generischen Ziele GG 1 und GG 2 erreicht werden⁶¹. Am Beispiel des Prozessgebietes Project Planning wird dies veranschaulicht. Es „umfasst alle Tätigkeiten, um alle Pläne zu erstellen und zu pflegen, die die Projektaktivitäten festlegen.“ (Ludewig, J. & Lichter, H. 2013, S. 238)

Um das generische Ziel GG 1 zu erfüllen, müssen die spezifischen Ziele des betrachteten Prozessgebietes erfüllt werden. Spezifische Ziele werden mit dem Präfix SG nummeriert, spezifische Praktiken mit SP. ⁶² Ein spezifisches Ziel ist erreicht, wenn die spezifischen Praktiken oder akzeptable Alternativen erfüllt sind. Für das Prozessgebiet Project Planning sind gemäß CMMI-DEV folgende spezifische Ziele und Praktiken definiert:⁶³

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 8: Generisches Ziel GG 1 am Beispiel von Prozessgebiet Project Planning (PP)

Innerhalb der spezifischen Praktiken sind weitere sogenannte Subpractices (dt. Unterpraktiken) definiert. Dies sind Empfehlungen, um der übergeordneten spezifischen Praktik zu entsprechen. Für spezifische Praktiken werden auch als Beispiel Ergebnisse angeführt, die erstellt werden sollten, um die Praktik zu erfüllen. Mit dem Erfüllen der o. g. spezifischen Ziele erfüllt ein Unternehmen das generische Ziel GG 1.

Um eine höhere Einstufung zu erreichen, muss zusätzlich zu den spezifischen Zielen das generische Ziel GG 2 erreicht werden. CMMI-DEV stellt hierzu Beschreibungen bereit, wie Prozessgebiete im Hinblick auf das Erfüllen von generischen Praktiken bewertet werden können. Im Anhang C wird das am Beispiel von Project Planning veranschaulicht.

2.2.6. Ziele und Kritik

CMMI soll ein aktuelles Bild der Prozessqualität liefern, um dadurch die Stärken und Schwächen des aktuellen, real vorhandenen Prozesses sichtbar zu machen. Daraus soll eine Prozessverbesserung abgeleitet werden. CMMI ist nicht technologiegebunden, das heißt es ist nicht ausschließlich auf klassische Methoden oder eine bestimmte eingesetzte Technik anwendbar.⁶⁴

Studien zu CMMI bringen überwiegend positive Erfahrungen hervor. Kritische Stimmen sind jedoch ebenso vorhanden, die vor allem folgende Kritikpunkte anführen:

- Die Basis von CMMI ist das Erfahrungswissen weniger Personen. Möglicherweise werden so entscheidende Faktoren nicht berücksichtigt
- Die Veränderungen technischer und organisatorischer Rahmenbedingungen wird nicht ausreichend berücksichtigt, was zu einem statischen Bild führt
- Die Einordnung in Reifegrade und Prozessbereiche sei willkürlich⁶⁵
- CMMI führt zu Trägheit im Unternehmen, da sich Firmen, die CMMI anwenden eher darauf konzentrieren, bestimmte Reifegrade beizubehalten, anstatt Innovationen hervorzubringen
- Es besteht die Gefahr der Bürokratisierung

Der letzte Kritikpunkt wird vor allem von Verfechtern agiler Methoden angebracht. Er tritt vor allem dann auf, wenn die Konzentration zu stark auf Dokumentation und Prozesskonformität gelegt wird, anstatt auf das Erreichen von Verbesserungen.⁶⁶

3. Agile Vorgehensweisen

Im folgenden Kapitel wird näher auf agile Vorgehensweisen eingegangen. Diese sind aus einer Gegenbewegung entstanden, die von Entwicklern durchgeführt wurde, um sich auf das Ziel einer funktionierenden Software zu konzentrieren und nicht auf bürokratische Prozesse. Gegen Ende der 1990er-Jahre entstanden diverse Ansätze wie Extreme Programming, Crystal oder Scrum⁶⁷.

3.1. Das Agile Manifest

Im Februar 2001 diskutierten schließlich 17 Personen eine Alternative zur klassischen Softwareentwicklung. Das Ergebnis ist das Manifesto for Agile Software Development. Es enthält vier Werte, die bei der Softwareentwicklung berücksichtigt werden sollen. Sie schätzen die erstgenannten Werte wichtig ein, die zweitgenannten jedoch höher.⁶⁸

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Die Werte Agiler Softwareentwicklung⁶⁹

Die Unterzeichner des Agilen Manifestes stellen mit ihren Werten somit Menschen, Produkte, Zusammenarbeit und Reaktionsfähigkeit in den Fokus.⁷⁰ Dies steht im Gegensatz zu klassischen Phasenmodellen wie dem Wasserfallmodell.⁷¹ Dort stehen Aktivitäten und Dokumente im Fokus und es sieht die Software-Entwicklung „als Folge von Aktivitäten, die durch Teilergebnisse (Dokumente) gekoppelt sind.“ (Ludewig, J. & Lichter, H., 2013, S.157)

3.2. Agile Prinzipien

Aus den vier Werten wurden zwölf Prinzipien abgeleitet. Ursprünglich für die Softwareentwicklung gedacht, haben sie sich mittlerweile in diversen Disziplinen etabliert. So definiert Michl die Prinzipien für die öffentliche Verwaltung allgemeingültig (Michl, T., 2018, S. 6ff.).

Im Folgenden werden die agilen Prinzipien im Wortlaut angeführt⁷² und deren Sinn kurz interpretiert. Die Übersetzung, ausführliche Beschreibungen und Interpretationen sind in Anhang D zu finden.

„Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”

Frühe und regelmäßige Auslieferungen sollen Mehrwert für den Kunden schaffen.

“Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage”

Änderungswünsche von Kunden sollen auch spät im Prozess berücksichtigt werden und nicht von Vornherein durch Verträge ausgeschlossen werden.

“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale”

Funktionierende Software soll regelmäßig und bevorzugt in kurzen Zeitabständen ausgeliefert werden.

“Business people and developers must work together daily throughout the project” und “The best architectures, requirements, and designs emerge from self-organizing teams”

Für ein erfolgreiches Projekt müssen interdisziplinäre Teams täglich zusammenarbeiten.

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done”

Interdisziplinäre Teams sollen mit Handlungsfreiheiten ausgestattet werden und ihnen soll Vertrauen sowie die nötigen Werkzeuge bereitgestellt werden.

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”

Die effektivste Methode zum Informationsaustausch ist persönliche Kommunikation. Menschen sollen häufig persönlich miteinander sprechen.

“Working software is the primary measure of progress”

Der Projekterfolg wird nicht an der Erreichung von Meilensteinen oder ähnlichen Kennzahlen gemessen, sondern an funktionierenden Produkten, die dem Kunden Mehrwert schaffen.

“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely”

Es sollte darauf geachtet werden, dass die Aufgaben in einem konstanten Tempo durchgeführt werden können. Selbst kurzzeitige Überstunden wirken sich negativ auf die Performance aus.

“Continuous attention to technical excellence and good design enhances agility”

Die Produkte sollen technisch exzellent sein und gut gestaltet werden.

“Simplicity - the art of maximizing the amount of work not done - is essential”

Das Prinzip “Einfachheit” soll berücksichtigt werden. Zunächst sollte das Produkt funktionieren, Erweiterungen können danach, je nach Ressourcenverfügbarkeit, hinzugefügt werden.

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”

Das Team soll regelmäßig reflektieren, ob die angewandten Prozesse und Vorgehensweisen dem Ziel des Schaffens von Mehrwert für den Kunden dienen.

3.3. Scrum – Ein Rahmenwerk

Im vorhergehenden Kapitel wurden Reifegradmodelle anhand des Beispiels CMMI veranschaulicht. Dies soll im folgenden Abschnitt auch mit agilen Methoden erfolgen. Dazu wurde wiederum der de-facto-Standard der Methoden ausgewählt, der in vielen Unternehmensbereichen Verwendung findet. Es handelt sich um das Rahmenwerk Scrum. Es erfolgt eine Kurzeinführung, ehe die Rollen und Artefakte von Scrum beschrieben werden. Abgerundet wird das Beispiel mit der Beschreibung des grundsätzlichen Prozesses.

3.3.1. Einführung in Scrum

In den folgenden Abschnitten wird mit Scrum ein Rahmenwerk für Agilität vorgestellt.⁷³

Scrum (dt. „das Gedränge“ – aus dem Rugby entlehnt) wurde von Jeff Sutherland und Ken Schwaber 1995 niedergeschrieben. Das Rahmenwerk für agile Entwicklung definiert sich wie folgt:

„Ein Rahmenwerk, innerhalb dessen Menschen komplexe adaptive Aufgabenstellungen angehen können, und durch das sie in die Lage versetzt werden, produktiv und kreative Produkte mit höchstmöglichem Wert auszuliefern“ (Sutherland & Schwaber, 2017, S. 3)

Scrum erfährt in den vergangenen Jahren zunehmend Beachtung, da es in den verschiedensten Bereichen angewandt werden kann und unabhängig von Technologien oder Tools ist. Es gilt als „De-facto-Standard in der agilen Softwareentwicklung“ (Gloger, B., 2010, S. 195).

Scrum verfolgt einen inkrementellen und iterativen Ansatz. Prozesse und Ergebnisse werden permanent kontrolliert und ggf. angepasst.

3.3.2. Rollen in Scrum

Scrum differenziert drei Rollen - Product Owner, Entwicklungsteam und Scrum Master.

Der Product Owner ist die Schnittstelle zum Kunden. Er ist der Produktverantwortliche. Er nimmt Anforderungen auf, sortiert sie und bereitet sie für die Umsetzung auf. Er trägt auch die Kosten- und Erfolgsverantwortung. Er legt deshalb fest, was im nächsten Zyklus (dem Sprint, s. a. 3.3.4) entwickelt werden soll und ist für die Abnahme des Inkrements zuständig.

Das Entwicklungsteam ist für die Umsetzung verantwortlich. Es besteht aus Profis, die je Sprint ein potenziell auslieferbares Inkrement übergeben. Die Teamgröße sollte zwischen drei und neun Mitgliedern betragen. Zu kleine Teams können eventuell nicht genügend Fähigkeiten bereitstellen, um hohe Qualität zu gewährleisten. Zu große Teams haben das Risiko einer zu hohen Komplexität.

Der Scrum Master ist im Hinblick auf die Erstellung des Produktes nachrangig zu betrachten. Er sorgt dafür, dass das Entwicklungsteam störungsfrei an der Erstellung der Inkremente arbeiten kann. Außerdem sorgt er für die Förderung und Anwendung von Scrum gemäß des Scrum Guides. Er hat keine Weisungskompetenz gegenüber den anderen Rollen. Er wird deshalb als Servant Leader bezeichnet. Bei der Einführung von Scrum ist er ein entscheidender Erfolgsfaktor. Er sorgt dafür, dass die Beteiligten ein tiefes Verständnis von Scrum erlangen und es anwenden können.

3.3.3. Artefakte von Scrum

Scrum sieht drei Artefakte vor, auf denen der Fokus liegen soll. Diese sind der Product Backlog, der Sprint Backlog sowie das Product Increment.

Der Product Backlog ist die Menge an Anforderungen für das Gesamtprodukt. Er ist niemals vollständig und beinhaltet sämtliche bekannte Anforderungen an das Produkt. Er wird vom Product Owner gepflegt. Die Befüllung erfolgt mit sogenannten Themes, Epics und User Stories⁷⁴.

Der Product Owner priorisiert anschließend alle User Stories bzw. Anforderungen im Product Backlog. Einträge können auch verfeinert werden (Refinement). Die Entscheidung über den Zeitpunkt und die Art der Verfeinerung trifft das Scrum-Team. Diejenigen Einträge, die im nächsten Zyklus bearbeitet werden sollen, werden am weitesten verfeinert und als bereit (Ready) markiert.

Das Entwicklungsteam wählt anschließend unter Berücksichtigung des Status und der Priorisierung die Einträge aus, die es im nächsten Zyklus bearbeiten will. Diese werden dem Sprint Backlog hinzugefügt. Dieser ist die Basis für den nächsten Sprint. Im Hinblick auf die Anzahl der gewählten Anforderungen ist ein weiterer Begriff von Bedeutung, der kein Teil des Scrum Guides ist, jedoch häufig im Zusammenhang mit Scrum genannt wird. Es handelt sich um die Velocity. Sie gibt an, „wie viele Story Points sich im Laufe eines Sprints umsetzen lassen“ (Eckkramer, T. et. al, 2014, S. 91). Dieser Wert stabilisiert sich nach einiger Zeit aufgrund von Erfahrungswerten.

Das letzte Artefakt ist das Product Increment oder Inkrement. Es stellt das Ergebnis aller in einem Sprint fertiggestellter Einträge aus dem Product Backlog dar und sollte daher ein potenziell auslieferbares Produkt darstellen. Es erfüllt dann den Zustand Done, der für ein allgemeingültiges Verständnis vom Entwicklungsteam vorab festgelegt werden sollte und ggf. aufgrund regulatorischer oder gesetzlicher Richtlinien bereits vorgegeben sein kann.

3.3.4. Ereignisse in Scrum

Im Verlauf eines Projektes mit Scrum treten einige Ereignisse auf. Da Scrum einen iterativen Charakter besitzt, treten diese regelmäßig auf. Gemäß dem Scrum Guide können fünf solcher Ereignisse differenziert werden. Diese lauten Sprint, Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospektive. Die folgende Abbildung veranschaulicht den kompletten Scrum-Prozess.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Der Scrum-Prozess im Überblick

Das Hauptereignis in Scrum ist der Entwicklungszyklus. Der sogenannte Sprint dient dazu innerhalb einer festgelegten Zeit ein fertiges Produktinkrement zu schaffen. Dieser Zeitraum ist immer gleich und soll maximal 30 Tage betragen. Diese Zeitbegrenzung wird Timebox genannt. Sprints sind somit im Sinne von Projekten mit einem Zeithorizont von maximal 30 Tagen anzusehen. Dem Product Owner ist das Recht vorbehalten, einen Sprint abzubrechen.

Zu Beginn eines jeden Sprints wird das Sprint Planning durchgeführt. In dieser Sitzung erarbeitet das gesamte Scrum-Team die Arbeit für den kommenden Sprint und plant unter Rücksicht auf Priorität und Aufwand, was im Produktinkrement des folgenden Sprints enthalten ist. Am Ende des Sprint Planning ist der Sprint Backlog gefüllt und das Team kann mit der Umsetzung beginnen.

Während des Sprints tritt das Entwicklungsteam täglich zusammen. Das Ereignis wird Daily Scrum genannt. Innerhalb von insgesamt 15 Minuten beantwortet jedes Teammitglied folgende Fragen:

- Was habe ich gestern für das Sprint-Ziel getan?
- Was werde ich heute für das Sprint-Ziel tun?
- Sehe ich Hindernisse, die das Sprint-Ziel gefährden können?

Das Daily Scrum fördert die direkte Kommunikation. Bei Störungen oder nötigen Detailinformationen erfolgt im Anschluss an das Daily Scrum eine separate Besprechung.

[...]

---

¹ Aus Gründen der besseren Lesbarkeit wird in dieser Arbeit bei Personenbezeichnungen die männliche Form gewählt, die Angaben beziehen sich jedoch selbstverständlich auf beide Geschlechter

² Vgl. Baltes, G. & Freyth, A. (2017, S. 4), Olbert, S. et. al. (2019, S. 99)

³ Weitere Erläuterungen zu verwendeten Fachbegriffen sind im Glossar zu finden

⁴ Eigene Abbildung in Anlehnung an Baltes, G. & Freyth, A. (2017, S. 10)

⁵ Baltes, G. & Freyth, A (2017, S. 44)

⁶ Tom Peters war zwischen 1974 und 1981 bei McKinsey & Company als Management Consultant tätig

⁷ Vgl. Baltes, G. & Freyth, A. (2017, S. 69)

⁸ Vgl. Komus A. & Kuberg, M. (2017, S. 12)

⁹ Vgl. Standish Group (2015, S. 7)

¹⁰ Vgl. Komus A. & Kuberg, M. (ebenda)

¹¹ Vgl. Röglinger, M. & Kamprath, N. (2012, S. 510)

¹² Vgl. Röglinger, M. & Kamprath, N. (ebenda)

¹³ Vgl. Ludewig, J. & Lichter, H. (2013, S. 236)

¹⁴ Beck, K. et. al (2001)

¹⁵ Vgl. Stachowiak, H. (1973, S. 131ff.)

¹⁶ Vgl. Thomas, O. (2005, S. 11)

¹⁷ Vgl. Thomas, O. (2005, S. 14)

¹⁸ Vgl. vom Brocke, J. (2015, S. 10), Ahlemann F. et. al. (2005, S. 10), Thomas, O. (2005, S. 13f.)

¹⁹ Vgl. Thomas, O. (2005, S. 17)

²⁰ Vgl. Thomas, O. (2005, S.18ff.)

²¹ Vgl. Ahlemann, F. et. al. (2005, S. 12)

²² Sämtliche Übersetzungen wörtlich zitierter Passagen in einer Fremdsprache sind im Anhang A zu finden

²³ Vgl. Paulk, M. C. et. al. (1993, S.4)

²⁴ Vgl, Paulk M. C. et. al. (1993, S. 8)

²⁵ Vgl. SEI, CMMI for Development (2010, S. 23)

²⁶ Vgl. Demir, F. (2018, S. 17f.)

²⁷ Vgl. Project Management Institute (2003, S. 19)

²⁸ Vgl. Gasche, R. (2018, S. 73)

²⁹ Vgl. Jacobs, S. (2018)

³⁰ Vgl. Ludewig, J. & Lichter, H. (2013, S. 236)

³¹ Vgl. Paulk, M. C. et. al. (1993, S. 1)

³² Vgl. Ludewig, J. & Lichter, H. (ebenda)

³³ Ahlenmann, F. et. al. (ebenda)

³⁴ Vgl. SEI, CMMI for Development (2010, S. 5f.)

³⁵ Vgl. CMMI Institute, About CMMI® Institute (o. J)

³⁶ Vgl. CMMI Institute, The CMMI® Institute Announces CMMI Development V2.0 (2018)

³⁷ Vgl. CMMI Institute, CMMI® Institute Expands CMMI® V2.0 to Include Services and Supplier Management (2018)

³⁸ Vgl. CMMI for Development (2010-2, S. 6)

³⁹ Vgl. SEI, CMMI for Development (2010, S. 9)

⁴⁰ Vgl. Ludewig, J. & Lichter, H. (2013, S. 237)

⁴¹ Vgl. SEI, CMMI for Development (2010-2, S. 3ff.)

⁴² Vgl. SEI, CMMI for Services (2010-2, S. 1ff.)

⁴³ Vgl. SEI, CMMI for Acquisition (2010, S. 3ff.)

⁴⁴ Für das spätere Verständnis im Text werden einzelne Komponenten wörtlich übersetzt

⁴⁵ Vgl. SEI, CMMI for Development (2010, S. 12f.)

⁴⁶ Eigene Abbildung in Anlehnung an SEI, CMMI for Development (2010, S. 10)

⁴⁷ Vgl. SEI, CMMI for Development (2010, S. 33f.)

⁴⁸ Eine Liste aller Prozessgebiete und der zugehörigen Kategorien ist im Anhang B zu finden

⁴⁹ Vgl. SEI, CMMI for Development (2010, S. 12)

⁵⁰ Vgl. SEI, CMMI for Development (2010, S. 27)

⁵¹ Stakeholder sind berechtigte Interessenseigentümer an Unternehmen (z. B. Kunden, Lieferanten, Politik)

⁵² Vgl. SEI, CMMI for Development (2010, S. 24f.), Kneuper, R. (o. J.)

⁵³ Eigene Abbildung in Anlehnung an SEI, CMMI for Development (2010, S. 31)

⁵⁴ Vgl. SEI, CMMI for Development (2010, S. 33f.)

⁵⁵ Vgl. SEI, CMMI for Development (2010, S. 27ff.) sowie Ludewig, J. & Lichter, H. (2013, S. 240ff.)

⁵⁶ Vgl. SEI, CMMI for Development (2010, S. 29f.)

⁵⁷ Vgl. Ludewig, J. & Lichter, H. (2013, S. 242)

⁵⁸ Vgl. SEI, CMMI for Development (2010, S. 16)

⁵⁹ Vgl. SEI, CMMI for Development (2010, S. 68ff.) sowie Ludewig, J. & Lichter, H. (2013, S. 242.)

⁶⁰ Ludewig und Lichter verwenden den dt. Präfix GZ für „generisches Ziel“ (im Original GG)

⁶¹ Vgl. Ludewig, J. & Lichter, H. (2013, S. 243)

⁶² Vgl. SEI, CMMI for Development (2010, S. 16)

⁶³ Vgl SEI, CMMI for Development(2010, S. 283ff.)

⁶⁴ Vgl. Ludewig, J. & Lichter, H. (2013, S. 237)

⁶⁵ Vgl. Ludewig, J. & Lichter, H. (2013, S. 248)

⁶⁶ Vgl. Jacobs, S. (2018)

⁶⁷ Vgl. Ludewig, J. & Lichter, H. (2013, S.218f.)

⁶⁸ Beck, K. et. al (2001)

⁶⁹ Eigene Abbildung nach Beck, K. et. al. (2001)

⁷⁰ Vgl. Michl, T. (2018, S. 5)

⁷¹ Kuster, J. et. al. (2019, S. 18)

⁷² Vgl. o. A., Principles behind the Agile Manifesto (o. J.)

⁷³ Vgl. Sutherland & Schwaber (2017), Fischbach, J. (2018, S. 65ff.), Eckkramer, T. et. al. (201,4 S.90ff.), Wolf, F. (2018, S. 255f.)

⁷⁴ Themes, Epics und User Stories werden im Anhang E näher erläutert