Welche Projektmethode passt zu Ihrem Team?
Kommentare

Agile Projektmethoden fordern eine interdisziplinäre und iterative Arbeit in kleinen Zyklen. Vielen Projektteams fällt es schwer, sich auf diese Herangehensweise umzustellen. Der „Big-Design-Up-Front“-Gedanke sitzt tief in den Projektgenen. Wie gelingt es aber, kleine, unabhängige Projekte aus einem großen Ansatz herauszudenken? Wie können Teams auf pragmatische Weise die Forderung nach Iteration und Lernen erfüllen und sich zugleich von impliziten Vorstellungen in Bezug auf gute, vollständige Projekte lösen? Dieser Artikel gibt praktische Tipps für die Veränderung der Teamprozesse und des Projekt-Set-ups.

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 ihre Features nicht jetzt „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. Wurde das ursprüngliche Feature zu klein angesetzt, 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 so signifikant, wie das Diagramm in Abbildung 1 zeigt, in der die Projektgröße (in Euro) gegen den Projekterfolg aufgetragen ist.

Abb. 1: Je kleiner die Projektgröße ist, desto eher wird das Projekt gelingen

Abb. 1: Je kleiner die Projektgröße ist, desto eher wird das Projekt gelingen

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

Damit Teams künftig seriell in kleinen, erfolgsversprechenden Schritten arbeiten, sind zwei Schritte zu gehen: Auf Organisationsebene sollte der Fokus auf einen kleinen Projektumfang gesetzt werden. Auf Teamebene ist es notwendig, angepasste Teamroutinen umzusetzen.

Kleine Projektumfänge zunächst Herausforderung

Der Projektumfang kann dabei sowohl aus fachlicher als auch aus technischer Sicht überdimensioniert sein. Insbesondere vor „Rewrites“ von Systemen kann es leicht passieren, dass Teams in die „Größenfalle“ tappen.

Die Beteiligten haben gerade erfahren, 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 festgestellt, dass in letzter Zeit aufgrund 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 Überlegungen werden sowohl hohe technische als auch 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 vier Prozent aller Rewrites innerhalb der vorgesehenen Zeit und des angesetzten Budgets erfolgen. Die hohe Anforderungsdichte und die sich daraus ergebende technische Komplexität sind für die meisten Projektteams nicht zu meistern.

Aber auch bei Erweiterungs- oder Neuerstellungsprojekten verlieren die Beteiligten das Maß dafür, was zu schaffen ist. Lange Featurelisten öffnen alle möglichen Wege zur Benutzung der Software. Alle Sonder- und Spezialfälle werden von Anfang an mit bedacht. Häufig würde es den Beteiligten helfen, nicht direkt in die Erstellung einer aufwändigen, vollständigen Software überzugehen, sondern zunächst prototypisch zu arbeiten und die Projektideen früh zu überprüfen und zu veröffentlichen. So würde es möglich, frühzeitig die korrekten Schlüsse für ein gutes Produkt zu ziehen.

„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“ (Quelle: Wikipedia) Neben der einfacheren Bestimmung des Bedarfs am Markt reduziert das Arbeiten mit einem „Minimal Viable Product“ (MVP) auch die jeweilige Projektgröße. Die Chance, dass die Beteiligten ihr Ziel im Rahmen der definierten Projektparameter erreichen, steigt so signifikant.

Geht es noch einfacher?

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

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

Entsprechend der Erkenntnisse und Rückmeldungen wird das Team in der nächsten Iteration eine passende Erweiterung vornehmen. Hierzu ist es notwendig, die Daten systematisch zu erheben (Abb. 2) Mögliche Kennzahlen ergeben sich aus der Nutzerzufriedenheit, den Zugriffszahlen oder dem Umsatz (Abb. 2).

Abb. 2: Das Minimal Viable Product ergibt sich im Zyklus „Planen“, „Erfolg messen“ und „Lernen“

