Konzernkommunikation über Agilität hat mitunter eine unfreiwillig komische Note:

„Die Unit XYZ bekommt ein agiles Mindset“

Autsch, man bekommt also ein Mindset verordnet, dabei hat man das oder entwickelt es, aber per order di mufti.

Stirnrunzeln.

Ebenfalls sehr beliebt: euphorische Begeisterungselogen.

Hallo Kollegen, vielleicht mal eine Retrospektive in den eigenen Reihen gefällig?

Agilität ist gut, aber kein Wundermittel. Und so ein unkritischer, verkäuferischer Umgang mit ihr schadet der Sache mehr als dass es ihr dient.

Wir dürfen Vielfalt nicht mit Beliebigkeit verwechseln. Meinungs- und Methodenvielfalt sind eine Bereicherung. Beliebigkeit nicht.

Wie weit müssen wir vor dieser Frage agiles und klassisches Projektmanagement voneinander abgrenzen?

Agiles Projektmanagement ist ein scharfes, effektives Werkzeug im Umgang mit nicht oder nur schwer planbaren Zusammenhängen – im Umgang mit Unsicherheit, aber wenn wir es ohne Sinn und Verstand einsetzen ist es auch nur ein beliebiges Tool und führt zu einer Beliebigkeit der Ergebnisse.

Klassisches Projektmanagement ist hingegen stark von einer initialen Planung getrieben.

Ich durfte jüngst Zeuge einer agilen Planung werden: Das 1-Personen Entwicklerteam haben wir anhand der Anforderungen aus einem Feinkonzept in einem GANTT-Chart geplant – das war noch nicht einmal falsch, aber warum musste das Etikett agil daran kleben?

Es gibt Spezialisierung, Sachzwänge und sequentielle Abhängigkeiten.

Ein lieber Kollege wollte einmal einen agilen Versuchsballon starten und einen Proof of Concept agil durchziehen. Im Konzernumfeld war leider eine exakte Aufgabenteilung vorgegeben – vordefinierte Silos: Infrastruktur, Application Management, …

Wenn es obendrein technische Abhängigkeiten gibt wird man nicht um eine sequentielle Planung herum kommen. Da hilft kein Sprint. Da bleibt vielleicht ein Timeboxing, aber das kann keine sequentiellen Abhängigkeiten aushebeln.

Ich habe sequentielle Planungen gesehen, die sehr gut funktioniert haben: Beim Go-Live von Großprojekten. Zu einem Zeitpunkt, wo die wirklichen Probleme längst gelöst waren – und zwar agil (auch wenn das keiner so genannt hat). Da wurden dann Abhängigkeiten konsequent ausgearbeitet, berücksichtigt und akribisch umgesetzt. Ohne Akzeptanzprobleme.

Mein lieber Kollege Thomas Mathoi würde jetzt darauf verweisen, dass es z.B. im Baumanagement Sachzwänge gibt, die uns zu einer sequentiellen Planung zwingen, wie die Abstimmung verschiedener Gewerke.  Da hat er natürlich Recht – die Frage ist nur: auf welcher Planungesebene? Natürlich muss die Mauer erst stehen, bevor sie verputzt wird und dann der Maler anrückt. Aber muss ich planen ob der Maler rechts oben oder links unten anfängt? In welchem Maß müssen die Gewerke im Vorfeld geplant werden oder können von den Handwerkern auf einer Baustellenbesprechung eigenverantwortlich modifiziert werden. Kein Maler käme auf die Idee eine noch nicht vorhandene Mauer streichen zu wollen… Und wenn die Dinge aus dem Ruder laufen, z.B. weil eine Wasserleitung angebohrt wurde oder Material nicht rechtzeitig eintrifft, kann improvisiert werden – und das ist gut so.

Die Methodenwahl: klassisch oder agil sollte also bewusst und kontextspezifisch erfolgen und nicht beliebig.

Die Frage, welches Vorgehensmodell momentan in unserem Kontext am sinnvollsten ist, kann man versuchen mit dem Stacey-Matrix bzw. dem Cynefin-Modell (auf dem die Stacey-Matrix aufsetzt) zu beantworten.

Die beiden Modelle erlauben uns in einer ersten Annäherung zu erkennen, wann welche Vorgehensweise sinnvoll ist.

Das Cynefin-Modell unterscheidet 4 Domänen:

• einfach
• kompliziert
• komplex
• chaotisch

Bei einfach und kompliziert können wir klassisch planen, bei komplex agil, denn wir wissen nicht wirklich, was die Konsequenzen unseres Handeln sind. Im Chaotischen versuchen wir zunächst mit agilen Strategien Land zu gewinnen um ins Komplexe oder Komplizierte zu gelangen.

Aus diesen Modellen können wir also sogar Handlungsstrategien ableiten.

Das führt uns zurück zu unserer Ausgangsfrage nach Vielfalt und Beliebigkeit.

Ich kann mich nicht losgelöst vom konkreten Kontext für klassisch oder agil entscheiden und nicht losgelöst von der Domäne in der ich mich gerade befinde.

Ich plädiere also für ein bewusstes sowohl als auch. Nicht für Beliebigkeit. Und nicht für eine willkürliche Vermischung.

Zwar können wir einzelne PM-Werkzeuge hybrid einsetzen, nicht aber unseren PM-Ansatz, denn hinter klassisch und agil verbergen sich grundlegende Annahmen, die mit dem Cynefin-Modell verknüpft sind (und die agilen Werte möchte ich dabei sogar noch außen vor lassen):

• Annahmen bzgl. Planbarkeit und Änderungen
• Annahmen bzgl. Planungstiefe und Planungshorizont
• gezielte zentrale vs. dezentrale Planung & Steuerung
• Strategien zum Umgang mit Unsicherheit

Je nach Domäne in der wir uns zu einem Zeitpunkt X befinden, können sich diese Annahmen auch verändern.

Gewusst wo und wofür. Das ist die Frage. Und dann konsequent umgesetzt.

Ein erstes Modell ist vielleicht einfach, die Verfeinerung ist schon kompliziert und erfordert eine detaillierte Planung und Umsetzung. Passiert dann Unerwartetes, müssen wir agil reagieren (und darauf sollten wir vorbereitet sein, weil normalerweise immer auch etwas Unerwartetes passieren kann).

Unter Umständen braucht auch agiles Vorgehen Orientierung an komplizierten Modellen, wenn wir nichts besseres greifbar haben. Auf dieser Basis planen wir Produkt oder Release, aber nicht die einzelne Iteration und natürlich hat eine Iterationsplanung wiederum eine Rückwirkung auf Release und Produkt.

Die Wahl unseres Vorgehens ist also abhängig von Kontext und Situation – und nicht von Ideologien.

Lasst uns unnötige Grabenkämpfe im Projektmanagement beerdigen und uns auf konkrete Problemstellungen konzentrieren.

In diesem Sinn ist Vielfalt befruchtend, aber Beliebigkeit bringt uns nicht weiter. Wir müssen bewusst über unsere Prämissen entscheiden. Und das kontextspezifisch.

Der Post #732 auf schlossBlog ist mein Beitrag zur Blogparade des PM-Camp Berlins 2017.

Dieser Post wurde insbesondere angeregt von einigen Diskussionen auf dem PM-Camp MUC. Versuchen wir doch den PM-Camp übergreifenden Brückenschlag.

Diese Tage kam ich in der Diskussion mit einem Kunden auf die Berücksichtigung von Security Requirements in einem agilen Kontext.

Hintergrund war, dass bislang Security vor allem für den Betrieb und für die Produktsicherheit thematisiert wird, aber Sicherheitsaspekte in der Entwicklung und in einer Projektphase noch eher stiefmütterlich behandelt werden. Auf der anderen Seite finden agile Vorgehensweisen immer weiter Einzug in die Unternehmen und die Ausgangsfrage des Kunden war, wie man Sicherheitsbelange im agilen Kontext berücksichtigen kann.

Für die Projektsicht gibt es vor allem zwei Themenstränge (und dabei müssen wir noch nicht mal zwischen agil und klassisch unterscheiden):

• Die Sicherheit im Projekt
• Die Entwicklung der Sicherheit für Produkt und Betrieb

