Der ultimative Leitfaden für die agile Softwareentwicklung

Projektmanagement ist eine komplizierte Sache. Es gibt endlos viele Methoden, Softwareoptionen, Rollen von Teammitgliedern und sich wandelnde Erwartungen, nicht nur innerhalb von Unternehmen oder Branchen, sondern auch im gesamten Betätigungsfeld Projektmanagement.

Es gibt kaum eine angebliche Prozessverbesserung, die von der Projektmanagement-Community nicht kritisch auseinandergenommen wird. Egal ob es darum geht, was agile Projektleiter oder Scrum-Master ausmachen sollte oder welche Projektmanagement-Software am besten für Unternehmen geeignet ist: Kaum jemals sind sich alle einig.

Trotz allem gibt es einen Trend, der seit 2015 – wenn nicht schon länger – beständig wächst: Agiles Projektmanagement gewinnt immer mehr an Bedeutung. Nicht zu Unrecht: Für die Softwareentwicklung zum Beispiel eignet es sich besonders gut.

Bei all den Diskussionen zu Fragen wie der Anpassung agiler Methoden oder Scrum vs. Kanban verliert man schnell aus den Augen, was agile Softwareentwicklung wirklich ist – und wie sie funktioniert.

Deshalb wollen wir uns heute die Zeit nehmen, einmal genau zu untersuchen, was Agile eigentlich ist und wie du deine Softwareentwicklung damit vorantreiben kannst.

In diesem Leitfaden für das agile Management geht es darum, wie die Methode entstanden ist, wie Entwicklungszyklen aussehen, welche Bedeutung die agile Entwicklung hat und welche Vor- und Nachteile sie bietet. Falls dich die Geschichte der agilen Methoden nicht interessiert und du gleich erfahren willst, wie agile Prozesse funktionieren, überspringe einfach den ersten Teil.

Der komplette Leitfaden für die agile Softwareentwicklung

Die Geschichte von Agile

Das Institute of Electrical and Electronics Engineers hat rudimentäre agile Projektmanagementmethoden bis ins Los Angeles des Jahres 1957 zurückverfolgt. Damals arbeiteten Bernie Dimsdale, John von Neumann, Herb Jacobs und Gerald Weinberg bei der Entwicklung von Software für IBM und Motorola eng zusammen. Craig Larman zitiert Weinberg in seinem Artikel „ Iterative and Incremental Developments. A Brief History“ (das Zitat haben wir aus dem Englischen übersetzt):

„Soweit ich mich erinnern kann, fanden alle von uns, dass das Wasserfallmodell bei sehr großen Projekten ungeeignet war oder zumindest die Realität verkannte. Die Wasserfall-Beschreibung ermöglichte uns etwas anderes: zu erkennen, dass wir etwas anderes taten, etwas, das außer ‚Softwareentwicklung‘ noch keinen eigenen Namen hatte.“

Das Wasserfallmodell war damals die vorherrschende Form des Projektmanagements. Es hängt eng mit Gantt-Diagrammen zusammen und zeigt auf, was an welchem Punkt in einem Projekt erledigt werden muss, damit es vorangeht.

Diese Methode machte die Softwareentwicklung unheimlich kompliziert. Das Wasserfallmodell basiert auf Vorhersehbarkeit und Abfolgen. Softwareentwickler*innen brauchen eine flexiblere Projektmanagement-Methode, die Raum für all die Fehler, Bugs, Rückschläge und Unabhängigkeit bietet, die für die Softwarebranche typisch sind.

Erst in den 1970er Jahren entstanden formalere Agile-Ansätze. Federführend waren Dr.  Ernest Edmonds,  Tom Gilb und das Systems Development Center der New York Telephone Company. Die Ideen fielen nicht gerade auf fruchtbaren Boden. Als Dr. Edmonds dem Journal of Computer Aided Design seine Vorstellungen präsentierte, wurden sie sogar rundheraus abgelehnt. Der einzige Kommentar, den die Zeitschrift Edmonds zurücksendete, lautete: „Wenn Sie nicht wissen, was Sie tun werden, bevor Sie damit anfangen, sollten Sie auch nicht anfangen!“ Edmonds wandte sich mit seiner Arbeit anschließend an General Systems, wo sie endlich akzeptiert wurde.

