ISB intern

Softwareprojekte – modern ausgeführt

Agile Steuerung – (k)ein Gegensatz?

Wandel und Einflussfaktoren

Nichts ist beständiger als der Wandel – auch die Art und Weise, wie wir unsere z.T. mehrjährigen Kundenprojekte abwickeln. Während lineare Projektmanagementansätze eine fundierte Planung und ingenieursmäßige Durchführung von Softwareprojekten als zentrales Erfolgskriterium sahen, führen eine immer schneller voranschreitende Digitalisierung verbunden mit einer zunehmenden Vernetzung zu erheblich veränderten Anforderungen an die Softwareentwicklung: Software wird als ein treibender Motor gesehen, um den Veränderungsdruck, der auf ganzen Geschäftsprozessen lastet, zu bewältigen. Permanente Anpassungen an neue Marktanforderungen, eine rasche Umsetzung von Vorgaben und Gesetzen werden zunehmend als selbstverständlich betrachtet. Die Auswirkungen der Corona-Krise haben diese Entwicklung erheblich beschleunigt. Hier wird „von der EDV“, d.h. sowohl von Ihnen, unseren Kunden, als auch von uns als Projekthaus tagtäglich eine Lösung erwartet. Dies stellt Herausforderungen an die Abwicklung von Softwareprojekten, die mit herkömmlichen Methoden nur unzureichend zu bewältigen sind – gefordert ist somit eine große Flexibilität in einem dynamischen Umfeld.

Deshalb möchten wir im Folgenden einen modernen Ansatz zur Durchführung und Steuerung von Softwareprojekten vorstellen. Dazu ist es aber notwendig zunächst etwas tiefer in die Anforderungen und Rahmenbedingungen einzusteigen.

Die geforderte Flexibilität und Dynamik in Softwareprojekten ist mit einem seriellen, planungsgetriebenen (ingenieursmäßigen) Ansatz nicht mehr zu erreichen. Ein agiles, inkrementelles Vorgehen bietet für diese Fragestellung einen bewährten und etablierten Ansatz: Die Flexibilität und Dynamik in Projekten kann beispielsweise mittels Scrum maßgeblich erhöht und im Projektalltag etabliert werden.

Gleichzeitig muss aber die Steuerbarkeit auch hinsichtlich Zeit und Budget insbesondere im Kontext unserer Kundenprojekte erhalten bleiben, d.h. wir müssen weiterhin Termine, Kosten, Mitarbeitereinsatz u.v.m. abschätzen und planen können. Nur so wird eine frühzeitige Prüfung und ggf. Steuerung im Projekt ermöglicht – ganz dem Deming-Cycle verpflichtet (s.u.). Eine Antwort auf die Frage „Wann bekomme ich was geliefert und zu welchem Preis?“ müssen Sie und wir weiterhin gegenüber unseren Auftraggebern beantworten können.

Doch hier ergeben sich Kontrapunkte zwischen den verschiedenen Anforderungen: Während Stabilität und Planbarkeit ehemals als zentrale Paradigmen der Projektarbeit herausgehoben wurden, werden sie heutzutage eher als Schwäche wahrgenommen und durch die Forderung nach Flexibilität und Anpassbarkeit ersetzt. Oder überspitzt ausgedrückt: Was früher als stabiler Projektplan galt, war oftmals nur eine Fiktion – und hat eine (vermeintliche) Sicherheit vermittelt, die der Projektrealität oftmals nicht standgehalten hat und im Ergebnis zu einer Vielzahl von Changes, Terminverschiebungen etc. geführt hat.

Es soll hier nicht der Eindruck vermittelt werden, dass die Forderung nach einer höheren Dynamik und Flexibilität alleine mittels Projektmanagement oder einem neuen Vorgehensmodell realisiert werden kann – die alleinige Diskussion „Agil vs. Wasserfall“ (zugespitzt in der Ausprägung „Scrum oder nicht Scrum?“) greift nach unserem Verständnis zu kurz. Wir müssen vielmehr die Projektabwicklung insgesamt in Richtung Veränderung und Flexibilität ertüchtigen.

Heute beantworten wir die Frage: Wie können wir uns der Herausforderung Flexibilität bei gleichzeitiger Steuerbarkeit stellen?

… das Rad neu erfinden?

Zurück zur Ausgangsfrage: „Wie managen wir Softwareprojekte in einem dynamischen Umfeld bei gleichzeitigem Erhalt der Plan- und Steuerbarkeit“? Dazu müssen wir das Rad nicht neu erfinden – es existieren bereits leistungsfähige, etablierte Antworten:

