Agile Scrum Handbuch E-Book

Frank Turley

• Herausgeber: Van Haren Publishing
• Kategorie: Bildung
• Sprache: Deutsch
• Veröffentlichungsjahr: 2020

Seitenzahl: 145

Beschreibung

Sie finden hier eine einfache, leicht verständliche Anleitung für alle, die das Konzept von Agilität und das Scrum-Framework erlernen möchten. Sie umfasst die zugrunde liegenden Konzepte und Prinzipien sowie die Rollen und Verantwortlichkeiten von Scrum, Ereignisse, Artefakte und Skalierungs-Ansätze, sowie gängige Verfahren und Techniken. ❶ Anstatt Agilität bloss darzustellen, konzentriert sich das Buch auf das einfache und konsistente Verstehen ihrer wahren Bedeutung und untersucht die Arten von Projekten, bei denen sie funktionieren kann und wo dies möglicherweise nicht der Fall ist. Diese Grundlage hilft Ihnen, sich in den alltäglichen Herausforderungen zu orientieren. ❷ Das Buch ist ein umfassender Leitfaden zum Scrum-Framework, basierend auf dem Scrum Guide (Ausgabe November 2017). Es umfasst alle Rollen und Verantwortlichkeiten, Ereignisse und Artefakte sowie einen kurzen Abschnitt zum Skalieren von Scrum. ❸ Es gibt ein Kapitel zur eXtreme-Programmierung, mit Beispielen für den Einsatz einiger der wichtigsten agilen Praktiken und Techniken, wie z. B. Test-Driven Development und Pair-Programming. ❹ Das vierte Kapitel gibt einen Überblick über die DSDM®-Methode, und konzentriert sich dabei hauptsächlich auf den dortigen Ansatz, Umfang und Festpreisverträge strukturiert zu bestimmen. ❺ Im letzten Kapitel finden Sie eine Übersicht über Kanban und ScrumBan. Dieses Buch ist auf das Zertifizierungsprogramm der EXIN Agile Scrum Foundation abgestimmt.

Leseprobe

Agile Scrum Handbuch

Andere Ausgaben bei Van Haren Publishing

Van Haren Publishing (VHP) ist auf Veröffentlichungen über Best Practices, Methoden und Standards auf dem Gebiet der folgenden Domänen spezialisiert:

-     IT und IT-Management;

-     Enterprise-Architektur;

-     Projektmanagement und

-     Businessmanagement.

Diese Veröffentlichungen sind in mehreren Sprachen verfügbar und sind Teil führender Serien, wie Best Practice, The Open Group series, Project management und PM series.

Auf der Website von Van Haren Publishing ist in der Knowledge Base ein großes Angebot Whitepapers, Templates, kostenlose E-Books, Dozentenmaterialien etc. zu finden. Besuchen Sie www.vanharen.net.

Van Haren Publishing ist weiterhin der Herausgeber von führenden Institutionen und Unternehmen, darunter: Agile Consortium, ASL BiSL Foundation, CA, Centre Henri Tudor, Gaming Works, IACCM, IAOP, IPMA-NL, ITSqc, NAF, KNVI, PMI-NL, PON, The Open Group, The SOX Institute.

Themen pro Domäne sind:

IT und IT-Management

ABC of ICT™

ASL®

CATS CM®

CMMI®

COBIT®

e-CF

ISO 17799

ISO 20000

ISO 27001/27002

ISPL

IT4IT

IT-CMFTM

IT Service CMM

ITIL®

MOF

MSF

SABSA

SIAM

Enterprise-Architektur

ArchiMate®

GEA®

Novius Architektur Methode

TOGAF®

Businessmanagement

BABOK® Guide

BiSL® und BiSL® Next

BRMBOKTM

BTF

EFQM

eSCM

IACCM

ISA-95

ISO 9000/9001

OPBOK

SixSigma

SOX

SqEME®

Projektmanagement