Bei letzterem Punkt könnte ich mir unterschiedliche Strategien vorstellen:

• Ein stufenweiser Hochlauf, bei dem systematisch das Sicherheitsniveau angehoben wird. (Anfangs mit einer Sandbox, dann Aufbau einer Entwicklungsumgebung, erst noch ohne Daten, dann nur mit einem Teilset der Daten, bis hin zur vollumfänglichen Produktion)
• Vorgabe von Leitplanken (im Qualitätsmanagement gibt es dafür das Control Chart als Werkzeug).
• …

Grundsätzlich würde ich Security-Anforderungen im Normalfall den nicht-funktionalen Anforderungen zuordnen.

Agile SW-Entwicklung fokussiert tendenziell auf funktionalen Anforderungen. Werden dabei wichtige nicht-funktionale Anforderungen vergessen, so kann dies eine Schwäche agilen Vorgehens sein.

Im Wesentlichen finden sich drei Ansätze zur Berücksichtigung von Security Requirements im agilen Kontext:

• Eigene nicht-funktionale Einträge ins Backlog (beispielsweise eigene User Stories. Ein Kollege hat mir berichtete mir, dass er ein eigenes Backlog für Security Anforderungen aufgebaut hat.)
• Berücksichtigung nicht-funktionaler Anforderungen als Constraints
• Berücksichtigung als Kriterien im Definition of Done

Wenn die Vorgaben für Security oder nicht-funktionale Anforderungen allerdings zu sehr formalisiert werden, dann birgt das bereits einen kulturellen Konflikt: Ein formaler Prozess entspricht jetzt nicht ganz den agilen Vorstellungen von eigenverantwortlichem Handeln, d.h. auch da bräuchte es klar definierten Handlungsspielraum für das Team.

Maturity Ansätze fand ich zur Berücksichtigung von Security Anforderungen nicht hilfreich. Da finden sich  CMMI-Adaptionen auf agile Vorgehensweisen. Thematisiert wird aber das Vorgehensmodell an sich und nicht die Berücksichtigung nicht-funktionaler oder sicherheitsrelevanter Anforderungen.

Beitrag #723 auf schlossBlog

Diese Tage wurde ich zufällig Ohrenzeuge einer kleinen Gruppe von Agile Coaches in einem Großunternehmen.

Erst sprachen sie ihre Einführungsfolien durch („Da sollten wir noch auf die agilen Werte eingehen.“). Das Ganze from the scratch weil agiles Vorgehen #Neuland und so, aber groß im Kommen.

Dann war Mittag und ich durfte einem anderen Gespräch der agile Coaches folgen: „Bist du jetzt schon Senior oder noch Junior? Und wie sieht es mit deiner Zertifizierung aus?“

Klar solches Hierarchie- und Statusdenken ist voll agil.

Steht bestimmt auch im agilen Manifest… Zertifikate vor gesundem Menschenverstand.

Agiles Projektmanagement ohne ein entsprechendes Mindset ist vollkommen sinnlos.

Mit dem richtigen Mindset ist schon fast wieder die Vorgehensweise egal.

Jedes Projekt braucht Agilität. Aber die erreicht man nicht durch die Einführung von agilem Projektmanagement, sondern durch eine entsprechende Einstellung und entsprechende Verhaltenswesien. Aus diesen resultiert dann (vielleicht) wieder ein agiles Projektmanagement oder aber ein open-minded klassisches Vorgehen.

Sinnfrei eingeführtes agiles PM ist genauso bürokratischer Mist, wie jede andere ohne Verstand eingeführte Methode. Mag die Methode an sich noch so gut sein.

Beitrag #721 auf schlossBlog

Fehlerkultur und Resilienz tauchen als Begriffe immer häufiger auf und erweisen sich in komplexen Aufgabenstellungen als erfolgreiche Strategie.  Wenn wir schon nicht alles planen und steuern können, dann können wir uns wenigstens auf die Unzulänglichkeiten des Lebens hinreichend vorbereiten. Das gilt in Ausnahmesituationen, ebenso wie im Unternehmensalltag oder in Projekten.

