Wer verschiedene Projektmanagementmethoden beschreibt, behilft sich häufig folgender Klassifizierung: Wenn Sie in einem Softwareprojekt genau wissen, was Sie wollen, dann können Sie die konventionelle Projektmanagementmethode nutzen: Die Wasserfallmethode. Wenn die Anforderungen dagegen unübersichtlich sind und Lösungswege unklar, dann eignet sich Agiles Projektmanagement.

Zur ersten Orientierung ist diese Pi-Mal-Daumen-Regel sicherlich hilfreich, blendet aber einen wichtigen Aspekt aus, der in Softwareprojekten eine wachsende Bedeutung gewinnt: „Wieviel innovative Neuerungen wünscht der Auftraggeber eines Softwareprojektes bzw. wieviel Disruption hält der Auftraggeber aus?“ Hier wird also nicht nach der Klarheit der Anforderungen gefragt, sondern nach der Veränderungsbereitschaft des Auftraggebers. Das ist eine völlig andere Frage. Es gibt Dutzende IT Projekte, wo die Anforderungen des Auftraggebers klar sind, demnach gemäß der einleitend genannten Regel ein Fall für die Wasserfallmethode. Ein Beispiel aus der Praxis: Ein mittelständisches Unternehmen beauftragt die Migration einer Projektkalkulationssoftware auf eine neue technische Plattform, da die alte Technologie (Delphi) nicht mehr zukunftsfähig ist. Sie könnten daraus ein C#.NET, Java-Projekt oder C# Projekt in der Azure-Cloud machen, der Entwickler setzt den bestehenden Workflow in der neuen Technologie um. Ganz einfach. Wasserfallmethode.

Andererseits bietet ein solches Projekt zahlreiche Ansatzpunkte für innovative Verbesserungsentwicklungen, nicht zuletzt unter Nutzung von KI/ML. Auf eben diese Verbesserungsentwicklung kann man sich vergleichsweise einfach einigen; hier entfallen lediglich lästige Routinearbeiten. Aber Vorsicht, wo Automatisierung umgesetzt wird, ist auch mit Widerstand zu rechnen. Im Rahmen eines Projektes zur „IT Automation“, wo diverse Geschäftsvorfälle von Passwort-Reset bis hin zum Deployment von Virtual Machines weitgehend automatisiert wurden, gab es folgende Ansage: „Wir gehen bis hierhin und nicht weiter, denn sonst fällt mein Arbeitsplatz weg.“ Derartige Situationen sind bekannt, ich gehe weiter unten kurz auf eine Antwort hierauf ein.

Schauen wir uns zunächst an, was das für die Methodenwahl beim IT Projektmanagement bedeutet, wenn man sich für ein „innovatives“ Entwicklungsprojekt entscheidet. Hier und im Folgenden beziehe ich mich im Übrigen immer wieder auf Prof. Dr. Peter Kruse, der zum Veränderungs- und Innovationsmanagement zahlreiche Publikationen vorgelegt und Vorträge gehalten hat (vgl. auch YouTube). Zitate sind aus seinem Buch „next practice. Erfolgreiches Management von Instabilität“ (GABAL Verlag) oder seinem Vortrag „Führen im Wandel – Gestaltungsprinzipien von Veränderungsprozessen“.

Wie die Agile Projektmanagementmethode innovative Potentiale heben kann

Ein innovativer Prozess beginnt ganz offensichtlich damit, dass das Bestehende in Frage gestellt wird oder (etwa durch den Markt oder durch Kundenabwanderung) bereits in Frage gestellt wurde. Damit wirklich Neuartiges generiert wird, benötigen die Beteiligten natürlich völlige Freiheit, eben dieses Neue zu denken und auszuprobieren. Zwar benötigt der Innovationsprozess an sich eine Struktur (nämlich klare Regeln, wie Ideen eingebracht, evaluiert, ausprobiert werden), aber es kann aufgrund der Natur des Innovationsprozesses keine Planung geben, denn das Ergebnis ist ja noch nicht bekannt. Dr. Kruse hierzu: „Wir brauchen im gewissen Sinne eine Reduktion von Konzeptarbeit und eine Zuwendung auf eine höhere und schnellere Form von Dynamik. (…) Kommen Sie nicht mit fertigen Konzepten, sondern kommen Sie immer mit Konzepten, die Sie sich trauen, den Leuten in einer iterativen Schleife anzubieten. Je schneller Sie Zwischenergebnisse herausbringen, desto höher die Dynamik im System.