A4-Projektmanagement

DSDM/Atern

ICB / NCB

ISO 21500

MINCE®

M_o_R®

MSP®

P3O®

PMBOK®Guide

PRINCE2®

Für eine vollständige Übersicht aller Veröffentlichungen besuchen Sie bitte unsere Website: www.vanharen.net

Impressum

Titel:

Agile Scrum Handbuch

Autoren:

Nader K. Rad und Frank Turley

Deutsche Ubersetzung:

Thomas Wuttke u.a.

Herausgeber:

Van Haren Publishing, ’s-Hertogenbosch - NL, www.vanharen.net

ISBN Hardcopy:

978 94 018 0475 2

ISBN EBook (pdf):

978 94 018 0476 9

ISBN ePub:

978 94 018 0477 6

Druck:

Niederländische Version: Erste Ausgabe, erste Auflage, September 2018

Deutsche Übersetzung: Erste Ausgabe, erste Auflage, September 2020

Layout und DTP:

Coco Bookmedia, Amersfoort – NL

Copyright:

© Van Haren Publishing, 2018, 2020

Kein Teil dieser Veröffentlichung darf vervielfacht, als automatisierte Datei gespeichert oder veröffentlicht werden auf oder mittels jeglicher Medien, ob elektronisch, mechanisch, als Fotokopie oder auf andere Weise, ohne die vorherige schriftliche Genehmigung des Herausgebers.

Trotz aller Sorgfalt hinsichtlich dieser Veröffentlichung können mögliche Fehler auftreten. Der Herausgeber und die Autoren übernehmen keine Haftung für das Auftreten von Fehlern und/oder Mängeln.

1. DAS AGILE KONZEPT

1.1 Projektmanagementmethode und Projektlebenszyklus

1.2 Prognostizierte versus adaptive Lebenszyklen

1.3 Agile versus Wasserfall

1.4 Ist Agile etwas Neues?

1.5 Das Agile Manifest

1.6 Die agilen Prinzipien

1.7 Praktische Überlegungen zu adaptiven Lebenszyklen

1.7.1 Iterationen mit festem Umfang versus Iterationen mit fester Dauer

1.7.2 Länge der Iterationen

1.7.3 Gleiche oder unterschiedliche Dauer für Iterationen?

1.7.4 Was ist, wenn einige Funktionen nicht fertig werden?

1.7.5 Was passiert in den Iterationen?

1.7.6 Empowerment

1.8 Ist Agile nur etwas für IT-Projekte?

1.9 Ist Agile schneller?

2. SCRUM

2.1Methodik versus Framework

2.2 Kurzer Überblick über das Scrum-Framework

2.3 Scrum-Rollen

2.3.1 Scrum Team

2.3.2 Rolle 1: Product Owner

2.3.3 Rolle 2: Scrum Master

2.3.4 Rolle 3: Entwicklungsteam?

2.3.5 Andere Rollen

2.3.6 Wer ist der Projektleiter?

2.3.7 Schweine und Hühner

2.3.8 Geeigneter Arbeitsplatz

2.3.9 Osmotische Kommunikation

2.3.10 Virtuelle Teams

2.4 Scrum-Ereignisse

2.4.1 Einführung in Scrum-Ereignisse

2.4.2 Timeboxing

2.4.3 Ereignis 1: Der Sprint

2.4.4 Ereignis 2: Sprint-Planung

2.4.5 Ereignis 3: Daily Scrum

2.4.6 Ereignis 4: Sprint-Review

2.4.7 Ereignis 5: Sprint-Retrospektive

2.4.8 Aktivität: Grooming (Pflege) des Product Backlogs

2.4.9 Keine Pause zwischen den Sprints

2.4.10 Der erste Sprint!

2.4.11 Release-Planung

2.4.12 Agiles Testen

2.4.13 Planungszwiebel

2.5 Scrum-Artefakte