In den 1990er Jahren waren die Softwareentwickler mit ihrem Latein am Ende. Die neuen Programmierer*innen entstammten hauptsächlich der Generation X (geboren zwischen 1961 und 1983) und waren als „Schlüsselkinder“ Eigenständigkeit gewohnt. Gleichzeitig hatten sie ihre rebellische Teenagerzeit noch nicht ganz hinter sich gelassen, als sie ihre Arbeit aufnahmen, und brachten diese Haltung mit in die Büros. Craig Larman befand, dass die Entwickler*innen das Wasserfallmodell als „ überreguliert, reglementiert und äußerst kontrollierend“ empfanden. Es war für sie einfach nicht mehr das Richtige.

In den 1990er Jahren fanden viele unkomplizierte und vielseitige Projektmanagement-Methoden ihren Weg in die Softwareentwicklung, darunter die Dynamic Systems Development Method (DSDM), XP, Scrum und Feature-Driven Development (FDD). Auch wenn all diese Systeme älter sind als das agile Manifest, werden sie mittlerweile zur agilen Methodik gezählt.

Das agile Manifest

Vom 11.–13. Februar 2001 trafen sich im The Lodge im Snowbird Ski Resort 17 Personen, die drei Dinge gemeinsam hatten: Spaß an gutem Essen, die Liebe zum Skifahren und den Wunsch nach einer Alternative zu auf Dokumentation basierenden, schwerfälligen Softwareentwicklungsprozessen. Noch heute bezeichnen sie sich ganz ohne Ironie als „organizational anarchists“. Bei diesem Treffen unterzeichneten alle Teilnehmer das Manifest für Agile Softwareentwicklung, das auf vier Konzepten aufbaut:

• „Individuen und Interaktionen stehen über Prozessen und Werkzeugen.
• Funktionierende Software steht über einer umfassenden Dokumentation.
• Zusammenarbeit mit dem Kunden steht über der Vertragsverhandlung.
• Reagieren auf Veränderung steht über dem Befolgen eines Plans.“

Zur Geschichte des agilen Manifests schreibt Mitgründer Jim Highsmith (Original auf Englisch):

„Um in der neuen Wirtschaft Erfolg zu haben und in der Zeit von E-Business, E-Commerce und Internet aggressiv voranzuschreiten, müssen Unternehmen sich von obskuren Richtlinien und Beschäftigung um der Beschäftigung willen frei machen. Diese Freiheit von den Bedeutungslosigkeiten der Unternehmenswelt zieht Befürworter der agilen Methoden an und ist für Traditionalisten beängstigend. Offen gesagt: Agile Ansätze jagen Unternehmensbürokraten Angst ein – zumindest denen, die gerne Prozesse um ihrer selbst willen vorantreiben, anstatt zu versuchen, das Beste für „den Kunden“ zu tun und „wie versprochen“ zeitnah etwas Greifbares zu liefern, wenn sie sich nirgends mehr verstecken können.

Die agile Bewegung ist nicht methodenfeindlich. Im Gegenteil: Viele von uns wollen die Glaubwürdigkeit des Wortes „Methoden“ wiederherstellen, eine Balance wiederherstellen. Wir befürworten Modelle, aber nicht das Erstellen von Diagrammen, die dann einfach in verstaubten Unternehmensarchiven verschwinden. Wir befürworten Dokumentation, aber nicht Hunderte von Seiten, die nie gepflegt und selten genutzt werden. Wir planen, aber wir erkennen die Grenzen der Planung in einer turbulenten Umgebung an. Wer Befürworter von XP, Scrum oder anderen agilen Methoden als „Hacker“ bezeichnet, hat weder die Methoden noch die ursprüngliche Bedeutung des Begriffs „Hacker“ verstanden. “