Der letzte Satz macht deutlich, weshalb die Agile Softwareentwicklung in besonderer Weise für innovative Entwicklungsprozesse geeignet ist: Das Prinzip der iterativen Schleifen ist ein zentrales Element im Veränderungs-/Innovationsmanagement. Je häufiger und je mehr Zwischenergebnisse in den Steuerungskreislauf zurückgespeist werden, desto eher gelingt es, die Intelligenz der ganzen Gruppe wachzurufen. Es ist das Grundprinzip zahlreicher Innovationen in der Internet-Ökonomie: Veröffentlichung eines neuen Internetangebotes, Optimierung auf Basis von Kundenfeedback, A/B Testing, viele iterative Schleifen, bis hin zu iterativen Schleifen auf täglicher Basis.

Ein völlig freier, innovativer Entwicklungsprozess mit ungewissem Ausgang und ohne Budgetlimits ist sicherlich nicht die Idealvorstellung eines IT Projektes. Es ist ganz klar: Ein idealtypischer Innovationsprozess eignet sich in dieser Reinform nicht für alle IT Projekte. In der Praxis wird ein solcher innovativer Prozess als „explorative Phase“ einem IT Projekt vorgeschaltet, oder aber wenige ausgewählte Teilbereiche eines IT Projektes folgen diesem Prinzip. Die „Dosis“ oder den „Wirkbereich“ von Innovation kann man also selbst bestimmen. Die Ingredienzen hierfür sind – etwas vereinfacht: Iterative Schleifen, völlige Freiheit der Beteiligten, strukturierter Prozess (bei Scrum etwa: Timeboxing).

In der Innovations-/Veränderungstheorie gibt es eine sehr hilfreiche Einordnung von Ausgangssituationen, anhand dessen sich gut ableiten lässt, welche Handlungsstrategie empfehlenswert ist und wann eigentlich Innovation/Veränderung zwingend erforderlich wird. Das lässt sich analog auf Softwareprojekte anwenden.

Überblick zu den 4 verschiedenen Grundformen von Herausforderungen einer Organisation aus der Sicht der Innovationstheorie

Dr. Kruse unterscheidet vier Systemzustände, und zwar entlang zweier Dimensionen. Die Erste Dimension ist stabil/instabil: Ein stabiles System verhält sich vorhersagbar. Instabil meint, das System macht Sprünge; die Kenntnis der Vergangenheit erlaubt mir nicht, die Zukunft vorherzusagen. Die zweite Dimension ist einfach/komplex. Im einfachen System gibt es nur wenige Elemente mit wenigen Beziehungen untereinander. Ein komplexes System besteht aus vielen Elementen mit hochgradiger Vernetzung.

Der einfachste Fall ist ein stabiles / einfaches System. Dieses System können Sie steuern, und zwar mit dem Ziel der Optimierung. Wenn Sie zuhause einen Topf Wasser auf den Herd stellen, dann handelt es sich um eine solche Situation. Das Wasser kocht (unter sonst gleichen Bedingungen) immer am gleichen Siedepunkt, es gibt nur die Elemente Wasser und Hitzequelle. Ein Software / IT Projekt unter analogen Bedingungen könnte etwa wie folgt aussehen: Für eine bestehende Applikation (z.B. SAP) muss eine Schnittstelle (API) entwickelt werden, die Daten in einem vorgegebenen (unveränderlichen) Format importiert. Einfach. Stabile Anforderungen.

Die zweite Situation ist stabil / komplex. Sie haben einen Außenpool in einer Hotelanlage und wollen das Wasser auf einer konstanten Badetemperatur (Soll-Wert) halten. Es handelt sich um ein System, das Sie regeln können. Das System verhält sich noch immer vollkommen vorhersagbar, nur die Anzahl der Faktoren hat sich erhöht: Es kommt die variable Außentemperatur hinzu (Sommer, Winter), die Anzahl der Gäste im Pool (Wasserverdrängung, Körpertemperatur), gegebenenfalls auch die direkte Sonneneinstrahlung auf die Wasseroberfläche oder die Verwirbelung von oberen und unteren Wasserschichten. Überträgt man diese Situationsparameter auf ein IT / Software Projekt, könnte dies etwa so aussehen: Sie sollen als Softwareentwickler eine einseitige (webbasierte) Eingabemaske für die Erst-Anfrage eines potentiellen Versicherungskunden definieren. Das Corporate Design gibt Ihnen als Programmierer das UI Design klar vor, Sie müssen mit etwa fünf Abteilungen sprechen für die Abstimmung der Eingabefelder (Marketing-Abteilung, Datenschutzbeauftragter, IT Abteilung, etc.).