2.5.1 Artefakt 1: Das Product Backlog

Product Backlog Items (Einträge)

Nur funktionale Anforderungen?

Die zwei Regeln

Die INVEST-Kriterien

Epics und Themes

Schätzungen

Story Points

Velocity (Geschwindigkeit)

Idealstunden / Idealtage

Velocity (Geschwindigkeit) versus Erfolg

Velocity (Geschwindigkeit) versus Velocity (Geschwindigkeit)

Planning Poker

Triangulation

Triangulation Board

Affinitätsschätzung

Neuschätzung

Priorisierung der Items (Einträge) des Product Backlogs

Was versteht man unter Wert?

Realwert ~ Nutzen / Kosten.

Die Priorisierung des Product Backlogs

Betriebswirtschaftliche Fachbegriffe

2.5.2Artefakt 2: Sprint Backlog

Unfertige Items (Einträge) am Ende des Sprints

Alle Items haben mitten im Sprint einen Status von Done (Fertig)

Festgeschrieben versus dynamisch

Unfertige Arbeit versus Velocity (Geschwindigkeit)

2.5.3 Artefakt 3: Inkrement

2.5.4 Definition of Done (Definition von Fertig)

2.5.5 Definition of Ready (Definition von Bereit)

2.5.6 Überwachung der Projektleistung

2.5.7 Überwachung des Sprint-Fortschritts

2.5.8 Information Radiator

Burn-Down Charts

Burn-Down Bars

Burn-Up Charts

Kumulatives Flussdiagramm

Niko-Niko-Kalender

2.6 Skaliertes Scrum

2.6.1 Rollen

2.6.2 Artefakte

2.6.3 Ereignisse

Sprint-Planung

Daily Scrums

Sprint Reviews

Sprint-Retrospektive

3. EXTREME PROGRAMMING (XP)

3.1 Pairing (Paarbildung)

3.2 Zuteilung von Aufgaben

3.3 Design (Entwurf)

3.4 Tests schreiben

3.5 Code

3.6 Refactoring

3.7 Integration

3.8 Gehen Sie nach Hause!

3.9 Daily Standup

3.10 Tracking

3.11 Risikomanagement

3.12 Spiking

4. DSDM®

4.1 Projektparameter

4.2 Planung im Vorfeld

4.3 MoSCoW-Priorisierung

4.4 Ausnahmen

4.5 Selbstorganisation

4.6 Vertragsarten

5. KANBAN UND SCRUMBAN

5.1 Kanban

5.1.1 Visualisierung

5.1.2 WiP-Grenzen

5.1.3 Pull versus Push

5.2 ScrumBut

5.3 ScrumBan

ÜBER DIE AUTOREN

Sie möchten etwas lernen, das Sie bei Ihren Projekten unterstützt? In diesem Fall sollten Sie zwei entscheidende Punkte beachten, die meist falsch verstanden werden:

1. Die weit verbreitete Aussage „Agile ist eine Einstellung.“ ist falsch. Richtig dagegen ist, dass man für Agile eine bestimmte Einstellung braucht. Bezeichnet man Agile als Einstellung, so führt dies in der Praxis lediglich dazu, dass man ohne jegliche Einschränkung und ganz nach eigenem Gutdünken arbeitet. Man nennt es einfach Agile, lässt Kritik an sich abprallen und strebt nicht wirklich nach Verbesserung.

2. Wer auch nur die Spur einer Ahnung hat, wie autoritäre Systeme funktionieren, weiß, dass solche Systeme stets ein Feindbild brauchen, um Schwächen im eigenen System zu überspielen und die Massen kontrollieren zu können. Die traditionelle Wasserfall-Methode erfüllt für viele Anwender agiler Methoden die Funktion dieses Feindbilds. Die Wasserfall-Methode wird zwar niemals eindeutig definiert, aber es wird impliziert, dass es sich um etablierte Projektmanagementsysteme handelt. Erfolgreiche Projekte benötigen jedoch kein Feindbild. Bitte denken Sie stets daran, dass erfolgreiche Systeme immer auf den vorhandenen Systemen aufbauen und nicht von Grund auf neu gebaut werden und dass jede Kritik, ganz gleich wie berechtigt sie sein mag, respektvoll und konstruktiv sein muss.

Sehen wir uns also an, was Agile wirklich bedeutet.

■ 1.1 PROJEKTMANAGEMENTMETHODE UND PROJEKTLEBENSZYKLUS

Bei der Softwareentwicklung werden auf die eine oder andere Weise folgende Schritte entweder für einzelne Funktionen oder für die Softwarelösung insgesamt durchgeführt:

■ Analyse

■ Design (Planung)

■ Realisierung

■ Integration

■ Test

Natürlich können diese Schritte auch anders bezeichnet, in weniger Schritte zusammengefasst oder in mehrere Schritte aufgeteilt werden. Diese Schritte nennt man auch Phasen der Softwareentwicklung.

Die Frage ist nun, wie Sie diese Phasen organisieren und ausführen. Nehmen Sie sich kurz Zeit und überlegen Sie sich ein paar Optionen, bevor Sie den Rest des Kapitels lesen.

Nun, auf wie viele Optionen sind Sie gekommen?

Möglicherweise können Sie sich viele verschiedene Optionen vorstellen. Im Endeffekt aber, gehören alle diese Optionen zu einer der zwei generischen Formen. Übrigens bezeichnet man diese Optionen auch als Lebenszyklus der Softwareentwicklung:

Ein generischer Lebenszyklus sieht etwa so aus:

In diesem Lebenszyklus wird jede Phase abgeschlossen, bevor man mit der nächsten beginnt. Mit anderen Worten, Anforderungen werden vollständig analysiert, bevor entschieden wird, was die Lösung beinhalten muss. Dann wird die Architektur der Lösung entworfen und festgelegt, wie sich die Funktionen am besten gestalten lassen. Im Anschluss daran arbeiten die Programmierer an verschiedenen Einheiten, die dann in einer Lösung zusammengeführt und als Gesamtlösung getestet werden.

Natürlich können sich die Schritte auch überlappen; so muss man beispielsweise nicht warten bis alle Einheiten vorliegen, bevor man mit der Integration und dem Testen beginnt. In einem solchen Fall könnte der Lebenszyklus wie folgt aussehen:

Dieser Lebenszyklus unterscheidet sich nicht grundlegend vom vorherigen Lebenszyklus und besteht ebenfalls aus einer sequenziellen Abfolge von Entwicklungsprozessen.

Grundvoraussetzung für diese Art von Lebenszyklus ist der anfängliche Aufwand, die Anforderungen an das zu bauende System zu verstehen. Die Spezifikation, das Design und folglich auch die Planung liegen im Vorfeld vor. Daher spricht man bei dieser Art von Lebenszyklus auch von einer plangesteuerten Entwicklung. Wir versuchen vorherzusagen bzw. zu prognostizieren, was wir wollen und wie sich dies realisieren lässt. Man spricht daher auch von einem prognostizierten Lebenszyklus.

Prognostizierte Lebenszyklen sind bei vielen Projekten, wie z. B. bei Bauvorhaben, der normale und geeignete Weg. Zuerst werden Planung und Entwurf erstellt und danach richtet sich dann die anschließende Ausführung. Für andere Projekte dagegen, ist diese Vorgehensweise nicht optimal.

Denken Sie nur einmal an ein typisches Projekt in der IT-Entwicklung. Man investiert viel Zeit in die Spezifikation und Analyse der Anforderungen und baut dann die gesamte Entwicklung des Softwareprodukts darauf auf. Was passiert nun in der Praxis häufig? Die Kunden wünschen Änderungen. Änderungen aber sind bei diesem Lebenszyklus in dieser Phase teuer, da möglicherweise alle bisherigen Ergebnisse nochmals überarbeitet und geändert werden müssen.

Eine gängige Weisheit in der IT besagt, dass viele Kunden erst wissen, was sie wollen, wenn sie das fertige Produkt sehen. Das Produkt sehen sie aber erst gegen Ende des Projekts und damit in einer Phase, in der Änderungen mit den größten Kosten verbunden sind.

Diesem Problem können wir begegnen, indem wir den Komfort und die Struktur des prognostizierten Lebenszyklus opfern, zugunsten eines Lebenszyklus, bei dem das Produkt inkrementell, in mehreren Versionen entwickelt wird. Jede Version umfasst dabei mehr Funktionen als ihre Vorgängerversion. Diese Art der Entwicklung ist ein besonderer Luxus, den nicht alle Projekte bieten. Bei Bauvorhaben beispielsweise gibt es keine sinnvollen Inkremente und das Produkt kann erst nach Abschluss des Projekts genutzt werden. Die IT-Entwicklung jedoch bietet die Möglichkeit mehrerer funktionierender Versionen, bei der jede Version um weitere Funktionen ergänzt wird.

Fairerweise muss an dieser Stelle jedoch gesagt werden, dass bei einem Bauvorhaben, beispielsweise einem Bauvorhaben für ein Krankenhaus, unabhängig von der Anzahl der Änderungen, am Ende immer ein Krankenhaus und nicht zum Beispiel ein Freizeitpark entsteht. Bei der IT-Entwicklung dagegen, kann es durchaus vorkommen, dass man ein Projekt mit einem bestimmten Ziel startet und sich dieses Ziel im Laufe des Projekts massiv und grundlegend ändert.

IT-Projekte ermöglichen also eine iterative und/oder inkrementelle Bereitstellung. Diese Möglichkeit machen wir uns in folgendem Lebenszyklus zu Nutze:

Bei diesem Lebenszyklus gibt es keine echten Prognosen. Anstatt das Produkt zu prognostizieren (und sich auf diese Prognose zu verlassen), werden in kurzen Zeiträumen Produktinkremente erstellt. Jedes Inkrement (die neueste Version des Produkts) wird dem Kunden und den Benutzern vorgestellt. Die Aktivitäten im nächsten Zeitraum richten sich dann nach dem jeweiligen Feedback. Statt einer Prognose wird das Projekt also kontinuierlich weiterentwickelt und an das Feedback angepasst bzw. adaptiert. Daher auch die Bezeichnung adaptiver Lebenszyklus.

Um ein Inkrement zu erstellen, müssen alle Entwicklungsprozesse innerhalb einer bestimmten Zeitspanne ausgeführt werden. Im nächsten Zeitraum wird das Ganze dann wiederholt bzw. iteriert. Man nennt diese Methode der Entwicklung deshalb auch iterative Entwicklung. Die Zeitspannen, in denen diese Prozesse und Handlungen wiederholt werden, bezeichnet man auch als Iteration. Daneben gibt es noch eine weitere Bezeichnung, auf die wir aber später noch näher eingehen werden.

■ 1.2 PROGNOSTIZIERTE VERSUS ADAPTIVE LEBENSZYKLEN

Prognostizierte und adaptive Lebenszyklen haben beide Vor- und Nachteile. Die richtige Wahl hängt von vielen Faktoren ab. Der wichtigste Faktor ist jedoch die Art des zu erstellenden Produkts.

Stellen Sie sich die zwei folgenden grundlegenden Fragen, bevor Sie den für Ihr Projekt benötigten Lebenszyklus festlegen.

1. Muss ich mich flexibel anpassen? Lautet die Antwort auf diese Frage nein, dann eignet sich ein prognostizierter Lebenszyklus besser! Prognostizierte Lebenszyklen sind einfacher und strukturierter. Ein adaptives System ist in den Fällen erforderlich, in denen ein gewisses Risiko besteht, dass man bei Projektstart ein Krankenhaus bauen soll und zu guter Letzt eine Art Freizeitpark dabei herauskommt.

