Nahezu jedes Software-Entwicklungsteam, das nach agilen Vorgehensweisen respektive mit Scrum arbeitet, antwortet auf die Frage, weshalb es das denn tue, mit Aussagen wie:

• Größere Nähe zum Kunden und dessen Anforderungen;

• schnellere Release-Zyklen und besser funktionierende Software;

• engere Zusammenarbeit mit dem Kunden und besserer Austausch.

Doch das ist nur eine Seite der Medaille. Hat eigentlich jemand schon mal gefragt, warum nicht viel mehr Teams nach agilen Vorgehensweisen arbeiten? Was sind die Vorbehalte, die einer agilen Arbeitsweise entgegen stehen? Diesen Hindernissen zu begegnen ist nicht immer ganz einfach.

(Teaserbild: Mikhail Tolstoy /Fotolia.com)

1: "Es gibt in Scrum keine Projektleiter."

Stimmt. Es gibt in Scrum-Projekten keinen Projektleiter, der die finanziellen und inhaltlichen Entscheidungen trifft und gleichzeitig weisungsbefugt ist für ein einzelnes Projekt-Teammitglied. Doch in Scrum gibt es einen Product-Owner, der einen Auftrag und ein Budget bekommt und in dessen Rahmen er inhaltliche und finanzielle Entscheidungen trifft. Er betreibt kein Mikro-Management. Doch er wählt Features und Anforderungen aus und priorisiert. Das Team organisiert sich selbst und entscheidet, wie Einträge aus dem Product Backlog umgesetzt werden. Der Product-Owner ist auch Ansprechpartner für alle Außenstehenden des Projekts.

2: "Die Selbstorganisation des Teams funktioniert nicht."

Stimmt manchmal. Einem Vogel, der bisher im Käfig gehalten wurde, wird auch nicht spontan das Überleben in der freien Natur gelingen. Doch es gibt Wege, solche Tiere gezielt und erfolgreich auszuwildern. Diese Metapher heißt übertragen: Teams, die bisher viele Weisungen erhalten haben, haben anfangs Schwierigkeiten, das Maß an Selbstorganisation und Selbstverantwortung zu finden, welche agile Vorgehensweisen fordern. Doch diese Teams können in Schritten erfolgreich Selbstorganisation und Selbstverantwortung so erlernen, dass sie anschließend erfolgreicher sind als vorher. Wichtig ist dabei, dass jedem Teammitglied die Projekt- und die Organisationsziele klar und transparent sind. Dann werden die einzelnen Beiträge eines jedes Teammitglieds für die Gruppe erfolgreicher sein als Anweisungen, die nur von einer Person kommen.

3: "Im regulierten Umfeld mit vielen Standards kann man nicht agil arbeiten."

Welche Arten von Regularien sind es und welchen Zweck haben sie? Normen, die es für Produkte gibt, etwa die der FDA für Medizinprodukte, können betrachtet werden wie andere Anforderungen an das System auch und damit ist es irrelevant, ob sie im agilen Rahmen umgesetzt werden oder nicht. Normen, welche die Arbeitsweise regulieren, gilt es zu hinterfragen. Welchem Zweck dienen sie? An welchen Stellen genau widersprechen diese Normen agilen Prinzipien, zum Beispiel in kurzen Iterationen zu arbeiten, schnell und erfolgreich Produkte zur Zufriedenheit des Kunden auszuliefern, eng mit dem Kunden zusammenzuarbeiten sowie Feedback-Mechanismen für das Team einzuführen (Retrospektiven in Scrum)? Vermutlich lässt sich keine Stelle finden, an der die Regularien genau diesen agilen Prinzipien widersprechen. Wieso dann nicht bewährte agile Werkzeuge und Methoden verwenden? Es lässt sich jedoch hinterfragen, welchem genauen Zweck die Forderung eines Prozesses dient und welche anderen Wege es gibt, die eigentlichen Prozessziele (reibungslose Zusammenarbeit, geringer Einarbeitungsaufwand, schnelle Fehlerkorrektur, gute Wiederverwendbarkeit) zu erreichen? Die entscheidende Frage ist also, wie die Ziele, die mit der Definition eines Prozesses angestrebt werden, erreicht werden können, ohne den Prozess-Overhead selbst zu haben.

4: "Unser Kunde ändert ständig seine Meinung, weshalb wir keine Architektur aufsetzen können."

Stimmt. Für jemanden, der ständig etwas anderes will, kann man kein Produkt entwickeln. Agile Vorgehensweisen unterstützen das Team jedoch sehr darin mit Kunden zusammen zu arbeiten, die anfangs nicht genau wissen, was sie wollen. Es fällt bei einer agilen im Gegensatz zu einer klassischen Methodik sehr viel früher auf, dass auf Seite des Kunden Unklarheiten und Unstimmigkeiten vorliegen. Ein agil arbeitendes Team hat dann sehr viel eher die Möglichkeit, diese Unklarheiten zu identifizieren und den Auftraggeber darin zu unterstützen, sich über seine Anforderungen klar zu werden. Ein agiles Team ist dazu gezwungen, sich über das Ziel des Projekts im Klaren zu sein. Sind diese Ziele anfangs nicht in ausreichender Notwendigkeit bekannt, forcieren agile Rahmenwerke wie Scrum, sich zunächst mit den Zielen und den Anforderungen des Kunden auseinanderzusetzen und auf eine Klarheit hinzuarbeiten. Die enge Zusammenarbeit mit dem Auftraggeber fördert diese Auseinandersetzung und bildet die Grundlage für eine gute Architektur. Wichtig ist es, diese Auseinandersetzung zu führen.

5: "Unser Auftraggeber will im Laufe des Projekts nicht mit uns reden."

Ja, das ist ein sehr großes Hindernis für ein agil agierendes Team. Denn agile Vorgehensweisen bedeuten immer auch eine größere Mitverantwortung des Auftraggebers. Es ergibt sich die Frage, ob dem Auftraggeber bewusst ist, dass er eine Mitverantwortung trägt am Erfolg des Projekts. Gelingt es dem Projektteam nicht, diese gemeinsame Verantwortung und den eigenen Wunsch nach Transparenz, Zusammenarbeit und Klarheit deutlich zu machen, bleibt die Frage, wie wichtig ist dem Auftraggeber das Projekt an sich. Sollte es überhaupt vollzogen werden? Diese Frage kann dem Auftraggeber gestellt und die Konsequenzen einer mangelnden Gesprächsbereitschaft können deutlich signalisiert werden. Im Gegensatz zu klassischen Vorgehensweisen ist es also für einen Auftraggeber sehr viel schwerer, sich aus der Projektverantwortung zu ziehen.

6: "Build-Zyklen und Integration sind zu kompliziert für eine Vier-Wochen-Iteration"

Hinter diesem Satz verbirgt sich oft die Aussage, dass das, was in eine Vier-Wochen-Iteration einfließt, nicht ausreicht für ein Release. Nun fordert aber kein agiles Vorgehen, dass mit jedem Iterationsende auch ein Release verbunden ist. Man kann also Vier-Wochen-Zyklen ohne ein abschließendes Release fahren. Komplizierte Integrationsmechanismen können durch inkrementelle Integrationsstrategien ersetzt werden, die auch eine Lokalisierung von Fehlern und Problemen bei der Integration erleichtern. Im Gegensatz zu einer Big-Bang-Integration treten Probleme und Fehler dann frühzeitig auf und die Überraschungen am Ende des Projekts halten sich in Grenzen.

7: "Wir können unsere Anwendungen nicht in Features herunterbrechen."