Hinsichtlich der „Behandlung“ von Dynamik in Softwareprojekten bietet das agile Manifest eine klare Orientierung: Softwareentwicklung wird als flexibler Ansatz interpretiert, der eine hohe Dynamik realisiert. Wir setzen dabei mit Scrum auf einen der bekanntesten und etabliertesten Ansätze – ein inkrementelles, iteratives Vorgehen, welches ursprünglich aus der Produktentwicklung stammt. Scrum wird schon seit langer Zeit erfolgreich in unseren Projekten eingesetzt.

Allerdings adressiert Scrum unserer Meinung nach nicht vollständig die Anforderungen, mit denen wir in unseren Kundenprojekten konfrontiert werden: Wir sehen die Notwendigkeit, die agilen Vorgehensweisen bzw. Scrum mit einem Projektmanagementrahmen zu versehen, um Steuerbarkeit, Verlässlichkeit etc. sicherzustellen, beispielsweise um Abweichungen vom Projektziel frühzeitig zu erkennen und entsprechende Maßnahmen zur Steuerung zu aktivieren. Deshalb haben wir neben einem agilen Vorgehen als weiteren Baustein das Vorgehensmodell PRINCE2® identifiziert – eine weltweit führende Projektmanagementmethode, welche in der Ausprägung PRINCE2 Agile den klar definierten Rahmen von PRINCE2® mit der Flexibilität und Reaktionsfähigkeit einer agilen Methode kombiniert. Wir möchten jedoch nicht sklavisch an den Vorgehensmodellen festhalten, sondern mit dem Anspruch „von Praktiker für Praktiker“ die beiden Methoden Scrum und PRINCE2® kombinieren. Zusammen mit unseren langjährigen Erfahrungen ergibt dies ein leistungsfähiges Vorgehensmodell. Weitere Prinzipien und Methoden vervollständigen dieses Vorgehensmodell, wie beispielsweise der Ansatz der produktorientierten Planung.

Produktorientierte Planung

Unser Vorgehen stellt das zu erstellende Produkt ins Zentrum, einschließlich des damit verbundenen Nutzens. Somit ist der Kern für eine erfolgreiche Zusammenarbeit zwischen Ihnen als Auftraggeber und uns als Auftragnehmer ein klares und einheitliches Verständnis über den zu erzielenden Nutzen des Produkts, die zeitlichen Meilensteine sowie die kritischen Erfolgsfaktoren – oder anders ausgedrückt: DieZusammenarbeit wird dann erfolgreich werden, wenn die Ziele gemäß der Produktvision und des fachlichen Bezugsrahmens erreicht werden und Sie als Kunde den erwarteten Nutzen aus den Projekten ziehen können.

Wie in Abbildung 2 dargestellt, sehen wir für die Ausführung eines erfolgreichen Vorhabens, eine produktorientierte Planung und Steuerung des Gesamtvorhabens auf verschiedenen Ebenen vor:

  • Oberste Ebene ist die Vision (Produkt- oder Projektvision). Diese beschreibt den Zustand, der am Ende des Projektes erreicht werden soll. Betrachtet wird die Geschäftssicht einschließlich des damit verbundenen Nutzens. Dazu gehört aus unserer Sicht (und aus Sicht von Prince 2) immer auch ein Business Case, der den Invest gegen den Nutzen bzw. ROI rechtfertigt.
  • Abgeleitet davon zeigt die Produkt- und Umsetzungsstrategie, in welchen Stufen welche Teile des Produkts im Markt bzw. bei unseren Kunden eingeführt werden können oder auch müssen, beispielsweise auf Grund von gesetzlichen Vorgaben. Als Ergebnis kann beispielsweise ein Product-Backlog resultieren.
  • Nun gilt es im nächsten Schritt den Releaseplan zu entwickeln, welcher die Vorgaben aus der Produktstrategie mit der Sprintplanung (und damit den tatsächlichen Möglichkeiten) kombiniert. Es wird der Funktionsumfang mit einem realistischen, zeitlichen Rahmen zusammengeführt. Daraus resultiert ein verbindlicher Releaseplan. Dazu stellen wir nachfolgend eine interessante Priorisierungsmethode vor (Stichwort MVP weiter unten in diesem Artikel).
  • Die konkrete agile Methode wie beispielsweise Scrum (in grün dargestellt) wird in den Projektrahmen eingebettet und jeweils iterativ ausgeführt – es resultiert ein konkreter Sprint Plan, der bei Bedarf bis auf eine Tagesplanung heruntergebrochen werden kann.

