Klassisch vs. agil vs. bimodal: Die richtige Methode wählen

Klassisches Projektmanagement basiert oft auf dem Wasserfall- oder dem V-Modell. Beiden gemeinsam ist, dass die Teams schon im Vorfeld – häufig mit großem Aufwand – alle Anforderungen und den Umfang der zu entwickelnden Lösung präzise festlegen müssen. Zuständigkeiten werden verteilt, aufeinander aufbauende Projektphasen und Meilensteine eingeplant, die durchgehende Dokumentation geregelt und das Budget abgestimmt. In Lasten- und Pflichtenheften oder in einer gemeinsamen Requirements-Spezifikation halten Kunde und Auftragnehmer alle relevanten Aufgaben fest und klären das Konzept der fertigen Lösung detailliert. Soweit sich die Anforderungen, Leistungen und Abläufe vorab genau beschreiben lassen, verspricht ein solches Modell viel Klarheit und Verlässlichkeit.

In Laufe der Umsetzung stellen Projektleiter jedoch häufig fest, dass sich die Anforderungen noch ändern, dass Projektphasen nicht klar voneinander abzugrenzen sind oder Zeit und Budget falsch geplant wurden. Zugleich aber sind klassische Modelle naturgemäß recht starre Konstrukte. Daraus kann sich eine Kombination aus Schwierigkeiten ergeben:

• Die geplante Lösung entspricht nicht den realen Anforderungen im Produktivalltag.
• Umfangreiche Nachforderungen machen die Lösung deutlich teurer als geplant.
• Durch eine überlange Entwicklungszeit ist das fertige Produkt inhaltlich oder funktionell veraltet.

Die teilweise gravierenden wirtschaftlichen Folgen brachten Entwickler-Teams dazu, neue Vorgehensmodelle zu erproben: die agile Softwareentwicklung.

Das oberste Ziel der neuen Agilität: Der Kunde bekommt schon früh eine produktive und seinen Vorstellungen entsprechende Teillösung. Funktionserweiterungen, Patches oder Sicherheitsupdates folgen regelmäßig und in kurzen Abständen. Anstatt die Kundenwünsche vorab in einem Pflichtenheft zu fixieren, werden sie während des Prozesses priorisiert, spezifiziert und Änderungen flexibel umgesetzt. Es wird also nicht von einer finalen Lösung aus gedacht, sondern man treibt kleine, kontinuierliche Erweiterungen voran. Selbstorganisierte, interdisziplinäre Teams entwickeln solche Projekte in kurzen Zyklen, sogenannten Sprints. In den Sprints werden Elemente der klassischen Softwareentwicklung (Anforderungsanalyse, Design-Änderung, Implementierung, Tests) für einzelne Softwarebestandteile und Funktionen vielfach wiederholt – auch während Lösungsteile schon produktiv eingesetzt werden.

Agile Ansätze und ihre Flexibilität lassen sich aber nicht einfach verordnen. Idealerweise verinnerlichen alle Mitarbeiter – nicht nur das Management oder einzelne Teams – die agilen Prinzipien. Ihre typischen Vertreter, wie eXtreme Programming (XP) oder Scrum, verlangen sowohl von den Entwicklern als auch von den Kunden, grundlegend umzudenken: Ohne eine fixierte Zielsetzung brauchen die Entwicklerteams ein durchgehendes Kunden-Feedback. Für die Entwickler bedeutet das, sich auf umfassende Transparenz einzulassen und die Kundenseite als Teil des Teams zu verstehen. Umgekehrt muss der Kunde aktiv mitarbeiten und steuernd auf das Projekt einwirken. Außerdem sollte er sich darauf einstellen, dass die Inhalte zum Projektstart nicht formal festgelegt sind.

Wie alle Vorgehensmodelle, bieten auch agile Methoden keine Erfolgsgarantie. Typische Probleme können sein:

• Die Dokumentation der kontinuierlichen Änderungen wird zu lax gehandhabt.
• Wichtige Informationen zu Schnittstellen oder Modifikationen sind nicht transparent.
• Die flexible Anforderungsdefinition erschwert es, Projekte zum Festpreis anzubieten.

Wer die „richtige“ Methode sucht, sollte nach der „passenden“ Methode Ausschau halten – abhängig von den existierenden Bedingungen und Bedürfnissen aller Beteiligten. So ist es nicht unbedingt sinnvoll, ein bislang funktionierendes Team, das zufriedene Kunden mit klassisch entwickelten Produkten versorgt, zwangsweise auf Agilität zu trimmen. Nur wenn sich alle Akteure auf agile Modelle einlassen, kann der Ansatz zur Unternehmenskultur werden.

In der Realität verfolgen Unternehmen selten eine Vorgehensweise in Reinkultur. So sperren sich auch klassische Modelle nicht gegen den Einsatz von agilen Elementen. Zum Beispiel können über Prototyping schon in frühen Phasen lauffähige Softwareteile ausgeliefert werden und ein schnelles Feedback zur Entwicklungsrichtung bringen. Und etwas Agilität steckt ohnehin in den meisten Projekten, um zwangsläufig auftauchende Änderungen zügig zu integrieren. Aber auch eine Trennung nach Projektart ist denkbar: Unternehmen behalten für gewachsene und etablierte Bestandssysteme einen klassischen Ansatz. Bei Neuentwicklungen, die neue Geschäftsfelder adressieren und von Innovation und Tempo leben, wählen sie den agilen Modus. Für solche gemischten Modelle haben die IT-Analysten von Gartner den Begriff Bimodale IT in die Welt gesetzt.

Ob innerhalb eines Projektes oder aufgeteilt über verschiedene Projekte: Bimodale IT versucht immer, die größten Vorteile aus beiden Welten zu kombinieren. Für das Requirements-Management kann das bedeuten, dass bestimmte Anforderungen mit klarer Priorität versehen werden. Hier würde eine agile Entwicklung zum Zuge kommen, mit schnellen ersten Ergebnisse und unmittelbarem Feedback. Auch auf diesem Weg lässt sich Softwareentwicklung mit hoher Geschwindigkeit und Qualität verwirklichen.

Zurück zur Übersicht