Das agile Manifest betont, dass keiner der Autoren an ein Patentrezept glaubt. Das macht es umso schwieriger, zu definieren, was Agile eigentlich bedeutet: Die Gründer glauben weder, alle Antworten zu kennen noch dass es die eine, für jedes Entwicklungsteam gleichermaßen perfekte Methode gibt. Ihr Ansatz ist zwangsläufig sehr liberal. Wie sie selbst oft genug betonten, geht es ihnen darum, anderen zu helfen und nicht darum, Vorschriften zu machen. Sie wollen andere mit agilen Methoden unterstützen und gleichzeitig selbst von ihnen lernen.

Vielleicht ist es genau dieser Ansatz, der ihr System so erfolgreich macht und dazu geführt hat, dass es sich durchsetzte.

Agile gewinnt an Popularität

Ab 2001 stieg die Zahl der aus agilen Methoden entstehenden Projektmanagementprozesse rasant an. Nach kurzer Zeit entstanden Agile Alliance und Scrum Alliance und 2001 wurde der Klassiker Agile Software Development with Scrum herausgegeben. Certified Scrum-Kurse wurden in der Welt der Projektmanager genauso allgegenwärtig wie Begriffe wie „Scrum-Master“ und „Selbstorganisation“. 2007 schrieb IBM:

„Agilität ist überall. Wer sie ignoriert, geht im technischen Diskurs von heute verloren. Wenn Sie sich Wissen dazu aneignen, können Sie fundiert entscheiden, ob sie für Sie das Richtige ist. So gewinnen Sie außerdem Verständnis für zahlreiche weitere aufstrebende Praktiken und Methoden. Wenn Sie im Technologiemanagement tätig sind – egal auf welcher Ebene – ist dies nicht nur Ihre Verantwortung, sondern auch eine Voraussetzung für Ihr Überleben. “

Heute, 10 Jahre später, werden agile Methoden in ihren zahlreichen Ausprägungen in der Softwareentwicklung nahezu standardmäßig eingesetzt.

Agile Softwareentwicklung

„Agiles Projektmanagement“ ist ein Sammelbegriff, der allein in der Softwareentwicklung unterschiedlichste Methoden umfasst. Dazu gehören:

• Adaptive Software Development (ASD)
• Crystal
• Dynamic Systems Development Method (DSDM)
• Extreme Programming (XP)
• Feature-Driven Development (FDD)
• Kanban (je nach Verwendungsart)
• Lean
• Scrum

Auch wenn es sich hierbei um unterschiedliche Softwareentwicklungsmethoden handelt, wollen wir uns in diesem Artikel nur damit beschäftigen, was sie beim Thema Agile verbindet. Dieser Abschnitt ist nach den vier Hauptüberzeugungen des agilen Manifests  gegliedert.

1. Individuen und Interaktionen stehen über Prozessen und Werkzeugen

Egal wie man es dreht und wendet, es sind Menschen, die Software entwickeln, keine Computerprogramme oder Rädchen im Getriebe eines Unternehmens.

Nicht falsch verstehen: Agile Projektmanagement-Software ist eine großartige Ressource für Projektmanager*innen. Diese Art von Projektmanagement-Software bietet Tools, um die Kommunikation zu verbessern, für das Bug Tracking und zum Planen von Softwareveröffentlichungen. Aber Software allein kann ein gutes Team nicht ersetzen. VersionOne erläutert (Übersetzung von uns):