Unser Verständnis von einem erfolgreichen Projekt und einer erfolgreichen Zusammenarbeit besagt, dass Auftraggeber und Auftragnehmer während der Dauer des gesamten Projektes immer die oben genannten Ebenen im Blick haben, ihre Projektsteuerung einschließlich des Berichtswesens danach ausrichten und dies im Rahmen einer abgestimmten, ebenenübergreifenden Zusammenarbeit ausführen. Diese Ebenen erzeugen Planbarkeit, ohne dass hierfür Abstriche an Flexibilität oder Dynamik gemacht werden müssten.

Eine isolierte Betrachtung nur auf Sprintebene bringt aus unserer Sicht die Gefahr mit sich, dass ein Prozess oder ein Teilmodul „zu tief gelegt wird“, während am Ende des zur Verfügung stehenden Zeitraums oder Budgets essenzielle Funktionen in einem anderen erfolgskritischen Teil fehlen. Die Herausforderung ist, immer wieder den Zoomfaktor in den Steuerungsebenen zu variieren: Wenn wir vom Business Case kommend auf die Details in den Sprints zoomen, um dann wieder die Extrapolation der Erkenntnisse aus den Sprints heraus auf die höheren Planungsebenen vollziehen, erfassen wir die Projektsteuerung im vollen Umfang.

Planungs- und Priorisierungsmethode mittels MVP

Der gesamte Planungsablauf ist nachfolgend in etwas anderer Weise veranschaulicht: Auf Basis der Produktvision und Produktstrategie wird die Struktur des Lösungsprodukts (Product Breakdown Structure oder PBS) abgeleitet, die schließlich in einem priorisierten und mit einer Grobschätzung versehenen Product-Backlog aufgeht. Mit der anschließenden Releasebildung erfolgt auch die Projektion in die Zeitachse und damit eine erste Terminplanung.

Eine große Herausforderung in der Projektarbeit stellt oftmals der durchaus valide Anspruch dar, ein perfektes Produkt zu entwickeln. Dies führt meist zu überbordenden Anforderungen und zu komplexen Produkten: In der Absicht, alle Anwenderanforderungen auf einmal und mit dem ersten Produktrelease zu erfüllen, entsteht potenziell ein teures Produkt, welches viele Funktionen enthält, die nicht oder nicht im realisierten Maße benötigt werden (Featuritis). Die entsprechenden Projekte werden tendenziell schwergewichtiger, länger und teurer als zwingend notwendig. Um dies (sehr überspitzt) bildlich darzustellen, haben wir nachfolgende Darstellung gewählt:

Deshalb ist der Ansatz nach dem Minimum Viable Product (MVP) entstanden – frei übersetzt das minimal funktionsfähige Produkt: Im Rahmen der Projektvision haben wir eine Vorstellung entwickelt, welchen Nutzen wir mit einem Projekt erzeugen möchten und als Business Case hinterlegt bzw. durch zwingende gesetzliche Vorgaben und zwingend zu erreichende Businessziele festgelegt.

Dem Ansatz des MVP‘s liegt folgende Fragestellung zu Grunde: Was muss ich mindestens liefern, damit der Business Case „gerade noch aufgeht“ bzw. die Kern- oder Minimalziele des Projekts, die Rechtfertigung für den Auftrag und für die Gewährung der Mittel waren, erfüllt werden. Wichtig ist, dass damit nicht der vollständige Projektumfang definiert wird, sondern ein schlankes Produkt im Release 1.0 entsteht und frühzeitig an die Endanwender geliefert werden kann. Das hat einige bemerkenswerte Vorteile:

  • Erste Funktionen kommen baldmöglichst zu den Endanwendern – der Nutzen des Projekts kann früh realisiert werden. Das Projekt kommt aus dem Phantom-Status langer Konzeptionszeiten heraus und liefert frühzeitig greifbare Ergebnisse.
  • Wir erreichen weiterhin eine sehr frühe Rückmeldung der Endanwender auf die Umsetzung und können dies in den weiteren Phasen als fundierte Verbesserungsvorschläge einfließen lassen.
  • Der Blick für das Wesentliche, auf das, was den eigentlichen Projekterfolg ausmacht, wird permanent geschärft.