Wenn die Situation instabil / einfach ist, dann ist Error & Trial eine hilfreiche Strategie. Sie sind etwa in einer fremden Stadt ohne Stadtkarte, ohne Smartphone. Wenn Sie eine bestimmte Adresse suchen, dann können Sie sich einfach durchfragen. Zum Error & Trial Prinzip: Sie bringen eine Eintragsfliege und eine Honigbiene jeweils in eine Flasche, den Flaschenboden (also: die geschlossene Seite) richten Sie nach dem Licht aus, die Flaschenöffnung auf die lichtabgewandte Seite. Welche der beiden Insekten findet heraus? Die Biene stirbt, denn Sie versucht hartnäckig, dem Licht zuzufliegen. Die Eintragsfliege fliegt wild herum (Error & Trial) und findet nach kurzer Zeit den Ausgang. Ein beispielhaftes IT / Software Projekt könnte wie folgt aussehen: Der Check-Out Prozess in einem eCommerce-Shop soll so optimiert werden, dass die Abbruchquote minimiert wird. Stellhebel sind die verfügbaren Zahlungsoptionen, der Komfort bei der Datenerfassung, die Anzahl der zu erfassenden Eingaben, die Gesamtdauer und Weiteres. Hier können Sie mit A/B Testing-Methoden arbeiten, kurzen iterativen Schleifen.

Kommen wir nun zur anspruchsvollsten Situation, nämlich instabil / komplex. Klassische Beispiele für solche Situation sind etwa die Entdeckung Amerikas durch Christopher Kolumbus. Kurz: Aufbruch zu unbekannten Kontinenten. Es gab damals keine Seekarten für dieses Unternehmen, es gab keine Möglichkeit, das Ziel vorherzusagen. Auf die Frage der Seeleute, wo es denn hingehe, musste Kolumbus als Kapitän ehrlicherweise sagen: „Das weiß ich auch nicht so genau. Das tut mir leid, kann ich Dir nicht genau sagen, aber eines kann ich auf jeden Fall sagen. Es wird bestimmt gefährlich, und es kommt auch nicht jeder mit zurück.“ Die Strategie des „Error & Trial“ ist in dieser Situation auch völlig unangemessen, denn diese würde ja den Schiffbruch, das totale Scheitern mit einkalkulieren. Die Antwort ist eine andere. Dazu Dr. Peter Kruse: „Es bleibt nur die Entwicklung von Visionen, das Vertrauen auf Intuition, die Sensibilisierung für die Wahrnehmung aktueller Gegebenheiten und das bewegliche Sich-Einlassen auf jede noch so kleine Veränderung. Der Kurs entsteht also aus der schrittweisen, wechselseitig aufeinander bezogenen Abstimmung von Zielvorstellungen und vorgefundenen Bedingungen.“ Und an anderer Stelle präzisiert Kruse, differenziert nochmals zwischen Vision und Ziel: „Eine Vision ist eine Vorstellung oder auch eine Idee, aber nicht ein exakt fassbarer Sollwert. Eine Vision ist kein Ziel.“.

Übertragen auf die Welt der IT Projekte und Softwareentwicklung würde dies etwa bedeuten: Die Stadt Berlin will eine Softwareapplikation entwickeln, die als übergreifende Koordinationsplattform die Baustellenplanung und –optimierung im großtstädtischen Bereich ermöglicht, so dass Baustellen (inklusive Verkehrsumleitungen) so eingephast werden, dass es zu minimalen Störungen im Verkehrsfluss kommt – unter Berücksichtigung von Ausweichverhalten der Berufspendler zwischen den verschiedenen Verkehrsmitteln. Einzubinden sind etwa die BVG / Berliner Verkehrsbetriebe (U-Bahnen, Busse, Trams), die Deutsche Bahn (S-Bahnen), das Straßenbauamt (Verlegung von Gas, Wasser, Strom), die Telekomanbieter (Verlegung von Glasfaserkabeln), die Regierung von Brandenburg, das Ordnungsamt (Veranstaltungsplanung, -genehmigung) undsoweiter. Gewünscht ist auch eine Verkehrsflusssimulation über alle Verkehrsmittel.