„Wir sollten miteinander interagieren, zusammenarbeiten, Details erarbeiten, uns einvernehmlich auf Dinge einigen, Fragen stellen, miteinander zu Mittag essen, uns besser kennenlernen und Vertrauen und Bindungen stärken. Es geht um die Interaktion von Angesicht zu Angesicht. In der neuen agilen Welt, in der wir leben, müssen wir sozialer sein als in der Vergangenheit, um Software zu produzieren. Und das wird sich auch nicht mehr ändern. Wer sich in der Hoffnung für den IT-Bereich entschieden hat, hier nicht mit Menschen zu tun haben zu müssen, hat jetzt möglicherweise ein Problem. Ja, wir alle brauchen immer noch Zeiten, in denen wir unsere Ruhe haben und uns konzentrieren können. Dafür gibt es bestimmte Bereiche, die zum fokussierten Arbeiten gedacht sind. Die meisten Unternehmen wissen, wie wichtig das ist, und bieten entsprechende kleine Bereiche außerhalb der Team-Räume an. Außerdem geben sie den Angestellten Laptops oder Tablets statt Desktop-PCs. Diese Mobilität macht es einfacher, bei Bedarf einfach woanders hinzugehen, um ungestört zu sein. Ironischerweise bietet sie gleichzeitig auch bessere Möglichkeiten zur Zusammenarbeit. “

Anders gesagt: Die Leute in Snowbird wollten zwar eine Methode zur Softwareentwicklung entwerfen, aber deren Fokus sollte auf dem Team liegen. Das ist ihnen nicht ohne Grund am allerwichtigsten. Der Gedanke dahinter ist, dass sich Teams, die nicht zusammenarbeiten, zwangsläufig langsamer an Rückschläge anpassen und sich somit damit schwertun, hochwertige, marktreife Software zu entwickeln.

Agile Teams, die diesen Wert in den Vordergrund stellen, profitieren hingegen idealerweise von diversen Vorteilen:

• Die Kommunikation zwischen Teammitgliedern ist schnell, klar und effizient.
• Zwischen den Teammitgliedern besteht eine enge Verbundenheit, die eine wirkungsvolle Teamarbeit ermöglicht.
• Alle Prozesse sind flexibel genug, um sich an neue Ereignisse und sich ändernde Umstände anpassen zu können.
• Die Teammitglieder fühlen sich für ihre jeweiligen Projektbereiche verantwortlich und frei in ihrer Gestaltung.
• Alle Teammitglieder werden ermutigt, Innovationen zu wagen und Risiken einzugehen.

2. Funktionierende Software steht über einer umfassenden Dokumentation

In großen Unternehmen, staatlichen Behörden oder auch Teams mit übereifrigen Leitenden passiert es schnell, dass halbe Tage der Dokumentation gewidmet werden.

Das findest du übertrieben?

Wie oft hast du schon einen langen Ausgabenbericht angefertigt, auf eine Genehmigung vom Management oder der Geschäftsführung gewartet, um mit einer Aufgabe weitermachen zu können, oder einfach konzentriert für einen Kunden zu arbeiten? Klingt das nicht irgendwann ziemlich ermüdend und wie eine eher schlechte Voraussetzung für Innovationen?

Leider ist es so – und Befürworter agiler Methoden wollen dieses Hindernis aus dem Weg schaffen.

Agile Teams streben an, den Dokumentationsaufwand so gering wie möglich zu halten. Jedes Dokument sollte die Produktentwicklung unterstützen – und sonst nichts.

Statt sinnlos Stunden damit zu verbringen, alles zu erfassen, was getan wurde und geschehen wird, konzentrieren sich agile Teams auf das eigentliche Produkt. Dabei gehen sie nicht das Produkt als Ganzes an, sondern stellen die Funktionalität in den Mittelpunkt.

Stell dir beispielsweise ein Haus vor.

Bei traditionellen Methoden würden Bauleiter*innen mithilfe von Baumanagement-Software auswerten, wie weit das Projekt fortgeschritten ist. Wenn beispielsweise das Fundament gelegt ist, der Rohbau steht und Hausverkleidung, Isolierung und Verkabelung fertig sind, wäre das neue Haus zu etwa 65 % fertig. Allerdings ist dieses Haus noch nicht bewohnbar: Die Arbeit am Haus ist zu 65 % erledigt, aber aktuell hast du null fertige Häuser.