An dieser Stelle begegnet man manchmal der Frage, ob ein MVP nicht ggf. Muss-Kriterien des Kunden aufweicht. Nein, aus unserer Sicht dient ein MVP gerade dazu, sich der Muss-Kriterien zu vergewissern, sie regelmäßig zu prüfen, abzusichern und von Anforderungen abzugrenzen, die eine geringere Priorität haben.

Selbstverständlich gehört dazu auch der Mut, mit einem noch nicht mit allen Komfortfunktionen ausgestatteten Produkt an den Markt zu gehen. Dies wird aber nach unserer Erfahrung kompensiert, wenn wir in einer geplanten und auch kommunizierten weiteren Produktpflegephase gemeinsam mit den Endanwendern das Produkt weiterentwickeln – eine in der täglichen Praxis erarbeitete und bewährte Lösung ist oft wesentlich besser als eine am Reißbrett entworfene Software. Es bietet ferner das Potenzial, den „Ballast“ bisheriger Lösungen und Vorgehen über Bord zu werfen.

Wir konzentrieren uns hier nun aber auf den Projektrahmen in einem agilen, dynamischen Umfeld, der das notwendige Maß an Planbarkeit und Kalkulierbarkeit bietet, ohne die Flexibilität aufzugeben. Ausgehend von der Produktvision, dem Business Case und der darauf aufbauenden Produktorientierten Planung des Gesamtvorhabens steht nun die konkrete zeitliche Planung und Steuerung des Gesamtvorhabens auf verschiedenen Steuerungsebenen an.

Hierzu wollen wir uns noch mal vertieft der Frage stellen: Wie können wir die Produktorientierte Planung in ein Steuerungs- und Phasenmodell einbetten, welches ebenfalls die gewonnene Flexibilität und Dynamik nicht einschränkt?

Steuerungs- und Phasenmodell

Rekapitulieren wir kurz, wie wir von der anfänglichen Produktvision auf Basis eines Business Cases über die Produktorientierte Planung zu einer Releaseplanung gelangt sind, die es uns erlaubt, unser Kernprodukt (MVP) termin- und budgetgerecht im Markt einzuführen, dann fällt auf, dass wir das Gesamtvorhaben sowohl „horizontal“ in verschiedenen Abstraktionsebenen als auch „vertikal“ auf der Zeitachse in Zwischenreleases für die Bestandteile unseres Produkts unterteilt haben. Die verschiedenen Abstraktions- und Aggregationsebenen sowie die resultierenden Phasen erlauben eine iterative Konkretisierung der Planung und des Produkts, ohne das Gesamtbild aus dem Auge zu verlieren. Dies korrespondiert und harmoniert sehr gut mit agilen Methoden sowie dem Arbeiten mit priorisierten Backlogs.

Kombiniert mit dem MVP-Ansatz werden je Ebene und Phase

  • Minimalanforderungen definiert, um jederzeit sicher zu stellen, dass die Kernziele erreicht werden
  • Puffer und Toleranzbereiche festgelegt, um auf allen Ebenen und in jeder Phase Freiraum für eigenverantwortliches Handeln und Reaktion auf Veränderungen zu ermöglichen
  • Akzeptanzkriterien definiert, die dem jeweiligen Aggregationsund Abstraktionslevel entsprechen und so sicherstellen, dass von der untersten Ebene der einzelnen inkrementellen Liefergegenstände bis hin zur Ebene des Gesamtprodukts ein kontinuierlicher Qualitäts- und Anforderungsabgleich erfolgen kann.

Hierzu werden konkret 3 Steuerungsebenen eingeführt (vgl. Abbildung 3):

  • Lenken
  • Managen
  • Liefern 13

Auf der Lenkungsebene ist der Business Case und das Gesamtprodukt im Blick. Auf der Ebene Managen werden die Releases und damit das Produkt und seine Teilprodukte auf strategischer Ebene geplant und gesteuert.

Auf der Ebene Liefern erfolgt die iterativ, inkrementelle Erstellung der Liefergegenstände. Auf der Zeitachse, also vertikal, wird das Projekt zunächst in vier Hauptphasen (analog des Prince 2 Phasenmodells) untereilt:

  1. Vorbereitung
  2. Initialisierung
  3. n Produktionsphasen
  4. Abschlussphase

 

Auf die Inhalte und Übergänge der einzelnen Phasen gehen wir in einem Folgeartikel noch vertieft ein. An dieser Stelle ist wichtig, dass in der Vorbereitungsphase wesentlich die Produktvision entwickelt und der dazugehörige Business Case aufgestellt werden muss.

