Wenn Projekte bessere Produkte verhindern

Auf der ALM 2022 stellte ich in meiner Session die Frage: Projektierst Du noch oder entwickelst Du schon Produkte? Dieser Artikel ist der Versuch einer Transkription plus eine leichte Anpassung der ursprünglichen Version.

Hintergrund der Eingangsfrage sind zum einen meine Beobachtungen aus mehr als 15 Jahren im Projektgeschäft mit Softwareentwicklungsdienstleistungen. Zum anderen Aussagen aus verschiedenen Meetups, Barcamps und Open Spaces. Obendrauf kommen noch Erfahrungen aus Projektanfragen im Rahmen meiner Selbstständigkeit.

Mein Ziel ist ein Aufrütteln und Hinterfragen des Staus Quo. Denn überall nehme ich eine noch immer stark von Projektdenken geprägte Sprache wahr. Und das bringt mich zu der Aussage, dass Unternehmen dadurch hinter ihren Möglichkeiten zurückbleiben, noch besser zu werden.

Lasst uns zunächst sehen, wo wir stehen.

Erste Anzeichen und andere Red Flags

Denkt als ersten Schritt über folgende Frage nach: Was verspricht sich euer Unternehmen von "Agilität"?

Stellt diese Frage auch gerne in einem passenden, größeren Rahmen. Zugegeben, das mag wie eine lästige Frage klingen und die Behandlung dieses Themas ist ein Artikel für sich. Doch hört euch die Antworten genau an und hinterfragt diese: "Wir müssen schneller werden". Wozu? "Wir müssen anpassungsfähiger werden". Wozu? "Unsere Softwareteams müssen mehr liefern". Wozu?

Diese Übung hat ein einfaches Ziel: Ist das Thema "Agilität" Mittel zum Zweck oder nur ein Selbstzweck?

Überlegt im zweiten Schritt, ob ihr die folgenden beispielhaften Aussagen kennt:

1. Wir nutzen agile Werkzeuge v. a. in den Softwareentwicklungsteams
2. Im Refinement fragen Devs: "Und was soll ich entwickeln?"
3. Wir haben Probleme, gute Sprintziele festzulegen
4. Um Anforderungen kümmert sich ein Business Analyst oder Requirements Engineer
5. Unsere Roadmap ist ein fester Zeitplan

Das sind alles mögliche Zeichen für eine "Projekt-Kultur". Von einem agilen Blickwinkel aus betrachtet, geben diese Aussagen potenzielle Warnhinweise:

1. Es gibt Grenzen zwischen "Gewerken" bzw. ein Silodenken mit entsprechenden lokalen Optimierungen. Zudem scheint die Erkenntnis zu fehlen, dass sich nicht nur das "Software-Silo" ändern muss.
2. Es fehlt der Sinn für die eigene Wirksamkeit. Die Devs sehen sich mehr als Erfüllungshilfe denn als Teil einer Co-Creation.
3. Was ist denn dann das Ziel eurer Sprints? Möglichst viel Inhalt? Oder gibt es viele Baustellen gleichzeitig zu bedienen? Dann befindet ihr euch möglicherweise in einer Feature Factory.
4. Wenn diese Person in das Team integriert ist und sehr eng mit diesem kommuniziert, spricht nicht viel dagegen. Ansonsten kann diese Rolle auf einen Wasserfall und Up-Front-Waste hindeuten.
5. Ja, auch Roadmaps sind ein Thema für sich. Welche Variante wähle ich für welche Zielgruppe? Sicher ist nur, dass eine "Roadmap" mit einem engen, festen Zeitplan nichts anderes ist als ein Projektplan.

Im dritten und letzten Schritt bietet sich noch an, einen Blick auf interne wie externe Stellenausschreibungen oder Anfragen zu werfen. Im Umfeld von Scrum bzw. konkreter eines Scrum Master können solche Beispiele auftauchen:

• "User Stories schreiben und Backlog pflegen" -> Scrum Master als Requirements Engineer?
• "Planung der Sprintinhalte und Sicherstellung der Zielerreichung" -> Scrum Master als Projektmanager?
• "Vollauslastung der Devs sicherstellen" -> Scrum Master zuständig für Kapazitätsplanung?
• "Sicherstellung der Qualität der Ergebnisse der Devs" -> Scrum Master in der Qualitätssicherung?
• "Reporting der sprintrelevanten Kennzahlen" -> Aufrechterhaltung der Kontrollillusion?

Diese Formulierungen deuten darauf hin, dass kein Scrum Master gesucht wird, sondern ein Projektleiter. Wahrscheinlich ist der Weg zur Agilität auch noch ein weiter.