In der agilen Softwareentwicklung bedeutet „65 % fertig“, dass das gesamte Projekt zu 65 % erledigt ist. Bei Software heißt das: Die wichtigsten Teile der Software sind fertig. Erledigt. Abgeschlossen. Betriebsbereit. Wenn etwas nicht fertig ist, sollte das Team es in Iterationen so lange erneut bearbeiten, bis es vollendet ist.

Agile Teams, die diese Werte in den Vordergrund rücken, profitieren idealerweise von diversen Vorteilen:

• Die Teams verbringen viel mehr Zeit mit der Entwicklung als mit der Dokumentation.
• Anforderungen sind klar dokumentiert und bilden die Grundlage für die Softwareentwicklung.
• Teammitglieder überprüfen regelmäßig gemeinsam den Code.
• Softwaredesigns unterliegen iterativen Revisionsprozessen.
• Projektfunktionen sind erst „fertig“, wenn sie erstellt, getestet, qualitätsoptimiert und genehmigt wurden.

3. Zusammenarbeit mit dem Kunden steht über der Vertragsverhandlung

Dieser dritte Punkt beschreibt ein Konzept agiler Methoden, das häufig missverstanden wird.

Die Zusammenarbeit mit Kunden ist nicht immer formlos und selbstverständlich haben auch agil arbeitende Teams Verträge mit den Stakeholdern. Gleichzeitig geht es im agilen Bereich jedoch darum, Missverständnisse und Fehlkommunikationen zu vermeiden, weshalb der Produktivität der Zusammenarbeit eine höhere Bedeutung zugesprochen wird als dem Wiederkäuen alter, erledigter Konflikte. Mit Software wie

Wer agile Methoden nutzt, ist sich dessen bewusst, dass ein erster Vertrag nicht immer genau das wiedergibt, was ein Stakeholder eigentlich will. Iterative, agile Vorgehensweisen sind auch deshalb so beliebt, weil die Stakeholder ihre Anforderungen anpassen können, wenn die Features und Funktionen Gestalt annehmen.

So bestärkt Agile flexible Vertriebsoptionen: Ein festes Budget verhindert möglicherweise ein optimales Software-Ergebnis, da man nicht im Vorhinein sagen kann, wie viele Iterationen nötig sein werden, damit alles wirklich gut funktioniert. Eine flexiblere Herangehensweise sorgt letztendlich für ein besseres Produkt und zufriedenere Kunden.

Idealerweise profitieren agile Teams dabei gleich mehrfach:

• Verträge legen den Umfang und Starttermin von Projekten fest.
• Zugunsten einer höheren Produktqualität können Verträge flexibel geändert werden.
• Änderungen an Verträgen erfolgen einzig zu dem Zweck, die Qualität des Produkts zu verbessern oder die Kundenzufriedenheit zu erhöhen.
• Die Verantwortung für den Projekterfolg liegt gleichermaßen beim Kunden und beim Team.
• Es erfolgt eine ständige Kommunikation zwischen Kunden und Team. Iterationen und Änderungen werden regelmäßig besprochen.

4. Reagieren auf Veränderung steht über dem Befolgen eines Plans

Die Gründer der agilen Bewegung störten sich an der Starrheit traditioneller Projektmanagement-Methoden. Ihr Ziel war es, ein deutlich flexibleres System zu erschaffen. Die von ihnen entwickelten Prinzipien betonen daher besonders die Wichtigkeit von Flexibilität und einer schnellen Reaktion auf veränderte Bedingungen.

Es gibt viele Faktoren, die dazu führen können, dass ein Produkt sich in eine andere Richtung entwickelt als ursprünglich angedacht. Dazu gehören beispielsweise:

• Änderungen am Budget oder Vertrag.
• Änderungen der öffentlichen Meinung.
• Verändertes Wissen darüber, wie das Endprodukt aussehen soll.
• Änderung der Stakeholder.