Die Initialisierungsphase enthält alle Tätigkeiten, damit das Projekt von den Stakeholdern und damit dem Lenkungskreis freigegeben werden kann. Dazu gehört u.a. die vertragliche Ausgestaltung, die initiale Produktorientierte Planung (POP) und die Befüllung des Product Backlogs, die initiale Erstellung eines Projekthandbuchs u.v.m., was für einen geordneten Projektablauf notwendig ist.

Die eigentliche Produktionsphase ist in n Phasen unterteilt. Wesentlich ist, dass am Ende jeder Phase ein überprüfbares Ergebnis gegen den ursprünglichen Business Case geliefert und gegenüber dem Lenkungskreis vertreten werden muss, um die Freigabe für die nächste Phase zu erhalten.

Das Projekt schließt mit einer Abschlussphase ab, in dem alle Tätigkeiten zum geordneten Projektabschluss und zur Übergabe des Produkts in den Regelbetrieb enthalten sind.

Das folgende Bild stellt die horizontale und vertikalen Gliederung des Projekts in Steuerungsebenen und Phasen nochmals dar: 

 

Was zunächst komplex anmutet, entpuppt sich bei genauerer Betrachtung als der wesentliche Schlüssel anspruchsvolle Projekte zielgerichtet zu steuern, ohne zu Beginn schon über ein detailliertes Lasten- und/ oder Pflichtenheft zu verfügen. Über die Steuerungsebenen werden jeweils unterschiedliche Planungshorizonte gleichzeitig im Blick gehalten. Über die Phasen werden diese zu definierten Zeitpunkten synchronisiert und immer neu auf den Business Case und den zu erzielenden Nutzen und damit auf die Wirtschaftlichkeit ausgerichtet. Auf diese Weise ist auf allen Ebenen möglich, nach den Deming-Zyklen (Plan, Do, Check, Act) nur auf unterschiedlichen Aggregationsebenen und unterschiedlichen Zeitintervallen zu arbeiten, die dann an den Übergängen ineinandergreifen! Während auf der untersten Ebene in kurzen Sprints iterativ und inkrementell das Produkt mit schnellen Feedback- und QS-Zyklen aufgebaut wird, werden die Zwischenlieferungen auf der zweiten Ebene in den Releases zu Produkten zusammengesetzt, die gegen den Business Case verprobt und an den Kunden ausgeliefert werden können.

Das dient nicht zuletzt der Qualität: der mit dem Scrum-Zyklus verbundene hohe Anspruch, dass Sprintergebnisse releasefähig sein müssen, erleichtert bei richtiger Umsetzung auch die Durchführung von PDCAgetriebenen QS-Maßnahmen für Releases. Der kurz getaktete QS-Zyklus auf der Sprintebene treibt und stützt somit einen übergeordneten QS-Zyklus für Releases. Diese QSZyklen greifen wie Zahnräder ineinander. Ein weiterer Artikel wird hierauf noch einmal detaillierter zurückkommen.

Um dem Gesamtkonstrukt ein Maximum an Flexibilität bei einem gleichzeitig hohen Maß an Steuerbarkeit und Planbarkeit zu geben, sind zwischen den Ebenen Toleranzbereiche definiert, die es den Ebenen erlauben, innerhalb dieser Toleranzen selbständig und autark zu agieren. Man kann sich die Toleranzbereiche wie „Federn“ zwischen den Ebenen vorstellen, die den Motor ruhig laufen lassen und kleinere Unebenheiten wegpuffern, sodass auf den oberen Ebenen der Blick für das Wesentliche frei bleibt und das Risiko von Mikromanagement verhindert wird.

Was haben wir damit erreicht?

Mit der in diesem Artikel vorgestellten Methodik haben vier wichtige Punkte erreicht, die ein Projekt in einem dynamischen, flexiblen Umfeld steuerbar machen. Wir haben

  • eine Vorstellung über den Nutzen des Projekts entwickelt und festgehalten,
  • die dazu notwendige Produktstruktur gefolgert,
  • eine Priorisierung der Anforderungen hin zu einem MVP durchgeführt
  • und den Releaseplan als ersten Terminplan abgeleitet.

Damit ist die Basis für eine erfolgreiche Projektarbeit gelegt – darauf aufbauend können alle weiteren Management-Prozesse einschließlich Kosten-Controlling etc. aufgesetzt werden – bei gleichzeitigem Erhalt der Flexibilität im Projekt.

Wenn Sie mehr Fragen dazu haben, legen wir Ihnen die Details gerne in einem persönlichen Gespräch dar.

Tags
Alle Tags
Artikel-Übersicht