2. Kann ich mich überhaupt flexibel anpassen? Diese Frage ist sogar noch wichtiger. Wer anpassungsfähig sein möchte, muss die Möglichkeit zur iterativen Entwicklung und inkrementellen Bereitstellung haben. Denken wir noch einmal an unser Bauprojekt: Können Sie das Gebäude iterativ planen? Können Sie zum Beispiel nur das Fundament planen, ohne den Rest des Gebäudes zu entwerfen bzw. ohne die Lasten zu bestimmen, die das Fundament tragen muss? Die Antwort auf diese Frage ist einfach und lautet NEIN! Eine iterative Entwicklung ist bei Bauprojekten nicht möglich. Das Gleiche gilt, wie bereits erwähnt, für die inkrementelle Bereitstellung. Ein ada ist daher für den Bau eines Gebäudes nicht geeignet (bitte verwechseln Sie dies nicht mit Projekten in den Bereichen Innenarchitektur und -ausstattung oder gar Renovierung, für die adaptive Systeme durchaus in Frage kommen können).

Was ich hier vermitteln will ist, dass prognostiziert oder adaptiv keine Frage von gut oder schlecht ist.

Machen wir eine kleine Übung. Stellen Sie sich ein IT-System vor: Um für eine sehr große Organisation mit Niederlassungen an sechs Standorten eine Netzwerkinfrastruktur zu errichten, soll für das Betriebssystem der 300 Computer einer Organisation oder eines IT-Projekts ein Update durchgeführt werden. Welcher Lebenszyklus der IT-Entwicklung ist Ihrer Meinung nach für dieses Projekt besser geeignet?

■ 1.3 AGILE VERSUS WASSERFALL

Agile ist die populäre Bezeichnung für Systeme mit adaptiven Lebenszyklen. Diese Definition des Begriffs Agile ist viel besser als zu sagen „Agile ist eine Einstellung“.

Sprechen die Anhänger von agilen Methoden über prognostizierte Lebenszyklen (englisch: Predictive Lifecycles), verwenden sie die Bezeichnung Wasserfall. Dies gilt vor allem für IT-Projekte; kein Mensch würde sagen: „Dieses Gebäude wurde mit Hilfe der Wasserfallmethode gebaut.“

Um ganz sicherzustellen, dass Sie die Terminologie beherrschen, sollten Sie sich bewusst sein, dass das Wort Wasserfall inzwischen praktisch ein Unwort ist und dass Sie durchaus wütend und beleidigt reagieren dürfen, wenn jemand sagt, dass Sie die Wasserfallmethode verwenden! Ich schlage deshalb vor, dass wir uns in diesem Buch an die offizielle Bezeichnung halten und von prognostizierten Lebenszyklen sprechen.

■ 1.4 IST AGILE ETWAS NEUES?

Agile wird in der Regel als neue Methode beworben. Das Wort Agile für adaptive Lebenszyklen zu verwenden ist sicherlich neu, aber wie sieht es mit dem Lebenszyklus selbst aus?

Ich weiß nicht, wie es Ihnen geht, aber ich kann mir nur schwer vorstellen, dass die vielen Projekte und Programme in der langen Geschichte der Menschheit ganz ohne adaptive Lebenszyklen ausgekommen sind. Fällt Ihnen vielleicht ein Beispiel ein?