Voraussetzungen für Innovation, für erfolgreiche Veränderungsprozesse

Wer Veränderungsprozesse vom Typ „Kolumbus“ startet, der muss sich als Manager der Herausforderungen bewusst sein – sei es in einer strategischen Neuausrichtung eines Unternehmens, sei es in einem Softwareentwicklungsprojekt. Zu Beginn wurde bereits der Einwand jenes Mitarbeiters genannt, dessen Arbeitsplatz im Rahmen eines IT Automatisierungsprojektes gefährdet wurde. Es gibt sicherlich vereinzelt Unternehmen, die etwa dank zahlreicher Geschäftsbereiche Arbeitsplatzgarantien aussprechen können, wenn Veränderungsprozesse in einem der Geschäftsbereich angestoßen werden. Die Mehrzahl der Unternehmen kann dies eher nicht. Dr. Peter Kruse formuliert hierauf folgende Antwort: „Sie müssen ja ehrlich sein. Sie können ihm [dem Mitarbeiter] keine Arbeitsplatzgarantie mehr geben. Zumindest in der Industrie wird das immer schwieriger. Und jetzt überlegen Sie mal, warum soll der Mensch überhaupt Veränderungen mitmachen, wenn Sie ihm diese Garantie nicht geben. Und da gibt es meiner Ansicht nach einen wesentlichen Vertrag, der die Garantie von Arbeitsplatzsicherheit ersetzen kann. Sie können die Marktfähigkeit von Menschen erhöhen. (…) Sie können den Menschen im Veränderungsprozess eine Erhöhung ihrer Kernkompetenzen anbieten. Und das machen Firmen sehr intensiv. Die sagen, du kannst mit einem Teil deines Gehaltes eine Fortbildung machen, die nichts mit meinem Laden zu tun hat. Ich bezahle dir den Taxischein – so kurios das klingt -, obwohl wir kein Taxiunternehmen sind. (…) Der Vertrag, den man miteinander macht, ist, Menschen in ihrer Kompetenz zu entwickeln – und nicht positional abzusichern.

Wer Veränderungsprozesse anstößt, der bringt Organisationen (oder Organisationseinheiten) von einem Zustand der Stabilität in einen anderen Zustand der Stabilität. In der Übergangsphase entsteht Instabilität – und die ist nicht einfach auszuhalten. Dr. Kruse empfiehlt: „Was Sie dann also trainieren sollten, ist eine hohe Instabilitätstoleranz (…) machen Sie eine Kultur der Sichtbarkeit von Zwischenergebnissen. Denn wenn Sie keinen Soll-Wert mehr vorgeben können und diesen Soll-Wert nicht mehr mit einem Ist-Wert vergleichen können, sind Sie darauf angewiesen, sichtbar zu machen, was Sie gerade getan haben. (…) Controlling ist die Selbstregulation eines Systems. Da geht es darum, dass Sie im System Sichtbarkeit von Zwischenergebnissen erzeugen, damit Sie überhaupt die eigene Dynamik spüren.“

Der Manager selbst muss auch an sich arbeiten. „Manager wollen vorhersagen, was bei einem Prozess herauskommt. Wenn Sie das System aber kreativ machen wollen, müssen sie sich von der Vorhersagbarkeit verabschieden. (…) Sie haben sogar diesen typischen Effekt, dass die Leistung einbricht. Und jetzt haben Sie da einen Manager oder eine Führungskraft, die das spürt und weiß, sie ist dafür verantwortlich. Die Folge ist eine Riesentendenz, wieder steuernd einzugreifen, anstatt diese Instabilität zuzulassen und sie kreativ werden zu lassen.“

Viel Erfolg bei der Umsetzung im nächsten Softwareentwicklungsprojekt!

“Ich suche nicht, ich finde. Suchen, das ist das Ausgehen von alten Beständen und ein Findenwollen von bereits Bekanntem. Finden, das ist das völlig Neue. Alle Wege sind offen, und was gefunden wird, ist unbekannt. Es ist ein Wagnis, ein heiliges Abenteuer.”
Pablo Picasso

Sebastian Zang
Author

Der Autor ist Manager in der Softwareindustrie mit internationaler Expertise: Prokurist bei einem der großen Beratungshäuser - Verantwortung für den Aufbau eines IT Entwicklungszentrums am Offshore-Standort Bangalore - Director M&A bei einem Softwarehaus in Berlin.