Und ich gebe "dem Projekt" eine Mitschuld daran.

Meine Hypothese

Bevor wir zu meiner eigentlichen Behauptung kommen, sind noch zwei wichtige Hinweise nötig.

Disclaimer 1: Es kommt immer darauf an.

In der Produktentwicklung bewegen wir uns in den meisten Fällen in einem komplexen Umfeld. Für die Lösungsfindung in einem solchen Gebiet gibt es keine Best Practices oder magischen Silberkugeln. Jedes Unternehmen ist anders und somit ist jede Lösung anders. Und genauso können Projekte und Produkte in einem Unternehmen wunderbar koexistieren, während es in einem anderen zu Reibungen führt.

Disclaimer 2: Unternehmen bestehen am Markt auch ohne explizite "Agilität".

Hier dürfen wir uns keine Illusionen machen. Wirtschaftlicher Erfolg geht auch ohne Scrum und Co. Sehr viele Unternehmen sind mit klassischen Organisationsformen und Vorgehensweisen an die Position gelangt, an der sie heute sind und verdienen schlussendlich Geld.

Die Frage ist nur, wie weit sie damit noch kommen bzw. wie lange sie so noch am Markt bestehen können. In meinen Augen wird durch das Festhalten an alter Management- und Projektdenke Potenzial verschenkt.

Hypothese: Denken in "Projektsprech" fördert agil tun statt agil sein und behindert einen nachhaltigen Markterfolg.

Oder kurz: Ihr lasst Geld auf der Straße liegen.

Wichtig dabei ist zudem, dass sich "Markt" nicht nur auf ein Produkt und dessen Absatzmarkt bezieht. Genauso ist damit auch der Arbeitsmarkt gemeint und somit die Arbeitgeberattraktivität. Jedes Unternehmen kann selbst bestimmen, welche Mitarbeitenden es attrahieren möchte und halten kann.

Blicken wir auf die Unterschiede und Zusammenhänge zwischen Projekten und Produkten.

Projekt, Produkt und Zielkonflikte

Als Einstieg lohnt sich festzuhalten, was ein Projekt eigentlich ausmacht. Gemäß IPMA ist die Definition wie folgt:

Ein Projekt ist ein einmaliges, zeitlich befristetes, interdisziplinäres, organisiertes Vorhaben, um festgelegte Arbeitsergebnisse im Rahmen vorab definierter Anforderungen und Rahmenbedingungen zu erzielen.

Aus Sicht einer Agilistin ist da viel Gutes dabei. Mit der Einmaligkeit und einer zeitlichen Befristung kommen wir zurecht. Interdisziplinarität finden wir großartig. Organisiert gehen wir vor, auch wenn das nach außen nicht immer so aussieht. Und passende Rahmenbedingungen halten wir für immens wichtig. Abhängig vom betrachteten Zeitraum haben wir ein Problem mit festgelegten Arbeitsergebnissen und Anforderungen. Denn wir wissen, dass in komplexen Umfeldern gute Lösungen emergent und nicht prädiktiv gefunden werden.

Was dieser Definition von Projekt vollkommen fehlt, ist der Hinweis auf einen zu schaffenden Wert. Genau das ist der Zweck eines Produkts, wie in dieser Definition zu sehen:

A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.

Diese Nichtübereinstimmung zwischen Projekt und Produkt kann entsprechend zu einem Zielkonflikt führen.

Welches Ziel hat eine Projektmanagerin? Gemessen am Projektdreieck achtet sie auf Zeit, Kosten sowie Inhalt bzw. Umfang. Tendenziell liegt der Fokus somit auf Output - also das "wie" oder "wie viel".

Welches Ziel hat eine Produktmanagerin? Sie hat den Kundennutzen bzw. einen für die Kundin zu schaffenden Wert im Blick. Tendenziell liegt ihr Augenmerk somit auf Outcome - also eine Ergebnisorientierung oder das "was".

Zur Auffrischung, wieso eine Produktorientierung wichtiger ist und wozu Unternehmen eigentlich existieren:

Our highest priority is to satisfy the customer through early and continuous delivery of [value].

Und genau hier ist der Knackpunkt. Mit einer Fokussierung auf Projekte dreht sich ein Unternehmen oft nur um sich selbst und beschäftigt sich mit sich selbst. Eine (Rück-)Besinnung auf den Kundennutzen und damit eine Betrachtung des gesamten Wertstroms findet dabei nur noch am Rande statt?

Denkblockaden durch Projektjargon

Die Gefahren und Stolpersteine der oben beschriebenen Widersprüche setzen sich in Praktiken fort, wie sie vielleicht auch (noch) in Deinem Unternehmen zu beobachten sind:

• Fixe Jahresplanung statt regelmäßige Anpassung. Wozu kurze Iterationen und frühes Kundenfeedback, wenn das übergeordnete Ziel nur einmal im Jahr angefasst wird? Wozu sollen (Dev-)Teams "schneller" werden, wenn sich im Zweifelsfall der strategische Rahmen oder das restliche Unternehmen nicht mitbewegt? Welche Ängste bzw. welches Menschenbild sind eigentlich die Ursache für solche Vorabplanungen?
• Lange Vorlaufzeit statt schneller Iteration am Markt. Wozu soll ich vorab einen wunderschönen Projektplan ausarbeiten, wenn ich dann ab Projektbeginn nur mit dessen Nachpflege beschäftigt bin? Wozu soll ich vorab detaillierte Funktionsabläufe und einen großen Featureumfang in internen Gruppen erdenken, wenn die mit Abstand besten Anforderungen von echten Kundinnen kommt?
• Effizienz statt Effektivität. Ich persönlich lege den Fokus zunächst klar auf die Effektivität - mir ist es wichtig, das Richtige zu tun. Erst danach gilt es, dieses auch richtig zu tun.
• Budgets... It depends. Ja, Budgets sind nicht zwangsweise schlecht. Die Frage ist, wie starr sie gehandhabt werden. Tatsächlich kann ein Budgetrahmen dabei helfen, sich auf einfache Lösungen zu konzentrieren. Dabei muss dem Unternehmen natürlich klar sein, dass nur zwei Punkte aus Inhalt, Zeit und Kosten erfüllbar sind. Egal ob mit agilem oder klassischem Vorgehen.
• Der Mensch als Verwaltungsobjekt statt wertvollem Vermögen. Warnhinweise hier sind Ausdrücke wie Vollzeitäquivalent bzw. Full Time Equivalent (FTE), Personentage (PT), Kapazitätsplanung, Auslastungsplanung und die feinen Unterschiede zwischen Aufwand und Zeit. Nur sprechen wir hier nicht von der Verwaltung von Maschinen, sondern von Menschen. Sobald Menschen im Spiel sind, reden wir von einem komplexen System, bei dem Werkzeuge aus der "einfachen" Welt nicht funktionieren.
• Regeln statt Prinzipien. Regeln sind leichter aufzustellen, wohingegen Prinzipien stärker wirken. Nur kann ich mich in einem festen Regelkorsett nicht mehr bewegen. Und sind Beweglichkeit und Anpassungsfähigkeit nicht zwei Ziele von Agilität?

Und wenn sich das Denken an diesen beispielhaften Punkten nicht in den richtigen Köpfen ändert, ist das neueste "agile Wundermittel" auch egal.

Fazit

Was ich damit sagen will:

• Seid euch eurer Veränderbarkeit bewusst. Nicht jedes Unternehmen oder jede Organisation kann oder will sich verändern. Das kann eine bewusste Entscheidung sein oder ein noch nicht erkannter Schmerz. Wichtig ist, das Thema ehrlich zu betrachten, um festzustellen, was tatsächlich erreichbar ist.
• Lokale Optimierung führt zu globaler Suboptimierung. Die Formel "ein Projekt plus ein Projekt gleich ein Produkt" wird selten aufgehen. Auch kann ein großartiges Dev-Team sich wunderbar in seiner Blase der Agilität entfalten. Nur agieren Teams nicht in Isolation. Eine reine Konzentration auf sich selbst wird zu Problemen an den Rändern der eigenen Suborganisation führen.
• Behaltet die Gesamt-Wertschöpfungskette im Blick. Ein besseres Produkt entsteht nicht durch das Weiterreichen in verschiedene Silos. Ein besseres Produkt entsteht, wenn der Wertstrom im Unternehmen gesamtheitlich betrachtet und angepasst wird.
• Maßgabe ist der Wert eines Produkts für eine Endkundin. Ziel sind nicht perfekte Prozesse oder Projekte mit Punktlandung. Eine Kundin interessiert schlussendlich nur, was ein Produkt für sie tun kann, welchen Schmerz dieses löst und welchen Job sie dadurch besser machen kann.

All dies führt zu der Erkenntnis, dass nachhaltiger Markterfolg nur durch volle Business-Agilität entsteht.

Und Werte wie Commitment, Fokus, Offenheit, Respekt und Mut passen immer. Egal ob im Projekt oder bei der Produktentwicklung ist der schätzende Umgang mit Menschen stets wertvoll.

Buchen Sie jetzt eine kostenlose Teamanalyse und wir finden gemeinsam heraus, wie ich Sie am wirkungsvollsten unterstützen kann.