Agil ist man nicht auf Ansage, es ist eine Geisteshaltung (auch gerne Mindset genannt). Diese unterscheidet sich so sehr vom – bis vor Kurzem in fast jedem Unternehmen allein gültigem – Dreiklang aus Hierarchien, Planung und Kontrolle, dass sie für solche "gewachsenen" Unternehmen nach einem Bildersturm klingt.

Man denke nur an all die in voller Blüte stehenden Fürstentümer und die liebgewonnenen Vorschriften-Komfortzonen: Es braucht eine lange, behutsame Transformation, angefangen beim Top- und Mittelmanagement bis in die Projekte hinein, um den Kulturwandel zu partizipativem, kollektivem und selbstorganisiertem Handeln zu vollziehen.

Fallbeispiel Sanierung eines "klassischen" Projekts

In meinem Beispiel tauchen wir ein in ein typisches deutsches Unternehmen, das seine Kernprozesse von der Akquise über die Auftragsbearbeitung und ‑ausführung bis zur Fakturierung und dem Mahnwesen beschreiben, standardisieren und mit IT-Unterstützung digitalisieren wollte. Dabei hatte man – wie immer – der starken internen IT-Abteilung den Auftrag zur Umsetzung erteilt und sich hernach in den Fachabteilungen wieder auf das Tagesgeschäft konzentriert.

Nach einem halben Jahr wurde der Pilot stolz in der ersten Niederlassung vorgestellt. Business wie IT waren enttäuscht von der Reaktion der jeweils anderen Seite. Über ein Jahr mit schmerzhaften Nachbesserungen folgte, bis das Produkt halbwegs gebrauchsfähig war, Kosten und erhoffter Time-to-Market liefen davon. Die Geschäftsleitung zog die Notbremse.

Aktive Beteiligung des Business

Mein erster Vorschlag zur Sanierung war, die Fachseite aktiv am Projekt zu beteiligen, sie in den "Driver Seat" zu setzen. Das ist in vielen "IT-Projekten" ungewöhnlich (!?!), denn erstens hat das Business für "sowas" ja keine Zeit und zweitens meist keinerlei Erfahrung, wie man das macht.

So auch in diesem Fall: Fehlanzeige bei Projekt- und Anforderungsmanagement, also: Grundlagen einführen und für die Mitarbeit im Projekt dediziert Projektmitglieder aus den Fachbereichen einfordern. Die IT-Leitung lehnte sich zurück und erwartete unsere Bauchlandung. Dennoch hatten wir in relativ kurzer Zeit eine kleine, sehr engagierte Truppe zusammen, die sich erstmals eingehende Gedanken über die Prozesse machte, die die IT abbilden sollte.

Gleichzeitig schaute ich mich im Unternehmen etwas um und fand ein paar weitere Projekte anderer Abteilungen, die sich just mit den gleichen Themen beschäftigten und bei der IT dafür Ressourcen angefordert hatten. Die Geschäftsleitung erkannte die Sparpotenziale und Synergien sofort. In den "Fürstentümern" regte sich zunächst Widerstand gegen die nun folgenden von der Geschäftsleitung „angeregten“ Konsolidierungen ihrer Projekte mit unserem. Ich gab meinen Team-Mitgliedern eine kleine Einführung in Veränderungsmanagement und holte Leute aus den erwähnten anderen Abteilungen in unser Boot.

Hybrider Ansatz häufig zielführender

Was hat das bisher mit Agil zu tun? Nun, eine Grundvoraussetzung für alle agilen Vorgehensweisen ist eine intensive, aktive Beteiligung der Fachseite, die ja die Product Owner stellen muss. Und die müssen wissen, wie das Ergebnis aussehen soll, also was die Definition of Done in Reviews und Tests sein soll. "Klassisches" Anforderungsmanagement wie bei unserer Prozessdefinition mag zwar nicht genau ins agile Bild passen, aber bereits hier arbeiteten immerhin alle Beteiligten sehr iterativ, zudem nutzten wir in vielen Teilen auch Elemente aus dem Design Thinking.

Das zeigt aber auch, dass in Unternehmen, die noch nicht gesamtheitlich agil "ticken", ein hybrider Ansatz zielführender sein kann als einer "by the books". Das kompetent und der Situation angemessen beurteilen zu können und zu entscheiden, ist letztlich die Aufgabe und die Fähigkeit eines guten Projektmanagers, den es ja so in der agilen Welt auch nicht gibt.

Anforderungen: "klassische" Ermittlung der Features und User Stories

Mithilfe einer kleinen Unternehmensberatung, die uns bei der Anforderungs- und Prozessbeschreibung unterstützte, kamen wir in allen Bereichen gut voran. Und siehe da: Ca. 80% der Abteilungs-Prozesse überschnitten sich oder waren sogar weitgehend gleich! Daraus ließ sich mit etwas Abstraktion und Konzentration auf das Wesentliche am Ende ein einziger, gemeinsamer End-to-End-Ablauf mit nur ganz wenigen aufgabenindividuellen Schleifen machen. Eine signifikante Einsparung für den kommenden Entwicklungsaufwand und ein riesiges Synergievolumen für das Unternehmen durch die Prozessoptimierung und –Standardisierung!

Weitere häufige Hinderungsgründe, um Projekte tatsächlich agil durchzuführen, die in der Beharrlichkeit der Auftraggeber liegen, stellen ich Ihnen in meinen nächsten Beitrag vor.