Agile Projektmethoden fordern eine interdisziplinäre und iterative Arbeit in kleinen Zyklen. Die Umstellung auf diese Herangehensweise fällt vielen Projektteams sehr schwer – der "Big Design Up Front"-Gedanke sitzt tief in den Projektgenen.

Wie gelingt es aber, kleine, unabhängige Projekte aus einem großen Ansatz heraus zu denken? Wie können sich Teams pragmatisch die Forderung nach Iteration und Lernen erfüllen und sich von impliziten Vorstellungen über gute, vollständige Projekte lösen?

Die Autorin Judith Andresen gibt praktische Tipps für die Veränderung der Teamprozesse und des Projekt-Setups.

Wir neigen zu großen IT-Projekten. Je länger die Beteiligten über das anstehende Projekt nachdenken, desto größer werden die notwendigen Anforderungen. Die Featureliste nimmt kontinuierlich an Länge zu – und damit wird das Projekt auch immer größer. Wir möchten ein gutes, vollständiges Produkt abliefern. „Wenn wir das so machen, müssen wir aber etwas für den Fall XYZ vorsehen“. Getrieben von diesem Gedanken planen wir ein immer größeres Stück Software. Durch vorherige Projekte haben die Beteiligten nämlich einiges gelernt, dass sie nun umsetzen:

• Wenn die Projektbeteiligten jetzt ihre Features nicht „durchgedrückt“ bekommen, bekommen sie diese nie.
• Die versprochenen Nachfolgeprojekte zum Nachbessern werden immer wieder verschoben. Daher ist es wichtig, dass die eigenen Anforderungen im initialen Projekt enthalten sind.

Das vorherige Projekt geriet unter Zeit- und Qualitätsdruck. Wenn das ursprüngliche Feature zu klein angesetzt ist, drohte es während des Projekts auf die Streichliste zu kommen.

Mit jeder Anforderung steigt die Komplexität und damit der Umfang der Aufgabe stark an. Für die meisten sind Projekte nur dann perfekt, wenn sie vollumfänglich alle möglichen Features enthalten. Gleichzeitig steigt das Risiko des Scheiterns signifikant [1], wie das nachfolgende Diagramm zeigt, in der die Projektgröße in EUR gegen den Projekterfolg aufgetragen ist:

Ein überschaubarer Projektumfang und ein klarer Projektauftrag wären wünschenswert. Dennoch trauen sich viele Teams diesen (als radikal empfundenen) Schnitt nicht.

Damit Teams zukünftig seriell in kleinen, erfolgsversprechenden Schritten arbeiten, sind mehrere Schritte zu gehen:

• auf Organisationsebene: Fokus auf kleinem Projektumfang
  
• auf Teamebene durch angepasste Teamroutinen
  

Der Projektumfang kann dabei sowohl aus fachlicher als auch aus technischer Sicht überdimensioniert sein. Besonders vor Rewrites von Systemen ergibt sich die Größenfalle.

Die Beteiligten haben gerade gelernt, dass für das System ein derart hoher technischer Schuldenberg aufgehäuft wurde, dass ein Rewrite notwendig wurde. Daher muss das neue System aus technischer Sicht besonders solide und auf dem neuesten Stand entwickelt werden. Gleichzeitig haben die Beteiligten gelernt, dass in letzter Zeit auf Grund des Bearbeitungsstaus wenig fachliche Bewegung im System zu spüren war. Es muss sich Großes tun, damit der Stillstand beendet wird.

Als Ergebnis dieser Überlegung werden sowohl hohe technische als hohe fachliche Forderungen gestellt. Das Projekt wird von Beginn an zu groß gedacht. Keiner der Beteiligten stellt die Größe der Forderungen in Frage. Die Standish Group zeigte, dass nur 4% aller Rewrites in Time & Budget [2] sind. Die hohe Anforderungsdichte und die sich daraus ergebende technische Komplexität sind für die meisten Projektteams nicht meistern.

Aber auch bei Erweiterungs- oder Neuerstellungsprojekten verlieren die Beteiligten das Maß für das gut Machbare. Lange Featurelisten öffnen alle möglichen Wege zur Benutzung der Software. Alle Sonder- und Spezialfälle werden von Anfang an in der Software mitgedacht. Doch an Stelle einer aufwändigen, vollständigen Software würde häufig ein protoypisches Arbeiten, frühes Veröffentlichen und Überprüfen der Projektideen den Beteiligten helfen, die korrekten Schlüsse für ein gutes Produkt ermöglichen.

 „A minimum viable product has just those core features that allow the product to be deployed, and no more. The product is typically deployed to a subset of possible customers, such as early adopters that are thought to be more forgiving, more likely to give feedback, and able to grasp a product vision from an early prototype or marketing information“ [3]

Neben der einfacheren Bestimmung des Bedarfs am Markt reduziert das Arbeiten mit einem minimal viable product (MVP) auch die jeweilige Projektgröße. Die Chance steigt signifikant, dass die Beteiligten im Rahmen der definierten Projektparameter ihr Ziel erreichen.  