Abb. 2: Das Minimal Viable Product ergibt sich im Zyklus „Planen“, „Erfolg messen“ und „Lernen“

Zur Aufzeichnung eines MVP können Methodenbausteine wie „Lean Canvas“ oder „Impact Mapping“ 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 zur Bestimmung des Projektkerns (z. B. ein Lastenheft oder eine Featureliste), kann es vorkommen, dass sich im Zuge der Routine mit dem Methodenbaustein eine Umfangsgröße einstellt, die den bisherigen ähnlich ist.

„Good is enough“

Für viele Teams ist es leichter, einen kleinen Kern als MVP zu formulieren und nach und nach weitere Funktionen – auch gedanklich – hinzuzufügen, als ein bereits formuliertes, großes Projektziel im Nachhinein zu verkleinern. Bei der Ausformulierung des MVP hilft der Grundsatz: „Good is enough“. Anstelle eines perfekten, allumfassenden Produkts sucht das Team nach einem gut leistbaren Projektumfang.

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

Lean Canvas

Wenn das Team den Kern des Vorhabens erkannt hat, kann das „Lean Canvas“ helfen, das Projekt zu beschreiben. Die Methode kann für das MVP, Projekterweiterungen oder allgemein für Features angewendet werden (Abb. 3).

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

Wenn das Projektteam Features und Erweiterungen mit jeweils einem Lean Canvas beschreibt, hilft es häufig, diese über ein „Impact Mapping“ in Zusammenhang zu stellen. Das Lean Canvas kann dabei Projektbeschreibungen ersetzen, die neben den fachlichen Anforderungen häufig bereits die technische Umsetzungsplanung enthalten.

Projekt oder Prozess?

Mit diesem Ansatz des sich nach und nach entwickelnden Produkts entsteht eine weitere Herausforderung für das Unternehmen. Wir sind es nicht nur gewohnt, möglichst große Projekte zu konzipieren. Die gesamte betriebswirtschaftliche Planung und Absicherung erfolgt über den Projektbegriff: „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.“ (Projektdefinition: Wikipedia).

Mit dem Ansatz eines wachsenden MVP, das sich User Story für User Story an die am Markt benötigte Lösung annähert, ist diese Definition und die damit 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, der nach eigener Schätzung notwendig ist, um ein gutes Produkt zu erstellen. Wichtig dabei ist, die Projektvision so zu formulieren, dass sie bei allen Beteiligten Akzeptanz findet.

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. Anstelle einer technischen Analyse ist hier ein Hinweis auf die Projektmethode zu setzen. Ist abzusehen, dass die Formulierung nicht akzeptiert werden wird, sind umfangreiche Voraberläuterungen oder ein „Just do it“ erforderlich.

Nur geforderte Infrastruktur bauen

Eine Komponente, die Projekte groß macht, ist häufig ein starker, technischer Unterbau. So wie wir Projekte mit einem „So wie beim letzten Mal“ in der Projektmethode aufsetzen, setzen wir auch technische Projekte mit „so wie beim letzten Mal“ auf. Das kann 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 User Story 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. Aber wir erinnern uns: „Gut ist genug“. Diese Fälle werden benannt und beispielsweise manuell weiterverarbeitet. Bezüglich des zentralen Features genügt es zu zeigen, dass es funktioniert – die zentralen Funktionen können bereits in Nutzertests überprüft werden.

Stellt sich heraus, dass die Risiko- und Nutzerfälle integriert werden müssen, werden die entsprechenden Anforderungen als User Stories 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.

Projektveränderung heißt: Alle müssen ihr Verhalten ändern

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 ausgeschüttet, wenn Voraussagen – einschließlich der negativen – tatsächlich eintreffen.

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

Veränderungsvorschläge hingegen liegen außerhalb der Komfortzone. Damit Menschen außerhalb ihrer Komfortzone agieren, muss die Chance auf Belohnung bestehen (Abb. 4). Folglich muss die Wahrscheinlichkeit, dass Voraussagen korrekt eintreten, gegeben sein.

