I

Inhaltsverzeichnis

INHALTSVERZEICHNIS   I

BILDERVERZEICHNIS.   III

1.  EINLEITUNG UND MOTIVATION  1

1.1  MOTIVATION  1

1.2  ZIEL  1

1.3  VORGEHENSWEISE  2

2.  PROJEKTMANAGEMENT.  3

2.1  GRUNDLAGEN.  3

2.2  METHODIKEN IM IT-PROJEKTMANAGEMENT  4

2.2.1  Wasserfall-Modell  4

2.2.2  V-Modell XT  5

2.2.3  Extreme Programming  7

2.3  AGILES PROJEKTMANAGEMENT.  8

2.3.1  Einführung.  8

2.3.2  Das Agile Manifest  9

2.3.3  Prinzipien des agilen Manifest  12

3.  SCRUM.  14

3.1  GRUNDLAGEN UND GESCHICHTE  14

3.2  ROLLEN  16

3.2.1  Scrum Master.  16

3.2.2  Product Owner  19

3.2.3  Team  21

3.2.4  Weitere Rollen  23

3.3  ANFORDERUNGSMANAGEMENT IN SCRUM.  23

3.3.1  Product Backlog  23

3.3.1.1  Einführung.  23

3.3.1.2  Beschreibung.  24

3.3.1.3  Priorisierung  25

3.3.1.4  Aufwandsabschätzung.  25

3.3.1.5  Definition of Done.  27

3.3.1.6  Entwicklung  27

3.3.1.7  Verantwortlichkeit und Hilfsmittel.  28

3.3.2  Sprint Backlog  28

3.3.3  Burn Down Chart  30

3.4  SPRINTS  32

3.5  MEETINGS  35

Inhaltsverzeichnis II

3.5.1  Release-Planung.  35

3.5.2  Sprint Planning Meeting.  36

3.5.3  Daily Scrum  37

3.5.4  Scrum of Scrums  40

3.5.5  Sprint Review.  41

3.5.6  Retrospektive  42

4.  EINFÜHRUNG UND PRAXIS.  44

4.1  EINFÜHRUNG VON SCRUM  44

4.1.1  Motivatoren  44

4.1.2  Vorgehensweisen  44

4.1.3  Gefahren  46

4.2  PRAXISBEISPIEL: TELEGATE MEDIA AG.  47

4.2.1  telegate Media vor der Einführung von Scrum.  47

4.2.2  Idee, Einführung und Umsetzung.  49

4.2.2.1  Idee.  49

4.2.2.2  Einführung und Umsetzung.  50

4.2.3  Wirkungen der Einführung  51

4.2.3.1  Eingetretene Verbesserungen  51

4.2.3.2  Probleme und Herausforderungen  52

4.2.3.3  Weitere Konsequenzen.  54

5.  BEWERTUNG  55

5.1  KRITERIEN EINES GEEIGNETEN IT-PROJEKTMANAGEMENTS  55

5.2  EIGNUNG VON SCRUM FÜR DAS MANAGEMENT VON IT-PROJEKTEN  56

5.3  WEITERE EINSATZMÖGLICHKEITEN  59

5.4  GRENZEN DER ANALYSE.  60

6.  FAZIT  62

LITERATURVERZEICHNIS   63

III

Bilderverzeichnis

BILD 1 WASSERFALL-MODELL .....................................................................................................................5

BILD 2 V-MODELL XT ..................................................................................................................................6

BILD 3 MANIFESTO FOR AGILE SOFTWARE DEVELOPMENT ........................................................................11

BILD 4 GRAFISCHE DARSTELLUNG DER SCRUM PROZESSE .........................................................................15

BILD 5 SPRINT BACKLOG ............................................................................................................................29

BILD 6 BURN DOWN CHARTS......................................................................................................................30

BILD 7 SPRINT TYPEN .................................................................................................................................33

BILD 8 ZEITVERSETZTE UND SYNCHRONISIERTE SPRINTS ...........................................................................34

BILD 9 SOFTWAREENTWICKLUNG BEI DER TELEGATE MEDIA AG VOR DER EINFÜHRUNG VON SCRUM ......48

1. Einleitung und Motivation

1.1 Motivation

Projekte gibt es schon seit Jahrtausenden. Bereits vor 4500 Jahren erbauten die Ägypter Pyramiden, Projekte von beachtlicher Größe und enormem Aufwand (Litke 2007, S. 7). Auch heute gibt es Projekte mit enormen Ausmaßen wie z. B. das 2005 in Deutschland eingeführte LKW-Mautsystem. Es gibt aber auch zahlreiche kleinere Projekte, deren Ergebnisse sich z. B. als Software in Motorsteuergeräten moderner Autos, DVD-Player, Handys, Digitalkameras, Kassensysteme im Supermarkt, gmx.de, google.com, facebook.com und vielen weiteren Produkten wiederfinden, die für unser alltägliches Leben von Bedeutung sind.

Für die erfolgreiche und effiziente Abwicklung solcher und anderer Projekte bedarf es einer klaren und systematischen Vorgehensweise (Bea et al. 2008, S. 30). In der Literatur und in der Praxis finden sich hierfür eine Reihe von Methodiken und Vorgehensweisen. Eine davon ist Scrum, das als De-Facto-Standard für agiles Projektmanagement gilt (Gloger 2010, S. 195). Aber was genau ist Scrum, wie funktioniert es, worin unterscheidet es sich von anderen Methodiken und macht der Einsatz überhaupt Sinn? Zur Beantwortung dieser Fragen sind eine umfassende Vorstellung und eine Bewertung von Scrum notwendig. Hilfreich ist auch ein Blick über den Tellerrand der wissenschaftlichen Theorie hinaus in die Praxis, was diese Arbeit leisten wird.

1.2 Ziel

Ziel dieser Arbeit ist es, Scrum umfassend zu beschreiben und anschließend, anhand zuvor diskutierter Kriterien, zu bewerten. Beim Leser soll also ein umfassendes Verständnis für diese agile Projektmanagementmethodik geschaffen werden. Daneben soll es dem Leser ermöglicht werden, Scrum im Kontext seines Arbeitsumfelds bzw. für künftige Projekte kritisch zu bewerten und eine fundierte Entscheidung bezüglich einer Einführung von Scrum zu treffen.

1.3 Vorgehensweise

Zu Beginn wird sich die Arbeit, mithilfe vorhandener Literatur, mit Projekten, Projektmanagement und Projektmanagementmethodiken beschäftigen. Die Einführung in agiles Projektmanagement und dessen Differenzierung zu anderen Methodiken und Vorgehensweisen bildet dann den Übergang zu einer umfassenden Auseinandersetzung mit Scrum. An dieser Stelle wird Scrum detailliert erläutert und es wird beschrieben, wie eine mögliche Einführung praktisch umgesetzt werden kann. Anschließend wird auf Schwierigkeiten und Probleme, die dabei auftreten können, eingegangen. Wie das praktisch aussehen kann, wird mithilfe eines Beispiels aus der Praxis illustriert. Dies bildet dann die Grundlage zu einer abschließenden Bewertung bezüglich der Einsatzmöglichkeiten sowie der Stärken und Schwächen von Scrum.

2. Projektmanagement

2.1 Grundlagen

Um ein gemeinsames Verständnis für die Begriffe Projekt und Projektmanagement zu haben, werden diese hier definiert.

KESSLER UND WINKELHOFER (2004, S. 9-10) beschreiben ein Projekt in Anlehnung an DIN 69 901 als ein Vorhaben, das im Wesentlichen durch die Einmaligkeit seiner Bedingungen in ihrer Gesamtheit gekennzeichnet ist. Als Beispiele zählen sie Zielvorgabe, Abgrenzung von anderen Vorhaben, begrenzte Ressourcen und eine projektspezifische Organisation auf. Als weitere Eigenschaften eines Projekts nennen sie unter anderem Neuartigkeit, Komplexität, klare Zielsetzung und zeitliche Begrenzung. Ferner definieren sie Projektmanagement als das erforderliche Management, um ein Projekt in einer bestimmten Art, zu einer bestimmten Zeit mit einem bestimmten Einsatz von Ressourcen zu einem bestimmten Ergebnis zu bringen. Basierend auf der DIN 69 901 beschreiben sie Projektmanagement auch als Gesamtheit von Führungsaufgaben, -organisationen, -techniken und -mitteln für die Abwicklung eines Projekts.