Die Annäherung an das MVP funktioniert mit der Leitfrage „Geht es noch einfacher?“ Es ist zulässig, Sonder- und Spezialfälle noch nicht programmautomatisch abzufangen, sondern den entsprechenden Nutzern und Nutzerinnen eine manuelle Bearbeitung anzubieten.

Durch eine frühe Veröffentlichung erhalten die Beteiligten auch ein realistisches Bild davon, welche Features von den Kunden und Kundinnen gut angenommen werden – und welche Anforderungen noch notwendig sind.

Entsprechend der Erkenntnisse und Rückmeldungen wird das Team in der nächsten Iteration eine passende Erweiterung vornehmen. Damit dies geschehen kann, erfolgt das Erheben der Daten (mögliche Kennzahlen ergeben sich aus der Nutzerzufriedenheit, Zugriffszahlen oder dem Umsatz) systematisch.

Zur Aufzeichnung eines MVP können Methodenbausteine wie „Lean Canvas“[4] oder „Impact Mapping“[5] helfen. Bei der Umstellung des Projektteams und der Organisation auf ein MVP ist auf einen neuen Methodenbaustein zu setzen. Nutzt das Team den bisherigen Methodenbaustein (z.B. ein Lastenheft oder eine Featureliste) zur Bestimmung des Projektkerns, wird mit der Routine des Methodenbausteins sich eine der bisherigen ähnliche Umfangsgröße einstellen.

Für viele Teams ist es leichter, einen kleinen Kern als MVP zu formulieren und nach und nach weitere Funktionen – auch gedanklich – hinzuzufügen. Das Verkleinern eines bereits formulierten, großen Projektziels fällt den meisten Beteiligten deutlich schwerer. Bei der Ausformulierung des MVP hilft der Grundsatz: „Good is enough“. An Stelle des perfekten, allumfassenden Produkts sucht das Team nach einem gut leistbaren Projektumfang.

Während sich „Geht es noch einfacher?“ der Leistungsreduktion „von oben“ nähert, liefert „Good is enough“ eine Näherung von unten. 

Wenn dass Team den Kern des Vorhabens erkannt hat, kann das "Lean Canvas" [4] helfen, das Projekt zu beschreiben. Die Methode kann für das MVP, Erweiterungen des Vorhabens oder allgemein für Features angewendet werden.

Das Lean Canvas bietet im Wesentlichen eine fachliche Sicht auf die Anforderungen und zwingt alle Beteiligten diese Anforderungen gut zu begründen. Diese Begründungen helfen bei der technischen Umsetzung und Priorisierung der nachfolgend zu erstellenden UserStorys.

Wenn das Projektteam Features und Erweiterungen mit jeweils einem Lean Canvas beschreibt, hilft es häufig, diese über ein Impact Mapping [5] in den Zusammenhang zu stellen.

Das Lean Canvas kann dabei Projektbeschreibungen ersetzen, die neben den fachlichen Anforderungen häufig bereits die technische Umsetzungsplanung enthalten.

Mit diesem Ansatz des sich nach und nach entwickelnden Produktes entsteht eine weitere Zumutung für die Organisation. Wir sind es nicht nur gewohnt, möglichst große Projekte zu konzipieren. Die gesamte betriebswirtschaftliche Planung und Absicherung erfolgt über den Projektbegriff [6]:

"Ein Projekt ist ein zielgerichtetes, einmaliges Vorhaben, das aus einem Satz von abgestimmten, gelenkten Tätigkeiten mit Anfangs- und Endtermin besteht und durchgeführt wird, um unter Berücksichtigung von Zwängen bezüglich Zeit, Ressourcen und Qualität ein Ziel zu erreichen."