Resilienz mag der Überbegriff sein, aber die Fehlerkultur, als die Art und Weise, wie wir mit Fehlern umgehen ist ein wesentlicher Bestandteil, der zur Resilienz beiträgt. Ein wunderschönes Beispiel dafür, was Fehlerkultur ist, liefert ein Beitrag von Impulse über Fehlermanagement in der Luftfahrt oder: Was Unternehmer von Piloten lernen können.

Und was können sie lernen?  – Das Fehler ganz normal sind und dazu gehören, aber wir können uns auf sie vorbereiten und wenn wir vorbereitet sind, zwingt uns nicht der einzelne Fehler, sondern erst die unglückliche Verkettung mehrerer Fehler in die Knie.

Die Schuldfrage/Cover-your-ass sind unternehmenspolitische Machtspielchen, die nur leider jeden anderen Zweck verfolgen als den Projekterfolg. Mit Fehlerkultur haben sie nichts zu tun. Eher Unkultur…

Resilienz (von lat. resilire ‚zurückspringen‘ ‚abprallen‘) oder psychische Widerstandsfähigkeit ist die Fähigkeit, Krisen zu bewältigen und sie durch Rückgriff auf persönliche und sozial vermittelte Ressourcen als Anlass für Entwicklungen zu nutzen.
(Wikipedia)

Resilienz ist wohl auch eines der Merkmale agilen Projektmanagements, dass dieses so populär macht. Ein zweiter Faktor, der damit Hand in Hand einhergeht sind Kommunikation & Transparenz. Gerade im agilen Projektmanagement werden viele Kommunikationsformen mit Ritualen verstärkt und etabliert. Und last but not least ein spezielles Menschenbild, obwohl das bei der zunehmenden Verbreitung agiler Ansätze immer häufiger vergessen wird. Überhaupt wird der Begriff „agil“ mittlerweile inflationär gebraucht – missbräuchlich gegenüber der ursprünglichen Idee.

Nichtsdestotrotz: Die Erfolgsfaktoren hinter erfolgreichem agilen Vorgehen sind also Kommunikation, Transparenz und Resilienz und auch klassisches Vorgehen kann genauso erfolgreich sein, wenn diese Erfolgsfaktoren gegeben sind. Projekterfolg ist also weniger eine Frage des Vorgehensmodells (agil oder klassisch) als eine Frage der Umsetzung dieser Erfolgsfaktoren (Transparenz, Kommunikation und Resilienz).

Der Vermittler GULP hat seine Datenbank ausgewertet und festgestellt wie und wo die Nachfrage nach agilem Projektmanagement zunimmt:

Und so sieht es mit der regionalen Verteilung der Nachfragen aus:

Projektarbeit muss kontext- und situationsspezifisch sein. Pauschalisierte Ansätze oder Ideologien sind vor diesem Hintergrund Quatsch. Das Spektrum der Projektarbeit (den Managementbegriff habe ich an dieser Stelle bewusst vermieden) ist im Wesentlichen gekennzeichnet durch das gewählte Vorgehensmodell und den praktizierten Führungsstil.

Beginnen wir beim Vorgehensmodell:

Das Spektrum reicht vom Wasserfall bis hin zu agilem, iterativen Vorgehen. Der reine Wasserfall existiert bei genauer Betrachtung eigentlich gar nicht. Nur ein Idiot würde einen einmal gefassten Plan blind in einem Wurf umsetzen. Weitaus häufiger finden sich modifizierte Wasserfallmodelle. Für den Umgang mit Unsicherheit gibt es unterschiedliche Lösungsstrategien: Ein Changemanagement, das Change Requests an ein Projekt behandelt, oder eine iterative Ausarbeitung. Aber auch hier ist die Unterscheidung nicht sinnvoll, weil es auch in der vermeintlich klassischen Projektwelt erlaubt ist iterative Elemente einzusetzen und umgekehrt scheint mir das agile Vorgehen als Postulat genauso überzogen, denn ich kann mir sehr wohl Vorhaben vorstellen, die für den großen Entwurf ein modifiziertes Wasserfallmodell wählen und erst in der Ausarbeitung agil werden, beispielsweise bei der Umgestaltung ganzer Unternehmensarchitekturen. Es gibt ergo keine harten Grenzen.