BEA, ET AL. (2008, S. 31) definieren ein Projekt ähnlich als ein zeitlich befristetes Vorhaben, das sich neben seiner Neuartigkeit und Einmaligkeit auch durch seine Größe und Komplexität auszeichnet. Ohne den Begriff Unternehmenswert explizit zu definieren, identifizieren BEA, ET AL. (2008, S. 36) dessen Steigerung als die wichtigste Zielsetzung des Projektmanagements. Dazu trage das Projektmanagement mit einer effizienten Planung, Umsetzung und Kontrolle einzelner Projekte bei. Realisiert wird der Wertbeitrag eines Projekts durch ein systematisches Vorgehen. VERSTEEGEN, ET AL. (Versteegen et al. 2001, S. 209-210) liefern keine vollständige Definition für das Projektmanagement, identifizieren aber aus Unternehmenssicht Termin- und Budgeteinhaltung und aus Kundensicht die Erfüllung seiner Anforderungen zum vereinbarten Zeitpunkt als wesentliche Kriterien.

Auch wenn es, wie VERSTEEGEN ET AL. (Versteegen et al. 2001, S. 209) anmerken, keine einheitliche Definition für das Projektmanagement in der Softwareentwicklung gibt, findet sich im intendierten Ziel, ein Projekt erfolgreich abzuschließen, eine wesentliche Gemeinsamkeit. Diese Arbeit orientiert sich bezüglich der Betrachtung des Projektmanagements ebenfalls an dieser Sichtweise und den von VERSTEEGEN ^{ET AL.} genannten Kriterien Termineinhaltung, Budgeteinhaltung und Anforderungserfüllung.

2.2 Methodiken im IT-Projektmanagement

Aufbauend auf das vorige Kapitel, werden hier einige Methodiken für das Management von IT-Projekten exemplarisch vorgestellt. Damit soll eine Grundlage geschaffen werden, mit der später Scrum verglichen werden kann. Als IT-Projekte werden in dieser Arbeit solche verstanden, deren Ziel die Entwicklung von Produkten aus dem Bereich Informationstechnik ist.

2.2.1 Wasserfall-Modell

Das Wasserfall-Modell ist das älteste im Software-Engineering bekannte Vorgehensmodell. Kennzeichnend für das Wasserfall-Modell ist das sequentielle Abarbeiten der einzelnen Phasen. In jeder Phase wird ein Ergebnis produziert, das einer Qualitätskontrolle unterzogen und als Input der nächsten Phase bereitgestellt wird. Alternativ ist auch ein Rücksprung in die vorangegangene Phase möglich. (Ruf und Fittkau 2008, S. 31; Versteegen 2002, S. 30-31)

Die Stärke des Wasserfall-Modells ist gleichzeitig auch seine Schwäche. Da die Projektdetails bereits zu Beginn festgelegt und vom Kunden abgenommen werden, können spätere Änderungen gering gehalten werden. Dadurch lässt sich eine bessere Steuerbarkeit und Berechenbarkeit des Projekts bezüglich Zeit und Kosten erreichen. Der Versuch, Änderungen möglichst gering zu halten, macht es aber auch schwierig, während des Projekts erzielte Lerneffekte in das Projekt mit einfließen zu lassen. (Poppendieck und Poppendieck 2003, S. 25)

Alternative Darstellungen des Wasserfall-Modells, die sich primär in der Auswahl der verwendeten Phasen unterscheiden, finden sich unter anderem bei MADACHY (2008, S. 31), SCHÖNSLEBEN (2001, S. 107) und STOBBS (2000, S. 56).

2.2.2 V-Modell XT

Der Standard für die Entwicklung und Wartung von Software aller deutschen Bundesministerien ist das V-Modell, welches 1992 erstmals veröffentlicht wurde und seitdem ständig weiter entwickelt wird (Bernhard et al. 2003, S. 289). Die derzeit aktuelle Version ist das 2005 veröffentlichte V-Modell XT. Dieses deckt eine ganze Reihe von Projekttypen und Disziplinen wie beispielsweise Projektmanagement, Qualitätssicherung, Konfigurationsmanagement oder Ausschreibung und Vergabe ab. (Kirk 2010, S. 26-27) Ein durch das Suffix XT im Namen dargestellter Unterschied und wesentlicher Bestandteil des V-Modell XT gegenüber den vorherigen Versionen, ist das eXtreme Tailoring, womit gemeint ist, dass sich das Modell an die gegebenen Erfordernisse des Unternehmens und des Projekts anpassen lässt. (Faerber 2010, S. 17) Das zentrale Element des Tailoring sind Vorgehensbausteine, die jeweils eine eigenständige Einheit darstellen und die wesentlichen Inhalte des V-Modell XT enthalten. Diese können verändert und erweitert werden, und beinhalten alle notwendigen Aktivitäten und zu erstellenden Produkte, einschließlich der mitwirkenden Rollen, die zur Erfüllung von Aufgabenstellungen im Rahmen eines V-Modell-Projekts relevant sind. Einige dieser Vorgehensbausteine werden zusammen als der V-Modell- Kern bezeichnet, der ein Mindestmaß an Qualität in der Projektdurchführung

garantieren soll und für jedes Projekt obligatorisch ist. Zu diesem V-Modell-Kern gehören die Vorgehensbausteine Projektmanagement, Qualitätssicherung,

Konfigurationsmanagement und Problem- und Änderungsmanagement. In welcher Reihenfolge die Vorgehensbausteine angewendet werden, ist nicht vorgegeben, sondern hängt von der Projektdurchführungsstrategie ab, die festlegt, wann welches Produkt zu erstellen ist. Als Produkt werden alle zentralen Zwischen- und Endergebnisse des Projekts verstanden. Die Projektdurchführungsstrategie wird auf Basis des Projekttyps (unterstützt werden die Typen Systementwicklungsprojekt als Auftraggeber, als Auftragnehmer, Systementwicklungsprojekt innerhalb der Organisation und Einführung und Pflege eines organisationsspezifischen Vorgehensmodells) und der Projektvariante, die den Projekttyp näher charakterisiert, entwickelt. Neben der Projektdurchführungsstrategie werden auch sogenannte Entscheidungspunkte definiert, die einen Meilenstein darstellen, an dem der Projektfortschritt geprüft und gegebenenfalls das weitere Vorgehen freigegeben wird. In Bild 2 finden sich alle vorgesehenen Entscheidungspunkte, die entsprechend der in der Legende dargestellten Aufteilung in vier Bereiche farblich markiert sind. Die grundlegende Struktur des Projektverlaufs ergibt sich damit durch die Projektdurchführungsstrategie und die Entscheidungspunkte. (Abrahamsson 2002, S. 15-22)

2.2.3 Extreme Programming

Das von Kent Beck, Howard Cunningham und Ron Jeffries entwickelte Extreme Programming zählt zu den bekanntesten Vertretern der agilen Methodiken und Modellen. Extreme Programming kennzeichnet sich durch die fünf grundlegenden Werte Kommunikation (zwischen allen Beteiligten), Einfachheit (von Lösungen), (frühes und ständiges) Feedback, Mut (zum Handeln), Respekt (gegenüber Anderen und dem Projekt) und Andere (vom Team gewählte Werte). (Beck 2003, S. 18-22) Aus diesen Werten leiten sich eine Reihe von Handlungspraktiken ab, die sich vereinzelt bereits bewährt haben und eine Verbesserung bringen können, aber erst in der den Werten entsprechenden und den vorherrschenden Erfordernissen ausgerichteten Kombination sich gegenseitig verstärken und einen deutlich spürbaren Nutzen bringen. (Beck 2003, S. 35-36; Litke 2007, S. 276) Im Folgenden sind einige dieser Handlungspraktiken exemplarisch beschrieben:

- Pair Programming: An einem Arbeitsplatz sitzen zwei Entwickler, von denen einer aktiv programmiert und vom zweiten unterstützt wird.

- Test-First-Programming: Bevor Code geschrieben oder geändert wird, werden für das gewünschte Resultat Testfälle geschrieben.

- Ständige Integration: Die Integration und der Test von Änderungen erfolgt alle paar Stunden oder häufiger.

- Geteilter Code: Jeder Entwickler kann zu jedem Zeitpunkt an jeder beliebigen Stelle im System am Code arbeiten und diesen verbessern.

- Ursachenanalyse: Bei jedem gefundenen Fehler wird neben dessen Behebung auch nach der Ursache geforscht und diese beseitigt.

- Echte Kundeneinbindung: Diejenigen, die das Produkt später nutzen, werden direkt in das Team eingebunden. (Beck 2003, S. 37-70)