Mit dem Ansatz eines wachsenden MVP, das UserStory für UserStory sich an die am Markt gebrauchte Lösung annähert, ist diese Definition und damit die verbundene Denkweise nur schwer zu vereinen. Wenn Budgetpläne im eigenen Haus erstellt werden, gilt es eine gute Projektvision aufzustellen und für einen Zeitrahmen festzulegen, den Ihr für das Unterfangen schätzt, um ein gutes Produkt zu erstellen. Wichtig ist es dabei, die Projektvision so zu formulieren, dass sie von den anderen Beteiligten akzeptiert werden kann.

 In vielen Fällen sehen entsprechende Budgetpläne neben einer fachlichen Beschreibung ("Was wollen wir erreichen?") auch eine technische Umsetzungsbeschreibung ("Wie werden wir das erreichen?" vor. An Stelle einer technischen Analyse ist hier ein Hinweis auf die Projektmethode zu setzen. Wenn diese Formulierung voraussichtlich nicht akzeptiert werden wird, sind große Vorab-Erläutuerungen oder ein "Just-Do-it" notwendig, wie es dieser Artikel noch beschreiben wird.

Ein Grund, der Projekte groß macht, ist häufig ein starker, technischer Unterbau. So wie wir Projekte mit einem "So wie beim letzten Mal" aufsetzen in der Projektmethode aufsetzen, setzen wir auch technische Projekte "so wie beim letzten Mal" auf. Das kann zu zu großen, schwer wartbaren Systemen führen.

Agile, emergierende Architektur entsteht mit dem Grundsatz "Infrastruktur wird gebaut, wenn sie gefordert ist". Dabei überlegt das Team für jedes Akzeptanzkriterium: "Was ist die einfachste Art, dieses Kriterium zu erfüllen?"

Die entsprechende Lösung wird mit der UserStory gebaut. Mit diesem Grundsatz wird der gewählte Ansatz deutlich schlanker und einfacher. Dabei werden womöglich nicht alle Risiko- und Sonderfälle sofort automatisch durch die Software gelöst. Das ist okay, denn "gut ist genug". Diese Fälle werden benannt und zum Beispiel manuell weiterverarbeitet. Für das zentrale Feature genügt es zu zeigen, dass es funktioniert -- und die zentralen Funktionen können bereits in Nutzertests überprüft werden.

Wenn sich herausstellt, dass die Risiko- und Nutzerfälle integriert werden müssen, werden die entsprechenden Anforderungen als UserStorys aufgenommen. Das Team kann sich wiederum eine passende technische Lösung überlegen. So wächst die Komplexität der Lösung mit der Komplexität der Anforderungen. Der Lösungsraum und der Anforderungsraum passen zueinander. 

Wir sind Gewohnheitstiere. Die Auseinandersetzung mit Dingen und Tätigkeiten jenseits des Vertrauten, Bekannten und Üblichen ist anstrengend. Rituale stützen uns – sowohl die positiven als auch die negativen. Denn Glückshormone werden im Gehirn geschüttet, wenn Vorausgesagtes tatsächlich eintritt. Jammern über schlechte Zustände ist also für den Einzelnen oder die Einzelne ein Gewinn – er beziehungsweise sie hat ja Recht in den Voraussagen und wird körperintern für die korrekte Voraussage belohnt.

Wenn wir viele vertraute und übliche Dinge tun, ist es wahrscheinlich, dass viele Voraussagen eintreffen. Wir handeln entsprechend – wir richten uns gerne in der Komfortzone ein.

 Veränderungsvorschläge hingegen liegen außerhalb der Komfortzone. Aussicht auf Belohnung besteht auch hier, wenn Voraussagen korrekt eintreten. Damit Menschen außerhalb ihrer Komfortzone agieren, muss die Chance auf Belohnung bestehen.  

Der einfachste Weg, eine veränderte Projektvorgehensweise einzuführen, ist: es einfach zu tun. Definiert Euer Minimum Viable Product und implementiert dieses einfach. Messt die Zeit vom Beginn bis zur ersten testbaren Version -- die Ergebnisse werden für sich sprechen.

Das bedeutet:

• Definiert nicht das ganze Projekt bereits in User Storys
  
• Definiert nicht eine vollständige Roadmap mit Releasezyklen
  
• Definiert nicht jedes Feature als Lean Canvas
  
• Definiert nicht die Featureabhängigkeiten in einem Impact Mapping
  

Sucht Euch einfach ein wichtiges, zentrales Feature, überlegt Euch den kleinsten Kern -- und baut das.

Diese Phase lässt sich gegegenenfalls als Prototyp-Phase deklarieren, wenn ein komplettes "Undercover-Just-Do-It" nicht möglich ist. In diesem Fall baut Ihr aber nicht nur einen technischen Prototypen, sondern Ihr lernt auch ein neues Projektvorgehen, in dem die Leitfragen

1. Gut ist genug
   
2. Geht es noch einfacher?
   

den Projektzuschnitt maßgeblich bestimmen. Mit diesem Vorgehen bringt Ihr Euch als Projektteam in die Lernzone. Ihr müsst noch nicht ein gesamtes Projekt klein schneiden, kleiner denken und Euch von einem großen Vorabdesign lösen. Alles, was Ihr schaffen müsst, ist:

1. Ein zentrales Feature zu bestimmen
   
2. einen Durchstich für dieses Feature zu definieren und
   
3. es einfach zu bauen.
   

Mit den Erfahrungen, die Ihr dort gesammelt habt, wird es leichter fallen, den für Euch richtigen Projektprozess aufzusetzen.

Beim Entwickeln dieses zentralen Features wird nur die Infrastruktur aufgesetzt, die genau dieses Feature fordert.  

Der Artikel ist eine Zweitveröffentlichung des gleichnamigen Artikel von Judith Andresen in der Zeitschrift "Windows Developer 03.2015". Abweichend vom Original ist die Anrede in diesem Artikel "Ihr", während im Zeitschriften-Artikel gesiezt wird.

• Nächster Artikel: Gebrauchte Neuland-FlipCharts zu verkaufen
• Vorheriger Artikel: Newsletter | Prozesse in Unternehmen verstehen