Dieses Argument höre ich häufiger und es ist für mich nicht verständlich. Keine Anwendung, die mit Software realisiert wird, ist in einem einzigen großen Schritt fertig. Es mag schwer fallen, eine Anwendung zu zerlegen. Doch was ist der erste Schritt, der zur Realisierung des großen Ganzen gegangen werden soll? Dieser erste Schritt ist ein erstes Feature, basierend auf dem Wissen, das zu Beginn vorliegt. Mehr braucht es anfangs nicht. Das ist eine große Erleichterung, weil sich das Team am Anfang nicht auf alles konzentrieren muss.

8: "Wie können wir dann den Aufwand abschätzen?"

Schätzen ist notwendig, um dem Auftraggeber Sicherheit zu geben und dieses Bedürfnis gilt es zunächst einmal zu respektieren. Allerdings ist auch zu fragen, wie sicher eine Schätzung wirklich zu welchem Zeitpunkt sein kann und wie realistisch es tatsächlich ist, eine bestimmte Schätzgenauigkeit zu erreichen. Der Lösungsumfang und Realisierungsaufwand lässt sich immer nur auf der Basis des bekannten Wissens schätzen. Da jedoch selten zu Projektstart alles bekannt ist, sind anfängliche Schätzungen sehr ungenau und instabil. Gute Schätzungen basieren auf Erfahrungen - je größer diese sind desto besser die Schätzung. Im Laufe eines agilen Vorgehens werden mit jedem Inkrement neue Erfahrungen gesammelt. Das bedeutet, dass die anfängliche sehr ungenaue Schätzung mit jeder Iteration immer genauer und besser wird. Wichtig ist an der Stelle also, es nicht bei der anfänglich ungenauen Schätzung zu belassen. Gleichwohl sollte man auch hinterfragen, ob der Aufwand, den eine Schätzung selbst einnimmt, gerechtfertigt ist.

9: "Warum Festpreis, wenn ich nicht genau weiß, was ich bekomme?"

Ein absolut nachvollziehbares Argument. Wer geht schon gern in einen Elektronikladen, zahlt einen festen Preis ohne die Garantie zu haben, ob das erworbene Gerät die notwendige Funktionalität bietet? Festpreise sind bei agil entwickelten Produkten verständlicherweise nahezu nicht zu vermitteln.

Doch wie wäre es mit einem anderen Preismodell? Ich wäre als Kunde durchaus bereit, für ein geplantes System erst einmal einen geringeren Preis zu zahlen, dafür nehme ich anfängliche Schwierigkeiten in Kauf, die ich nachbessern lasse beziehungsweise lasse neue Ideen in die Produktentwicklung einfließen. Konkreter formuliert: Bei diesem Preismodell bekommt der Kunde ausschließlich das, was er will und er zahlt auch nur das. Der Vertrauensvorschuss, den er gibt, gilt immer nur für eine Iteration und nicht bis ans Ende des gesamten Projekts. Damit wird auch das Sicherheitsbedürfnis des Kunden stärker erfüllt.

10: "Unsere Projekte sind zu groß für Agilität."

Ein Scrum-Team besteht typischerweise aus etwa sieben Mitgliedern. Große Projekte lassen sich mit solch einer Mitarbeiterzahl nicht abwickeln. Die Lösung ist dann, ein großes Projekt in einer Menge von kleineren Teams mit wenigen Schnittstellen nach außen zu organisieren. Daraus ergeben sich Fragen nach der Aufteilung. Die Koordination und Struktur der Teams sollte individuell entschieden werden. Wenn alle Teams sinnvollerweise mit einem Product Backlog arbeiten, kann bei fachlich strukturierten Teams nicht mehr jedes Team jede Aufgabe erledigen. Fachlich strukturierte Teams sind in einigen Organisationen sinnvoll, weil dort ausgeprägtes Expertenwissen bei Teammitgliedern vorhanden ist und der Einarbeitungsaufwand zu groß sein kann, um dieses Wissen in der Breite zu verteilen. In anderen Organisationen sind fachlich strukturierte Teams womöglich gar nicht notwendig und die einzelnen Teams können sich ohne weiteres aus dem Backlog bedienen. (ph)