Auf Seiten des gewählten Führungsstils sieht es ähnlich aus:

Dem humanistischen Ideal des agilen Manifests, ein paritzipatives Modell, weitgehend selbstgesteuert, steht das autoritäre, taylorisitsche Denken gegenüber. Aber auch hier gebe ich zu Bedenken: Der gewählte Führugnsstil muss sowohl zu den Beteiligten und der betroffenen Organisation passen, als auch dem konkreten Kontext gerecht werden. D.h. z.B. dass ein rein agiles Vorgehen an bestimmte Voraussetzungen gebunden ist: Wenn eine Organisation noch nicht bereit ist für ein partizipatives Modell, so wird auch ein agiler Ansatz scheitern. Da hier kulturelle Prozesse betroffen sind, gibt es auch keine schnellen Veränderungen, sondern bestenfalls einen langwierigen, mit Anstrengungen verbundenen Prozess.

Einen zweiten kontextspezifischen Aspekt kann es aus sachlicher Notwendigkeit geben: Bei einem Notfall oder einem Rettungseinsatz, wird man schwerlich die Autortität des Einsatzleiters hinterfragen. Hier gibt es Notwendigkeiten in der zeitlich/sachlichen Koordination, die eine Unterordnung erfordern. Dies ist aber kein blinder Gehorsam, sondern lediglich eine situationsspetzifische Unterodnung. Sobald die sachliche Notwendigkeit entfällt besteht auch wieder die Möglichkeit zu Partizipation und autonomen Handeln.

Ein dritter und letzter wesentlicher Punkt bei der Wahl des Führungsmodells stellt die erforderliche Expertise dar. Die Tayloristische Arbeitsteilung wird allzu schnell auf ihre arbeitspsychologischen Nachteile reduziert. Ein weiterer Aspekt (und auch ein Vorteil) liegt in der Spezialisierung (und Expertise). Die Annahme eines SCRUM-Teams, in dem jeder theoretisch jede Aufgabe übernehmen kann, ist illusorisch. Natürlich gibt es komplexe Aufgaben die sinnvollerweise einem Experten zugeordnet werden. (Wer beispielsweise mal einen EDI-Experten in einem Unternehmen kennengelernt hat, weiß wovon ich spreche…)

Der Versuch die existierenden Schulen/Ansätze in diesem Spektrum zu verankern ist zugegebenermaßen gewagt und im Detail zwangsläufig auch falsch.

Ich möchte zwischen den verschiedenen Vertretern des „klassischen“ Projektmanagement (so fragwürdig dieser Begriff auch immer ist) gar nicht differenzieren und Scrum ist auch nur ein Vertreter der agilen Welt. Mittlerweile gibt es auch bei den „klassischen“ Vertretern  immer mehr das Aufrgreifen agiler Ansätze und umgekehrt in der rein agilen Welt muss man sich auch den Realitäten stellen: Wenn der Kunde sich nicht einbinden lässt, dann muss auch der Product Owner neu interpretiert werden. Und wenn dann die Voraussetzungen nicht passen, dann sieht auch ein Scrum Master genauso alt aus, wie ein im Stich gelassener klassischer PM.

De facto geht es halt doch nicht ohne eine kontextspezifische Betrachtung: Wichtiger als das Vorgehensmodell sind die konkreten Umstände. Welche Stakeholder sind eingebunden, nehmen welche Rolle war? Rollen lassen sich zum Teil nur definieren, zum Teil sind sie einfach nur gegeben. Ein gut eingebundener Kunde ist der Traum eines jeden Projetarbeiters – egal ob agil oder klassisch. In der Realität muss man den Kunden nehmen, den man hat. Das Leben ist kein Wunschkonzert.

Dies ist mein Beitrag zur Blogparade von Marcus Raitner zum diesjährigen Motto des PM-Camp Dornbirn.

Projekte werden bleiben. Und sie werden wichtiger denn je. Nichtsdestotrotz gibt es diesen Wunsch nach einem „beyond project management“ zu verzeichnen und auch dieser Wunsch ist durchaus nachvollziehbar:

1. Es gibt eine wahre Inflation an Projekten („Projektitis), d.h. vieles (egal ob es sich um ein Projekt handelt oder nicht) wird in ein Projektkorsett gepresst. Da wird ein Projekt schon mal schnell zum Formalismus und der gesunde Menschenverstand bleibt auf der Strecke.
2. In der Projektarbeit wird glatt vergessen, dass es bei Projekten um komplexe Problemlösungsaufgaben geht, stattdessen wird mit Patentrezepten nach schnellen Lösungen gesucht.
3. Innerhalb des Projektmanagement gibt es seit Jahren Abgrenzungskämpfe: Einmal zwischen den Verbänden (GPM, PMI,…) und zum Anderen klassisch vs. agil.

An (1) sind aktuelle Management-Strukturen nicht unschuldig: Projekte werden als Werkzeug zur Unternehemenssteuerung eingesetzt – nein: missbraucht. Da sind Projekte das Vehikel beispielsweise der Budgetplanung und wenn für ein Thema Budget gebraucht wird, dann plant man dafür ein Projekt – unabhängig von Art und Charakter der Aufgabe. Außerdem will man alle Projekte miteinander vergleichen können und die Dashboards und KPI´s in denen das Portfolio dargestellt werden, sind der Traum des Managements, aber mitunter des Albtraum der Projekte, denn komplexe Sachverhalte auf Kennzahlen zu reduzieren ist nicht nur mutig, sondern auch gefährlich. Vielleicht steckt hinter „beyond project managememt“ also mehr ein „beyond management„.

Bei (2) möchte ich von einem Komplexitätsdilemma von Projekten sprechen (siehe auch die Betrachtung im Rahmen der Design Thinking Reihe). Die Komplexität der Aufgabenstellung ist einerseits konstituierendes Merkmal eines Projektes, andererseits verdrängen wir das sofort wieder in dem wir uns auf die Suche nach der einen Lösung machen, egal ob im großen Wurf oder in inkrementalen Schritten. Wenn wir uns das Komplexitätsdilemma bewusst machen, ist es kein Wunder, warum so viele Projekte scheitern. Vielleicht brauchen wir hier einen Perspektivenwechsel: Weg von der Erfolgsbetrachtung des einzelnen Projekts, hin zu einer Entwicklungs- und Lernperspektive.

Ad (3): Ich bin ganz bei Stefan Hagen und Reinhard Wagner: Die künstlichen Abgrenzungsversuche sind reiner Quatsch. Was die Scharmützel der Verbände angeht, so sehe ich diese v.a. als Ergebnis der ökonomischen Interessen des mittlerweile auswuchernden Zertifizierungsbusiness (aber das ist eine andere Diskussion). Die vielen unnötigen Diskussion agil vs. klassisch der letzten Jahre gehen mir mittlerweile reichlich auf den Senkel. Zunächst muss man feststellen, dass dieses „klassische Projektmanagement“ erst von den „Agilisten“ erfunden wurde, nämlich im Versuch der Abgrenzung. Wir sind uns sicher schnell einig, dass es viele fragwürdige und überholenswerte Methoden und Vorgehensweisen gibt, die wir gerne anpacken sollten, aber bitte keine Glaubenskriege. Es gibt keinen Grund ein humanistisches Menschenbild, iterative Vorgehensweisen, Selbststeuerung und Teams in Projekten (á la Agiles Manifest) abzulehnen. Das tut auch keiner – nur die Abgrenzung klassisch vs. agil. Es gibt nur ein Welt, aber diese mit sehr vielen Facetten und vielen unterschiedlichsten Versuchen die Fragen dieser Welt zu beantworten. Primär ist für mich dir Frage nach dem Kontext entscheidend und nicht die Frage nach der Schule mit der ich versuche einen Kontext zu bearbeiten. Somit schließt sich wieder der Kreis zur Argumentation von Stefan Hagen und Reinhard Wagner.

Auch wenn wir hier etwas einseitig auf die Prozessperspektive des Design Thinking blicken, so ist das doch ein hilfreicher Ansatz um auch Projektmanagement-Schulen zu reflektieren.