Für Unternehmen, die ein fertiges Produkt schaffen wollen, bedeuten Änderungen meist Probleme. Daher ersetzt Agile herkömmliche Fälligkeitstermine durch Burndown-Charts, Retrospektiven, Risikobewertungen oder Story Card Lifecycles. Agile will allen Teammitgliedern die nötigen Tools zum erfolgreichen Priorisieren, Planen und Einarbeiten unvorhergesehener Änderungen an die Hand geben.

Letztendlich soll jede neue Herausforderung das Projekt weiterbringen, statt ein Hindernis darzustellen.

Agile Teams, die diese Werte in den Vordergrund stellen, profitieren idealerweise von diversen Vorteilen:

• Teammitglieder können leicht auf Änderungen am Projekt reagieren.
• Änderungen sind vorhersehbar.
• Teams können Fortschritte genau nachverfolgen und wissen, was bereits erledigt ist.
• Die Planung erfolgt kontinuierlich vom Start bis zum Ende des Projekts.
• Der Gesamtstatus des Projekts und die nächsten Schritte sind für alle Teammitglieder transparent und nachvollziehbar.

Der agile Softwareentwicklungszyklus

Wie bereits erwähnt, gibt es die unterschiedlichsten Arten agiler Softwareentwicklung, doch allen gemein sind die vier oben genannten Prioritäten. Egal ob du Scrum, XP, Crystal, Feature-Driven Development oder andere agile Methoden nutzt, die grundlegende Herangehensweise bleibt gleich.

1. Starte das Projekt.
2. Definiere, worin das Projekt und seine Ziele bestehen.
3. Erstelle Richtlinien für die Projektanforderungen.
4. Entwickle eine Softwarefunktion.
5. Integriere die Funktion.
6. Teste die Funktion.
7. Wenn der Test erfolgreich ist: Fahre mit der nächsten Funktion fort und wiederhole Schritte 4–6.
8. Wenn der Test nicht erfolgreich ist: Dokumentiere, was fehlgeschlagen ist, und implementiere Änderungen, bis die Funktion funktioniert.
9. Überdenke und priorisiere Funktionen neu, wenn Kundenfeedback und neue Herausforderungen es erfordern.
10. Veröffentliche die marktreife Funktion, sobald sie getestet und integriert wurde.
11. Fahre mit der Entwicklung der nächsten Funktion fort und wiederhole Schritte 4–6, bis das Projekt beendet ist.

Ein besonders gelungenes Beispiel findet sich auf der Website der ISTQB Exam Certification. Dort wird die iterationsweise Entwicklung eines Textverarbeitungsprogramms beschrieben. Jede Iteration verbessert die vorherigen Funktionen und fügt neue Funktionen hinzu, während gleichzeitig alle Iterationen aufeinander aufbauen. Jede Iteration ist wie ein neues Produkt, das die vorherige Iteration als Grundlage nutzt.

Überlegungen zur agilen Softwareentwicklung

Agile Entwicklungsmethoden liegen momentan im Trend, doch wie bei allen anderen Projektmanagement-Techniken gibt es Vor- und Nachteile.

Vorteile der agilen Softwareentwicklung

Agile Methoden bieten sieben zentrale Vorteile:

1. Fokus auf Qualität

Wenn die Softwareentwicklung in kleine Abschnitte zerlegt wird, ist es für Projektteams sehr viel einfacher, sich auf das Testen und Überprüfen jeder einzelnen Iteration zu konzentrieren. Außerdem können agile Teams Software-Bugs in kurzer Zeit finden und beheben.

2. Fokus auf den Kunden

Bei Agile liegt die kontinuierliche Veröffentlichung qualitativ hochwertiger Software im Fokus. Das Feedback und die Zufriedenheit der Kunden wirken sich unmittelbar auf die Produktentwicklung aus.

3. Fokus auf Transparenz und Kommunikation

Die agile Softwareentwicklung konzentriert sich auf die Zusammenarbeit und die Einbindung der Nutzer. Alle Stakeholder aus allen Projektbereichen geben aktiv Feedback zur Software.

4. Fokus auf Flexibilität