Ich kann Ihnen ein Beispiel nennen. Denken Sie einmal an eine in der Vergangenheit äußerst gängige Praxis (bzw. ein äußerst gängiges Projekt oder Programm): Krieg führen. Kann man einen Krieg mit einem prognostizierten Ansatz führen? Lässt sich alles von Anfang an planen und festlegen? Ganz bestimmt nicht. Zwar gibt es wahrscheinlich einen übergeordneten Plan, eher eine Art Strategie, aber den Krieg an sich müssen Sie Schlacht um Schlacht (d. h. in Iterationen) führen (manchmal werden möglicherweise mehrere Schlachten gleichzeitig gekämpft). Und je nach Ausgang der einzelnen Schlachten wird dann die Strategie für die weitere Kriegsführung flexibel angepasst.

Dieses Beispiel ist zwar kein angenehmes Thema, zeigt aber ganz klar, dass adaptive Ansätze nicht neu sein können.

Was also ist neu?

Irgendwann in der Vergangenheit wurden der so genannte wissenschaftliche Managementansatz und der Taylorismus zur Norm und jeder andere Ansatz galt als minderwertig oder sogar falsch. Da Taylorismus voll und ganz auf prognostizierten Systemen beruhte, dominierten diese Systeme sozusagen die ganze Welt.

Dann kam eine Zeit, in der immer mehr Projekte in der IT-Entwicklung initiiert wurden. Die prognostizierten Systeme waren für das Management dieser Projekte nicht wirklich die beste Lösung. Man versuchte zwar dies zu tolerieren, aber der Druck stieg und es kam zu Demonstrationen und schließlich zur Revolution! Und, wie das bei Revolutionen so üblich ist, frisst auch diese Revolution ihre Kinder, aber dazu ein andermal.

■ 1.5 DAS AGILE MANIFEST

Bald schon kamen die ersten adaptiven Systeme in der IT-Entwicklung zum Einsatz und wurden allmählich strukturiert und in reproduzierbare Managementsysteme überführt. 2001 schlossen sich dann einige Pioniere auf diesem Gebiet zusammen und erarbeiteten ein Manifest.

Beginnen wir mit dem Namen. Es wird erzählt, dass nach langen Beratungen zwei Möglichkeiten übrigblieben: Das Agile Manifest oder Das Adaptive Manifest. Leider fiel die Entscheidung auf Das Agile Manifest. Das Adaptive Manifest wäre die bessere Wahl gewesen, weil dies die Art der Herangehensweise beschreibt und viele Missverständnisse verhindert hätte.

Das Agile Manifest findet sich auf der äußerst fortschrittlichen und modernen Website AgileManifest.org und lautet wie folgt:

Leider wurde das Manifest selbst, nachdem es verfasst wurde, nicht mehr überarbeitet oder angepasst.

Der letzte Satz des Manifests bleibt häufig unbeachtet. Bitte lesen Sie das Manifest noch einmal durch und denken Sie dabei an den letzten Satz.

Überprüfen wir also die vier Wertaussagen:

Wertaussage 1: Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge

Ignoriert man die Bedeutung von Individuen und ihren Interaktionen, scheitert man in der Regel sehr schnell, denn schließlich werden Projekte von Menschen durchgeführt. Einige Manager glauben, sie könnten Probleme in diesen Bereichen mittels raffinierterer Systeme lösen, aber das funktioniert nur in den seltensten Fällen.

Schon viele von uns dachten naiv optimistisch, wir könnten mit tollen Werkzeugen Probleme lösen, die durch das Ignorieren menschlicher Aspekte entstanden sind, und mussten dann enttäuscht feststellen, dass dies nicht funktioniert. Manager geben nach wie vor enorme Summen für die Implementierung und Wartung solcher Werkzeuge aus und hoffen auf deren magische Wirkung. Tatsache ist jedoch, dass Werkzeuge Systeme nur unterstützen, aber nicht ersetzen können. Positiv ist zu vermerken, dass es sich bei diesen Werkzeugen um ausgeklügelte Softwareprodukte handelt, die in jahrelanger Arbeit entwickelt und instandgehalten werden und so viele Projekte und Jobs schaffen, die uns Investitionen ermöglichen, um über die Optimierung von IT-Entwicklungsprojekten nachzudenken.