Wie aufgrund der Bezeichnung Extreme Programming schon vermutet werden kann, legt diese Methodik den Fokus auf die Softwareentwicklung, insbesondere das Programmieren. Bereiche wie Marketing, Vertrieb oder Management liegen außerhalb der Betrachtung. Genauso wenig kennt Extreme Programming feste Rollen. Stattdessen wird von jedem Teammitglied erwartet, sein bestmöglichstes zu tun, um zum Projekterfolg beizutragen. (Beck 2003, S. 82-85)

Anzumerken ist noch, dass während LITKE (2007, S. 273) und HOFFMANN (2008, S. 507) die Eignung von Extreme Programming nur für kleine bis mittelgroße Teams als gegeben sehen, ist diese BECK UND ANDRES (2003, S. 3) zufolge auch für große Projekte und Teams geeignet, wenn entsprechend angepasst und skaliert wird.

2.3 Agiles Projektmanagement

Einige Projektmanagementmethodiken wurden bereits vorgestellt. Eine weitere ist das agile Projektmanagement, welches mehr ist als nur eine Methodik. Was das bedeutet, wird im Folgenden beantwortet.

2.3.1 Einführung

In den letzten rund 40 Jahren, in denen Vorgehensmodelle und Methodiken erschienen sind, lässt sich ein klarer Trend hin zu einem immer größeren Umfang und Komplexität erkennen. Während das Wasserfall-Modell (Æ 2.2.1) noch relativ leicht zu Beschreiben ist, erfordert das V-Modell XT (2002) eine umfassende Einarbeitung. Daneben werden traditionellen Vorgehensmodellen und Methodiken eine durch zu starre Strukturen bedingte Inflexibilität, eine mangelnde Einbeziehung des Kunden in die Entwicklungsprozesse und ein hoher Dokumentationsaufwand vorgeworfen. Als Gegengewicht dazu erschienen in den 1990er Jahren die ersten agilen Methodiken, die das Ziel hatten, Software-Entwicklungsprozesse zu verschlanken und deren Komplexität zu reduzieren. (Hoffmann 2008, S. 506-507; Vigenschow 2008) Zu diesen zählt GLOGER (2010, S. 195) neben Scrum das Extreme Programming (Beck 2003) von Kent Beck und Ward Cunningham, Crystal Clear von Alistair Cockburn (Cockburn 2005) und Feature Driven Development von Jeff DeLuca und Peter Coad (De Luca o. J.). Als weitere bekannte Vertreter nennt SEIBERT (2007, S. 42-43) auch Adaptive Software Development von James Highsmith (Highsmith 2000) und Lean Software Development von Mary und Tom Poppendieck (Poppendieck und Poppendieck 2003). Im Februar 2001 trafen sich 17 Leute in Utah, darunter einige der eben genannten Vertreter agiler Methodiken sowie Softwarespezialisten aus unterschiedlichen Bereichen, die eines gemeinsam hatten: Sie sahen die Notwendigkeit für eine Alternative zu schwergewichtigen Software-Entwicklungsmethodiken. In den drei

Tagen, die sie gemeinsam verbrachten, gründeten sie die „Agile Alliance“ und entwickelten das „Manifesto for Agile Software Development“ auch bekannt als das Agile Manifest. (Highsmith 2001)

2.3.2 Das Agile Manifest

Agile Entwicklung ist nicht einfach eine Methodik, ein Modell oder ein Prozess. Es ist eine Philosophie. Es ist die Denkweise wie sie vom agilen Manifest vorgesehen und durch vier Bewertungen und zwölf Prinzipien beschrieben ist. (Shore und Warden 2008, S. 9)

Das Agile Manifest (Æ Bild 3) beginnt mit der Aussage, dass dessen Verfasser durch ihre Praxis bessere Wege der Softwareentwicklung finden und anderen dabei helfen. Daraus lässt sich schließen, dass das agile Manifest nicht nur theoretischer Natur ist, sondern aus der praktischen Erfahrung vieler Spezialisten der Softwareentwicklung resultiert. Durch diese Arbeit, so die Verfasser, kommen sie zu den folgenden Bewertungen:

1. Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge Im Vordergrund stehen die einzelnen Menschen, die zusammen entwickeln und miteinander sowie mit ihrer Umwelt interagieren. Auch wenn Werkzeuge und Prozesse durchaus wichtig sind, dürfen sie die Arbeit der Menschen nicht einschränken. Während es die Menschen sind, die ein Projekt voranbringen, sollen ihnen Prozesse und Werkzeuge lediglich als Hilfsmittel dienen, um das Projektziel zu erreichen. (Bleek und Wolf 2008, S. 14-15)

2. Lauffähige Software ist wichtiger als umfassende Dokumentation Lucius Annaeus Seneca schrieb einst: „Longum iter est per praecepta, breve et efficax per exempla“, was etwa so viel bedeutet wie: Lang ist der Weg durch Lehren, kurz und wirkungsvoll durch Beispiele. (Lautenbach 2002, S. 375) Während die Dokumentation von Funktionalität als Lehre bezüglich der Software betrachtet werden kann, ist lauffähige Software zur Präsentation der Funktionalität wirkungsvoller. Hinzu kommt, dass lauffähige Software der Maßstab ist, mit dem der Projektfortschritt nachgewiesen wird. Daher steht lauffähige Software im Vordergrund und sollte möglichst früh und oft

präsentiert werden können. Dokumentation sollte zugunsten lauffähiger Software eingespart werden und nur in dem Umfang erstellt werden, der für die Erreichung des Projektziels erforderlich ist und dabei einfach, präzise, klar, widerspruchsfrei und angemessen bezüglich des Verhältnisses von Aufwand und Nutzen sein. Der Transfer von Wissen sollte weniger durch Dokumentation und mehr durch Interaktion und Kommunikation erfolgen. (Bleek und Wolf 2008, S. 14-15; Koch 2008, S. 74-75) 3. Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen Insbesondere bei innovativen Produkten unterliegen Anforderungen einer hohen Unsicherheit, so dass es selten möglich ist, diese und andere Details wie Budget oder Entwicklungsdauer im Rahmen von Vertragsverhandlungen bereits zu Beginn des Projekts präzise festzulegen und auch einzuhalten. Dies wird auch vom jährlich erscheinenden Chaos Report der Standish Group (2009) bestätigt, der besagt, dass nur in etwa einem Drittel aller IT-Projekte innerhalb der vorgegebenen Zeit mit dem geplanten Budget die gewünschten Anforderungen realisiert werden. Die Entwicklung einer brauchbaren und dem Kundenwunsch gerecht werdenden Software ist nur dann möglich, wenn mit dem Kunden und den Anwendern zusammengearbeitet wird. Auch wenn Vertragsverhandlungen vor Projektbeginn erforderlich sind, dürfen sie die spätere Zusammenarbeit nicht behindern. In den Vertragsverhandlungen sollten lediglich grobe Rahmenbedingungen festgelegt werden, die nach und nach zusammen mit dem Kunden präzisiert werden. Dies und die ständige Möglichkeit des Teams, vom Kunden Feedback zu erhalten bzw. zu erfragen, erhöht die Wahrscheinlichkeit, dass Anforderungen richtig verstanden und durch eventuelle Spekulationen bezüglich der Kundenwünsche entstandene falsche Annahmen für die Entwicklung vermieden werden. Auch die Wahrscheinlichkeit, dass zu einem späten Zeitpunkt beim Kunden Änderungswünsche auftreten, reduziert sich damit. (Dubinsky und Hazzan 2008, S. 10; Koch 2008, S. 76)

4. Die Reaktion auf Veränderungen ist wichtiger als das Befolgen der Planung Während eines Projekts können ständig neue Erkenntnisse und Lerneffekte auftreten. So kann für das geplante Produkt die Notwendigkeit weiterer oder die Zwecklosigkeit geplanter Funktionen erkannt werden. Effizienzhemmer in bestimmten Vorgehensweisen können durch Lerneffekte vermieden werden. Es gibt viele unterschiedliche Veränderungsmaßnahmen, die erkannt werden und eine Verbesserung

für den Projektablauf bedeuten können. Daher wird die Reaktion auf Veränderungen als wichtiger bewertet als das sture Befolgen von Plänen. (Bleek und Wolf 2008, S. 15) Im Anschluss an diese vier Bewertungen folgt die Aussage, dass die Autoren zwar den Werten auf der rechten Seite einen Wert beimessen, denen auf der linken Seite jedoch einen höheren Wert zuschreiben.