Vor rund zehn Jahren führten wir mit großer Begeisterung bei der microTOOL GmbH, einem Berliner Softwarehersteller, agile Software-Entwicklung ein. Wir entwickelten die neue Version eines wichtigen Produkts nicht mehr nach traditionellen Vorgehensweisen wie Wasserfall oder "Command & Control", sondern mit eXtreme Programming (XP). Später führten wir Scrum ein und die Erfolge bestätigten uns in dieser Entscheidung. Noch vor drei Jahren hätte unser Erfahrungsbericht über agile Software-Entwicklung deshalb den Titel "Sieben Jahre agil – das hat sich gerechnet" getragen.

In den letzten drei Jahren wandelte sich jedoch unsere ursprüngliche Begeisterung in eine sehr differenzierte und kritische Sichtweise. Wir mussten lernen, dass eine rein agile Vorgehensweise langfristig betrachtet erhebliche Gefahren für die Qualität des Produkts birgt. Die Konsequenz hieß für uns allerdings nicht, zu den alten Methoden zurückzukehren, sondern Scrum so zu modifizieren, dass einheitliche Qualitätsstandards gewährleistet sind. Im Folgenden schildern wir unsere Erfahrungen mit agiler Software-Entwicklung und beschreiben unsere Lösung für das Dilemma zwischen Agilität und Produktqualität.

Ausgangspunkt: die Werte unserer Unternehmenskultur

Das mittelständische Unternehmen microTOOL ist auf die Entwicklung von Software-Werkzeugen für Requirements Engineering sowie integriertes Projekt- und Anforderungsmanagement spezialisiert. Vier grundlegende Werte prägen unsere Unternehmenskultur und damit auch unsere Vorgehensweisen bei Produktentwicklung und Projektmanagement:

Vertrauen der Kunden und Anwender

Wie bei allen Softwareproduzenten ist auch für uns das Vertrauen, das Kunden und Anwender uns entgegenbringen, ein zentraler Wert. Dieses Vertrauen zahlt sich letztlich in Lizenz-, Wartungs- und Dienstleistungsumsatz aus.

Qualität von Architektur und Code

Um Vertrauen zu gewinnen und dauerhaft zu erhalten, ist eine hohe Qualität der Software-Produkte unverzichtbar. Für uns spielt bei der Qualität von Architektur und Code die Erweiterbarkeit eine besondere Rolle. Durch sie haben wir den entscheidenden Wettbewerbsvorteil, kundenspezifische Anpassungen und Erweiterungen unserer Produkte anzubieten zu können.

Wissen und Erfahrung

Um Software mit hoher Qualität zu entwickeln, braucht man das Wissen und die Erfahrung von Mitarbeitern. Da Mitarbeiter wechseln, ist es notwendig, das Wissen im Unternehmen auch personenunabhängig zu halten. Dafür verwenden wir unter anderem ein Firmenwiki und Entwickler-Blogs. Aber dokumentiertes Wissen droht immer zu veralten. In den Algorithmen zur automatisierten Softwareproduktion steckt das Knowhow über die technische Architektur unserer Produkte, dies ist das wertvollste Wissen von microTOOL.

Kultur des Miteinanders und Soft Skills

Und schließlich ist für jedes Unternehmen die Kultur des Miteinanders wichtig: Wie wird kommuniziert? Wie werden Lösungen entwickelt? Wie löst man Konflikte? Wie geht man mit Krisen um? Brainstorming, moderierte Meetings zur Problemlösung, Software-Entwurf-Sessions im Team mit Metaplantechnik, Mediation bei Konflikten – das alles ist in der Unternehmenskultur von microTOOL heute verankert.

Diese vier Werte sind eng miteinander verknüpft. Wenn nur einer ins Wanken gerät, so sind unweigerlich auch die anderen gefährdet. Diese Werte haben unseren Weg stark beeinflusst, den wir mit der agilen Software-Entwicklung gegangen sind.

Erste Begegnung mit agilen Konzepten: XP vs. V-Modell

Im Jahr 2002 starteten wir ein Projekt mit dem Ziel, eine unterstützende Software für den Einsatz des V-Modells 97 zu entwickeln. Das V-Modell ist der deutsche Entwicklungsstandard für IT-Vorhaben der öffentlichen Hand – in der Version V-Modell 97 folgt es dem traditionellen Wasserfallmodell. Das derzeit aktuelle V-Modell XT erschien 2005 und enthält auch agile Vorgehensweisen.

Für die Entwicklungsteams war der Ansatz des V-Modells plausibel, so dass eine einheitliche und standardisierte Vorgehensweise bei der Software-Entwicklung die Qualität der Entwicklungsergebnisse verbessert. Aber alle waren sich darin einig, dass für Teamgrößen von drei bis zehn Entwicklern das V-Modell 97 ungeeignet ist, da es für große Projekte mit Auftraggeber und Auftragnehmer gedacht ist.