Projektmanager können problemlos Prioritäten ändern und neu festlegen, was für das Produkt wichtig ist – selbst wenn sich das jede Woche ändert. Noch nicht erreichte Ziele können mühelos in spätere Iterationen übernommen werden.

5. Fokus auf Geschwindigkeit

Dank regelmäßiger Veröffentlichungen haben Softwareentwickler jederzeit einen Teil eines fertigen Produktes vorliegen. Die Geschwindigkeit ist der größte Pluspunkt von Agile: Der neunten State of Agile Survey [PDF] zufolge besteht der am häufigsten genannte Vorteil agiler Methoden in der beschleunigten Produkteinführung.

6. Fokus auf Risikominimierung

Projektmanager*innen können sich über Iterationen an eine sich verändernde Softwareumgebung anpassen. Mit inkrementellen Softwareveröffentlichungen lassen sich Bugs und Probleme frühzeitig erkennen, bevor das Produkt fertiggestellt wurde und Bugfixes umso schwieriger werden.

7. Fokus auf die Verwaltung schlanker Budgets

Wenn die Projektkosten in kleinere Abschnitte (oft als Sprints bezeichnet) aufgeteilt werden, lassen sie sich einfacher prognostizieren. Außerdem können Teams so bezahlt werden, sobald einzelne Veröffentlichungen fertig sind.

Nachteile der agilen Softwareentwicklung

Agile ist eine großartige Option für viele Softwareentwicklungsteams, aber es muss nicht zwingend für jedes Team das Richtige sein. Bevor du agile Projektmanagement-Methoden einführst, solltest du auch die möglichen Nachteile kennen.

1. Agile ist weniger ideal für Regierungsbehörden und Großunternehmen

Eine ausführliche Dokumentation ist bei agilen Methoden nicht gewollt und sie erfordern eine umfassende Transparenz. Für weniger flexible Unternehmen sind sie daher eher hinderlich.

2. Eventuell überlagern anstehende Lieferungen die Qualität

Wenn ständig neue Software-Iterationen erwartet werden, kann es schnell passieren, dass die Qualitätssicherung dabei zu kurz kommt.

3. Änderungskosten werden ignoriert

Lajos Moczar bemerkt in CIO: „Häufig führen Leute zu einem späten Zeitpunkt noch sehr große Änderungen durch und denken sich, das Projekt müsse das verkraften, da es sich schließlich um ein agiles Projekt handelt. Allerdings klappt das nur, indem Iterationen hinzugefügt werden. Fehler, die anfangs unkompliziert waren, werden dadurch häufig immer schwieriger zu beheben, weil sich der zugrunde liegende Code ständig ändert.“

4. Agile funktioniert schlecht bei Teams, die streng beaufsichtigt werden wollen

Agile ist ein großartiger Produktentwicklungsprozess für kleine Teams, die gut zusammenarbeiten. Wenn in einer IT-Abteilung jedoch ständig eine große Zahl an Teammitgliedern gemanagt werden muss, scheitert das ganze System häufig am schwächsten Glied in der Kette.

5. Agile erfordert Übung

Dem State of Agile Report zufolge ist der Hauptgrund für das Fehlschlagen agiler Projekte fehlende Erfahrung mit agilen Methoden. Wasserfallmethoden fürs Projektmanagement sind intuitiv nutzbar, wohingegen das Erlernen agiler Methoden etwas Zeit braucht.

Fazit

Die agile Softwareentwicklung ist mehr als nur eine Projektmanagement-Mode. Es handelt sich um eine eigene Projektmanagement-Disziplin mit klaren Vorteilen, vor allem für IT-Teams. Bei diesen Methoden stehen Transparenz, iterative Prozesse, Kommunikation die Qualität des Endprodukts im Vordergrund.

Ich bin neugierig, was du darüber denkst: Nutzt du selbst agile Methoden? Habe ich etwas vergessen zu erwähnen? Erzähl es in den Kommentaren!

Suchst du nach Projektmanagement-Software? Wirf einen Blick auf Capterras Liste der besten Projektmanagement-Softwarelösungen.