Das „klassische“ PM unterstellt fast schon tayloristisch den „one best way“ zum Projektziel, der anfangs geplant und dann konsequent sequentiell in einem Wasserfallmodell abgearbeitet wird. Dieses Bild ist natürlich stark vereinfacht, denn auch die „agilen“ Oesterreich und Weiß weisen bereits darauf hin, dass die Väter des Wasserfallmodells durchaus (Rück-)Sprünge zwischen Prozesschritten/-phasen gesehen haben.

Im agilen PM wird die Idee der Umsetzung auf dem direkten Weg in einem großen Wurf aufgegeben. Der Fokus bleibt zwar auf der Umsetzung einer Lösung, aber nicht auf der Umsetzung eines großen Plans, sondern auf der Umsetzung der Anforderungen im Backlog in vielen kleinen Schritten/Iterationen. Iteratives Vorgehen lässt bewusst Platz für permanente Changes, die den klassischen PM doch in Verzweiflung treiben. Schrittweises Vorgehen und die permanente Integration erlauben von Anfang an einen Lernprozess. Risiken werden durch die laufende Integration minimiert, da Fehler schnell erkannt werden und korrigiert werden können. Änderungen können problemlos in den laufenden Prozess einfließen. Was gerne vernachlässigt wird ist aber, dass agiles PM auch einige implizite Annahmen mit sich bringt, z.B. bzgl. der Skalierbarkeit von Anforderungen/Features und der Skalierbarkeit des Teams.

Während diese beiden Ansätze also auf die Umsetzung von Anforderungen fokussieren, fokussiert Design Thinking auf den kreativen Prozess, auf die Gestaltung und Problemlösung. Wir entwickeln ja erst die Lösung und auch nicht die EINE Lösung, sondern möglicherweise erst einmal eine ganze Reihe verschiedener Lösungsansätze, die wir parallel verfolgen und weiterentwickeln, bevor wir uns für eine Variante entscheiden. Wir suchen quasi die Lösung für ein komplexes Problem, statt von Anfang an einen mehr oder weniger komplizierten Plan zu verfolgen.

STOP. Denkpause.

Aber eigentlich ist doch Komplexität ein konstituierendes Merkmal der Projektdefinition. Heißt das dann nicht im Umkehrschluss, dass wir im Projektmanagement (egal ob klassisch oder agil) auf der Suche nach dem einen Weg zum Ziel die Komplexität (trotz besserem Wissen) ignorieren bzw. vernachlässigen?

Kein Wunder, dass so viele Projekte scheitern…

Umgekehrt benötigt der kreative Prozess aber Freiraum, Zeit und Ressourcen. Er ist vielleicht effektiv, aber möglicherweise nicht so effizient, wie es sich der eine oder andere Stakeholder erhofft.

Folgende Grafik skizziert noch einmal die drei Herangehensweisen, vom klassischen direkten Weg zum Projektziel, über das agile Herantasten, bis hin zur parallelen Entwicklung von Lösungsalternativen im Design Thinking:

Wie bereits im vorangegangenem Beitrag angesprochen: Design Prozesse sind „sprunghaft“. Sie erlauben nahezu beliebige Sprünge zwischen den einzelnen Prozessschritten. Der Design Prozess ist kein Wasserfall-Modell, das sequentiell durchlaufen wird.

Das obige Bild zeigt anhand des Design Thinking Prozess des HPI, dass aufgrund neuer Erkenntnisse oder Ideen, jeder Prozessschritt beeinflusst werden kann und es vor allem zu Sprüngen zurück im Prozess kommen kann. Design Prozesse bekommen so eine eigene Agilität, wobei diese nicht wie im agilen Projektmanagement in geplanten Iterationen erfolgen muss. Design Prozesse sind hier weit freier, losgelöst von organisatorischen Hilfskonstrukten wie Iterationen oder getakteten Sprints. Auch optimierende Betrachtungen von Velocity oder Burn-Down-Charts gibt es natürlich nicht. Wir sind ja auch in einem kreativen Prozess und nicht in einem (reinen) Produktionsprozess.