Realistische Veränderungen liegen in der Lernzone. Das ist ein enger Bereich um die Komfortzone herum – vieles gilt noch aus der Komfortzone, nur wenige Dinge oder Regeln haben sich geändert. In diesem schmalen Band um die vertrauten Verfahren herum sind wir in der Lage, Veränderung sicher zu vollziehen.

Ein zu großer Schritt bringt uns in die Panikzone. Alle, die sich in der Panikzone befinden, bewegen sich ohne Rücksicht auf andere Beteiligte so schnell wie möglich in die Komfortzone zurück.

Die Gefahr, die Grenze zur Panikzone zu überschreiten, gilt für alle Teammitglieder. Denn große Veränderungsanliegen katapultieren viele Teammitglieder gleichzeitig in die Panikzone. Entsprechend ist eine revolutionäre Veränderung, also eine Veränderung, die vieles gleichzeitig massiv verändert, im Grunde nicht denkbar. Es sei denn, die mit der Veränderung kommende Belohnung ist so groß, dass jeder Einzelne bereit ist, die Panikzone für eine kurze Zeit zu tolerieren. Dies ist selten der Fall. Evolutionäre Bewegung hingegen ist leichter im Team zu bewerkstelligen. Durch kleine und wenige Veränderungen wirkt das Team in der Lernzone – alle können gemeinsam ihre Komfortzone vergrößern und das neue Verhalten ins Repertoire aufnehmen.

Änderungswiderstand in Bezug auf die Einführung agiler Projekte ist häufig zu beobachten. Die Entwicklungsteams begrüßen die Beteiligung im Prozess; gleichzeitig fordern sie aber explizit ausführliche User Stories mit genau ausdefinierten Akzeptanzkriterien.

An Verhaltensweisen wie diesen kann man erkennen, dass die ursprünglich eingeführte Änderung zu groß oder zu wenig erklärt worden ist.

Damit Projektteams mit ihrem ersten „Minimal Viable Product“ nicht in diese Falle tappen, sollten die Beteiligten Erfolge sprechen und keine unnötigen Diskussionen aufkommen lassen, die das Vorgehen gefährden.

Just do it!

Der einfachste Weg, eine veränderte Projektvorgehensweise einzuführen, ist, es einfach zu tun. Definieren Sie Ihr Minimum Viable Product und implementieren Sie es einfach. Messen Sie die Zeit vom Beginn bis zur ersten testbaren Version. Die Ergebnisse werden für sich sprechen. Das bedeutet:

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

Suchen Sie sich einfach ein wichtiges, zentrales Feature, überlegen Sie sich dazu den kleinsten Kern und bauen Sie es. Diese Phase lässt sich gegebenenfalls als Prototypphase deklarieren, sofern ein komplettes „Undercover Just do it“ nicht möglich ist. In diesem Fall baut man aber nicht nur einen technischen Prototyp, sondern erlernt auch ein neues Projektvorgehen, in dem die Leitsätze „Gut ist genug“ und „Geht es noch einfacher?“ den Projektzuschnitt maßgeblich bestimmen.

Mit diesem Vorgehen bringen Sie sich als Projektteam in die Lernzone. In dieser müssen Sie noch kein gesamtes Projekt klein schneiden, kleiner denken oder sich von einem großen Vorabdesign lösen. Alles, was Sie schaffen müssen, ist, ein zentrales Feature zu bestimmen, einen Durchstich für dieses Feature zu definieren, und es einfach zu bauen. Beim Entwickeln dieses zentralen Features wird nur die Infrastruktur aufgesetzt, die genau dieses Feature fordert. Mit den Erfahrungen, die Sie in der Lernzone gesammelt haben, wird es leichter fallen, den für Sie richtigen Projektprozess aufzusetzen.

Abb. 4: Die Lernzone ist ein enger Bereich um die Komfortzone

Abb. 4: Die Lernzone ist ein enger Bereich um die Komfortzone

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -