Kommentierte Links (CXXVIV)
 |
| Grafik: Pixabay / Brian Penny - Lizenz |
Donnerstag, 31. Juli 2025
Montag, 28. Juli 2025
Law of the second floor
 |
| Bild: Public Domain Pictures / Petr Kratochvil - CC0 1.0 |
Einige der "Gesetze", in denen Zwangsläufigkeiten und Regelmässigkeiten grosser Organisationen beschrieben werden, haben es in den letzten Jahrzehnten zu grösserer Bekanntheit gebracht, etwa Conway's Law oder Goodhart's Law. Heute soll es aber um eines der weniger bekannten gehen. Gefunden habe ich es im Blog des Agilen Otter, und es trägt den Namen TheLaw of the Second Floor, sinngemäss übersetzbar mit Das Gesetz der zwei Stockwerke.
Nobody two levels ABOVE OR BELOW you on the org chart really knows what your days are likeLaw of the second floor
Auch das sinngemäss ins Deutsche übersetzt: niemand, der in der Hierarchie zwei Ebenen über oder unter Dir ist, weiss womit Du Deine Arbeitszeit verbringst. Dass diese "Gesetzmässigkeit" (bei der es sich eigentlich um eine häufig zu machende Beobachtung handelt) dann Gesetz der zwei Stockwerke heisst, liegt in der Gleichsetzung von Hierarchieebene und Stockwerk begründet, die sich tatsächlich in vielen Unternehmen so wiederfindet.
Wie alle Beobachtungen ist auch die, auf der das Gesetz der zwei Stockwerke beruht, erst einmal wertneutral, allerdings ist implizit bereits die Bewertung enthalten, dass die Unkenntnis der Situation des jeweils anderen zu suboptmalen Ergebnissen führen wird - in Ermangelung eines genauen Wissens werden Annahmen getroffen, die zu einem gewissen Anteil falsch sind, was wiederum dazu führt, dass darauf beruhende Anweisungen oder die Reaktionen auf diese es ebenfalls sind.
Ein scheinbar naheliegender Verbesserungsansatz wäre es, dieses Problem an seiner Wurzel zu behandeln, indem man allen Beteiligten die Situation der jeweils anderen nachvollziehbar macht. Das ist aber schwer bis unmöglich - unten in der Hierarchie sind Detailgrad und Focus hoch, oben ist der Detailgrad gering und an Stelle eines thematischen Focus tritt eine breite, abstraktere Sicht. In beiden Fällen sind Kontext, Terminologie, etc. hochgradig spezifisch und z.T. gegenläufig.1
Versucht wird das trotzdem immer wieder, z.B. durch Mitarbeiter-Befragungen, Veröffentlichungen im Intranet, Townhall-Meetings und weitere Formate. Mehr als ein bestenfalls oberflächliches Verständnis entsteht dabei aber selten, alleine aufgrund des damit verbundenen Kommunikations- und Lernaufwandes, der den Beteilgten in der Regel unverhältnismässig erscheint und für den in den meisten Fällen auch gar nicht genug Zeit zur Verfügung steht.
Alleine diese Erkenntnis kann, wenn sie allgemein geteilt wird, zu deutlichen subjektiven und systemischen Verbesserungen führen. Zum einen, weil es die Annahmen und Erwartungshaltungen gegenüber anderen Personen realistischer macht, zum anderen dadurch, dass niemand mehr (irrigerweise) glaubt, im Zweifel bereits alles zu wissen, was für eine Entscheidung notwendig ist. Die gemeinsame Arbeit an übergreifenden Zielen kann dadurch deutlich erleichtert werden.
Freitag, 25. Juli 2025
Wie der Staat wieder handlungsfähig wird (III)
 |
| Bild: Wikimedia Commons / Anton Heiz - CC BY-SA 4.0 |
Unter den vielen Berichten über sich verzögernde Infrastruktur-Projekte ist dieser hier kaum aufgefallen: der Bau des Fehmarnsundtunnels (Teil der Fehmarnbelt-Querung) dauert mindestens drei Jahre länger als geplant. Auffällig dabei ist, dass ein Grossteil dieser Verspätung nicht etwa durch Probleme beim eigentlichen Bauvorhaben entsteht (das hat noch gar nicht begonnen), sondern durch Bürokratie: Ausschreibungsprozesse, zu beachtende Fristen, Einspruchsverfahren, Klagemöglichkeiten, etc.
Der Fehmarnsundtunnel ist dabei kein Einzelfall: wer mit Bauträgern und Behördenvertretern spricht bekommt zahllose derartige Geschichten zu hören, bei denen das eigentliche Vorhaben mehr oder weniger im Plan liegt, bei denen aber bürokratische Vorgaben immer wieder zu verzögertem Start oder zwischenzeitlichen Unterbrechungen führen - und das nicht etwa durch Behördenwillkür, sondern nur weil auch die sich an Gesetze und Vorschriften halten müssen.
Wie sehr es tatsächlich die Verwaltungsbürokratie ist, die alles verlangsamt, kann man an einem anderen Beispiel sehen. den LNG-Flüssiggas-Terminals, die ab dem Jahr 2022 an der Nord- und Ostseeküste gebaut wurden. Für deutsche Verhältnisse sind sie in atemberaubender Geschwindigkeit fertig geworden, zum Teil lag zwischen dem Beschluss des Vorhabens und dem Ende der Bauarbeiten weniger als ein Jahr. Und man kann jetzt bereits ahnen, wie das gelungen ist.
Das für diesen Zweck erlassene "Gesetz zur Beschleunigung des Einsatzes verflüssigten Erdgases" (LNG-Beschleunigungsgesetz) macht fast ausschliesslich Eines: es setzt andere Gesetze und Vorschriften ausser Kraft. Formulierungen wie "Abweichend von § X ..." oder "§ Y des Gesetzes Z ist nicht anzuwenden" ziehen sich durch seinen gesamten Text und machen deutlich klar, dass hier ein subtraktiver Wandel stattfindet. Mit anderen Worten: Verbesserung durch Weglassen.
Natürlich heisst das nicht, dass alle bisherigen Gesetze und Vorschriften sinnlos sind und abgeschafft werden sollten, derartige Kettensägen-Methoden gehören (wenn überhaupt) in ganz bestimmte Sektoren der Privatwirtschaft, die entfesselnde Wirkung eines Regulierungs-Rückbaus ist aber an diesem Fall mehr als deutlich zu erkennen. Wenn der Staat wieder handlungsfähig werden soll, ist das temporäre oder dauerhafte Ausserkraftsetzen also ein durchaus gangbarer Weg.
Dienstag, 22. Juli 2025
Das Effektivitäts-Framework von Tesla und SpaceX
 |
| Bild: CCNull / Marco Verch - CC BY 2.0 |
Es dürfte nur wenige Personen geben, deren Image sich in wenigen Jahren so stark gewandelt hat wie das von Elon Musk - vom ökologisch-liberalen Hoffnungsträger zum techno-faschischen Oligarchen. Was dabei in Vergessenheit zu geraten droht ist, dass Musk in seinen Unternehmen vieles umgesetzt hat, was aus "agiler Perspektive" als vorbildhaft gilt.Dazu gehört unter anderem auch das fünfstufige Effektivitäts-Framework von Tesla und SpaceX, der u.a. in seiner autorisierten eponymen Biografie beschrieben ist.
— Startup Archive (@StartupArchive_) July 20, 2025
1. Question every requirement (make them less dumb)
Die konsequente Umsetzung dessen, was auch als maximizing the amount of work not done bekannt ist. Wichtig dabei ist als Voraussetzung, dass Anforderungen immer einer Person zuzuordnen sein müssen, bei der man sie hinterfragen kann. Und ebenfalls, dass dieses Hinterfragen nicht nur als Legitim sondern als sinnvoll und gewünscht wahrgenommen wird, da jedem bewusst ist, dass niemand (egal wer er ist) davor gefeit ist, Fehler zu begehen - und zwar auch dumme Fehler.
2. Delete as much process as possible - even if it is too much
Ein Grundsatz, der seit Musks Kettensägen-Bürokratieabbau sicher kritischer gesehen werden muss, der aber einen rationalen Kern hat: von vielen (Umsetzungs-)Prozessen weiss man erst ob sie verzichtbar sind, wenn man durch ihre vollzogene Abschaffung getestet hat ob sie fehlen würden - andernfalls wird sich immer jemand finden, der sie verteidigt (im Zweifel der, dessen Job die Prozess-Aufrechterhaltung ist). Und wenn sie wirklich fehlen, kann man sie ja erneut einführen.
3. Simplify and optimize
Ab hier wird das Vorgehen dem ähnlicher, das aus Scrum, Kanban & Co bekannt ist. Wichtig ist dabei aber, dass zuerst die beiden ersten Schritte durchgeführt worden sind, um zu verhindern, dass unsinnige Anforderungen umgesetzt oder sinnlose Prozesse optimiert werden. Ein bekanntes Beispiel für die danach folgende Vereinfachung und Optimierung sind die Fertigungsstrassen der neuen Tesla-Fabriken, die erst in Zelten gebaut und optimiert werden, bevor die (teure) Fabrik um sie herum gebaut wird.
4. Accelerate cycle time
Sobald ein Fertigungs- oder sonstiger Arbeitsprozess grundlegend eingerichtet ist kann er in seinem Ablauf beschleunigt werden, z.B. indem Arbeitspakete kleiner geschnitten werden, Kopfmonopole aufgelöst werden oder Routinen entwickelt werden. Das Ganze idealerweise auf Basis von Daten wie Durchlaufzeiten, Qualitätsschwankungen oder Abnutzungsraten. Und auch hier gilt: die vorherigen Schritte müssen vorher stattgefunden haben, sonst riskiert man, etwas Falsches zu beschleunigen.
5. Automate
Dass die Automatisierung von Prozessschritten erst ganz am Ende erfolgt, hat einfache Gründe: sie ist kostspielig, und sollte daher erst stattfinden, wenn möglichst klar ist, dass das was automatisiert wird wirklich sinnvoll und effektiv gestaltet ist. Und sobald die Automatisierung stattgefunden hat, sind die Anforderungen und Abläufe der Sichtbarkeit der Menschen entzogen, und damit auch dem kritischen Hinterfragen. Frei nach Thorsten Dirks: automatisierte Scheissprozesse sind zu vermeiden.
Wie oben gesagt, spätestens Elon Musks Tätigkeit für die US-Regierung, in der sich sein Effektivitäts-Framework wiedererkennen lässt, hat aufgezeigt, dass es nicht in jeden Kontext übertragen werden kann oder übertragen werden sollte. Gleichzeitig hat es seine Unternehmen aber unbestreitbar erfolgreich gemacht, bis hin zu zeitweisen Quasi-Monopolen auf ihren Märkten. Wie so oft gilt daher auch hier: bitte nicht unhinterfragt kopieren, sondern zuerst kritisch bewerten. Z.B. mit den eigenen Schritten 1 bis 3.
Freitag, 18. Juli 2025
Flight Levels
Eine Gemeinsamkeit praktisch aller bekannten agilen Vorgehensmodelle ist, dass sie aus Amerika kommen und auch von dort angesiedelten Zertifizierungs- und Standardisierungs-Organisationen verantwortet und weitwerentwickelt werden. Es gibt aber Ausnahmen von dieser Regel, und eine davon kommt sogar ursprünglich aus dem deutschsprachigen Raum: die Flight Levels, entwickelt von Klaus Leopold aus der österreichischen Hauptstadt Wien.
Die zugrundeliegende Idee ist zunächst einfach: es wird davon ausgegangen, dass sich alle Arten von Arbeit, die in grossen Organisatinen durchgeführt werden, einem von drei Flight Levels (Flug-Höhen) zuordnen lassen. Operative Arbeit bildet das unterste Flight Level 1, teamübergreifende Koordination (möglichst End to End) das mittlere Flight Level 2, Strategie-Entwicklung und organisationsweite Zielsetzungen finden auf dem oberen Flight Level 3 statt.
Wichtig dabei ist, dass diese drei Flughöhen nicht (!) mit Hierarchieebenen verknüpft, bestimmten Organisationseinheiten zugeordnet oder auf eine andere Art und Weise geschützt oder exklusiv gehalten sind. Stattdessen kann und soll hierarchie- und einheitsübergreifend jeder eingebunden werden können, der zu einem Thema etwas beitragen kann, unabhängig davon wo in der Organisation er fachlich oder disziplinarisch verortet ist.
Wie Vieles andere, das in der agilen Bewegung entstanden ist, ist diese Idee keine komplette Neuentwicklung, sondern findet sich in ähnlicher Form bereits an anderen Stellen, z.B. im St. Gallener Management-Modell. In der agilen Methodenwelt haben die Flight Levels aber eine spezielle Lücke finden und schliessen können: die der fehlenden Kanban-Skalierungsframeworks. Ursprünglich sind sie auch als Ergänzung des "Lehrstoffs" der Kanban University entstanden und wurden erst später eigenständig.1
Dieser initiale Kanban University-Hintergrund ist auch die Erklärung dafür, dass die mit den Flight Levels verbundenen fünf Praktiken jedem Anwender von Wissensarbeits-Kanban bekannt vorkommen dürften. Es handelt sich um:
- Die Situation visualisieren
- Fokus setzen
- Agile Interaktionen durchführen
- Veränderungen messen
- Die Strukturen und Abläufe verbessern
Alles in allem also um einen kontinuierlichen Visualisierungs- und Verbesserungsprozess der Wertschöpfung, wie er für Kanban typisch ist.
Ebenfalls erkennbar aus Kanban übernommen ist der bewusste Verzicht auf einen formellen Rahmen aus vorgegebenen Rollen, Meetings und Vorschriften, an dessen Stelle der bewusste Start mit dem bestehenden Ist-Zustand tritt, der dann nach und nach optimiert werden kann. Daraus erklärt sich dann auch die Selbstbeschreibung als blosser "Denkansatz", der in bewusstem Kontrast zu den im Vergleich formalisierteren Ansätzen wie SAFe oder Scrum steht.
Interessant ist dabei, dass es ab der Trennung von der Kanban University (ca 2020) doch zu einer stärkeren Ausdifferenzierung und Vergrösserung der Flight Levels-Idee gekommen ist. Zwar nicht durch Meetings und Rollen, aber durch Erweiterungen wie die "Flight Items" genannten Arbeitspakete, die auf "Flight Routes" durch die Flight Level systeme fliegen, deren Analyse und Design zum Gegenstand von Werkzeugen und Praktiken wie z.B. der "Work Systems Topology" wird.
Im Zusammenhang damit sind schliesslich auch für die Flight Levels die für die agilen Frameworks typischen mehrtägigen Workshops entstanden, an deren Ende man sich einen farbigen Badge in den Lebenslauf einfügen kann, etwa "Flight Levels Professional" oder "Flight Levels System Architecture". Auf den Begriff der Zertifizierung wird dabei zwar bewusst verzichtet, die Art der Nutzung in Lebensläufen und Ausschreibungen ist aber sehr vergleichbar.
Trotz dieser offensichtlichen Gewinnerzielungsabsicht (die für sich genommen auch nicht verwerflich ist) hat sich Flight Levels in weiten Teilen der agilen Community bisher den Ruf eines irgendwie anderen, noch nicht komplett kommerzialisierten Vorgehensmodells erworben, nicht zuletzt wegen seines charismatischen Gründers Klaus Leopold, der es geschafft hat sich als einer der wenigen deutschsprachigen "agilen Thought Leader" zu etablieren.
Ob man damit tatsächlich etwas anfangen kann, liegt am Ende bei den eigenen Präferenzen. Wer offene Ansätze wie Kanban mag wird auch Flight Levels mögen, wer Wert auf stützende Rahmenbedingungen legt, wird eher mit den stärker aufformulierten Frameworks glücklich werden. Und wer aus der technischen Dimension der Agilität kommt wird den Ansatz mit freundlichen Interesse betrachten, ihn aber vor allem wegen seines Prozess-Minimalismus mögen. Jeder wie er mag.
Dienstag, 15. Juli 2025
Das morphende Daily
 |
| Bild: Unsplash / Carine L. - Lizenz |
Es ist eine der klassischen Fragen, mit denen sich jede grössere Organisation früher oder später beschäftigt - wie schaffen wir es, dafür zu sorgen, dass mehrere zusammenarbeitende Teams unbürokratisch die notwendigen Informationen untereinander austauschen können? Formate dafür gibt es viele, vom Scrum of Scrums über die Gilde und die Community of Practice bis zur Management- oder Spezialisten-Abstimmung. Eines ist aber erstaunlich unbekannt - das morphende Daily.
Die Grund-Idee, die dieses Format von fast allen anderen unterscheidet, ist, dass kein zusätzliches Meeting eingerichtet wird, in dem die einzelnen Teams in Gänze oder durch Vertreter zusammenkommen. Stattdessen werden lediglich die normalen Daily-Termine der Einzelteams abgehalten, mit nur einer einzigen Besonderheit: sie finden sequenziell nacheinander statt, und zwar in ein und demselben (physischen oder digitalen) Raum.
Stellen wir uns der Einfachheit halber ein Projekt mit vier Teams vor. Von denen hält das erste sein Daily-Meeting um Neun Uhr ab, das zweite seines um Viertel nach Neun, das dritte um Halb Zehn, das vierte um Viertel vor Zehn (es sind also die agil-typischen 15 Minuten). Und wie es in vielen agilen und nicht-agilen Teams üblich ist, sind diese Meetings öffentlich - jeder der interessiert ist kann zu Besuch kommen, solange er nicht ablenkt, stört oder die Abläufe durcheinanderbringt.
Wie in diesem Szenario die einfachste Form der Informationsübermittlung aussehen könnte, erschliesst sich sofort - jedes Team kann einfach eines oder mehrere Mitglieder bestimmen, die während der gesamten (und mit einer Stunde noch recht überschaubaren) Dauer im Raum bleiben, den jeweils anderen Teams für Fragen zur Verfügung stehen und gegebenenfalls darauf aufmerksam machen können, was aus dem eigenen Team für die anderen relevant sein könnte.
Eine etwas strukturiertere, aber noch immer einfache Variante kann daraus bestehen, dass ein Team einem oder mehreren der anderen im Voraus übermittelt, welches von deren Mitgliedern es gerne am jeweiligen Tag als Gast bei sich haben würde. Das kann z.B. der Spezialist für ein bestimmtes Thema sein (der UX Designer, der Tester, etc.), zu dem aktuell von Abstimmungsbedarf ausgegangen wird. Ggf. kann er im Daily seines eigenen Teams auch bereits Vorklärungen vornehmen.
Auch für übergreifende Rollen, wie Projektleiter, Architekten, Kundenvertreter oder sonstige Stakeholder kann dieses Format geeignet sein. Alleine dadurch, dass sie während der Dailies im Raum bleiben, sind sie über alles Wesentliche aus allen Teams im Bilde, vom Arbeitsfortschritt über aktuelle Probleme bis zu zu klärenden Punkten. Und je nach Rolle können sie sich auch selbst daran beteiligen, z.B. dadurch, dass sie selbst das letzte der aneinandergereihten Dailies durchführen.
Ich habe dieses Vorgehen in verschiedenen Projekten mit bis zu acht Teams erlebt, und es hat in allen einen einfachen Informationsaustausch ohne zusätzliche Abstimmungs- und Koordinationsmeetings ermöglicht (zumindest auf Tagesbasis, wöchentliche oder monatliche Planungs- und Review-Termine sind nochmal ein eigenes Thema, selbst wenn man oft auch sie nach einem vergleichbaren Muster aufeinanderfolgend abhalten kann).
Ein spannendes Phänomen ist dabei, dass es nach einiger Zeit dazu kommen kann, dass die Grenzen zwischen den Dailies der Teams sich auflösen. Vor allem wenn es gelingt, dass Teams mit tendenziell grösseren Berührungspunkten direkt aufeinanderfolgen, kann es an den Schnittstellen zu kurzen Abstimmungen und Übergaben kommen, so dass ein fliessender Übergang ohne klare Grenzen entsteht, das morphende Daily eben, das durchgehend fortläuft und bei dem sich nur die Teilnehmer verändern.
Natürlich wird dieses Format nicht in jedem Kontext passen, und man sollte sich auch bewusst machen, dass bestimmte Voraussetzung zwingend erforderlich sind, etwa die Fähigkeit sich kurz zu fassen und auf das Wesentliche zu beschränken, oder die Fähigkeit auch in diesen kurzen Terminen auf unerwartete Entwicklungen einzugehen, selbst wenn der ursprüngliche Plan etwas anderes vorgesehen hat, das dann ggf. bis zum nächsten Tag warten muss.
Für alle, denen etwas daran liegt, dass mehrere zusammenarbeitende Teams unbürokratisch und ohne zusätzliche Meetings Informationen austauschen und Abstimmungen vornehmen können, ist ein morphendes Daily aber etwas, das man auf jeden Fall ausprobieren sollte, und das man möglicherweise bald so gut finden wird, dass man nicht mehr darauf verzichten möchte.
Freitag, 11. Juli 2025
Now we've given them every freedom and they still don’t do what we want
Ich freue mich immer wenn ich auf jemanden verweisen kann den ich kenne, in diesem Fall auf Michael Mahlberg, bzw. auf seinen wie immer hörenswerten Vortrag auf der Konferenz Agile Meets Architecture 2025, der den wirklich schönen Titel trägt "Now we've given them every freedom and they still don’t do what we want".
Inhaltlich beleuchtet er die Rahmenbedingungen und der Führungsstile, deren Verständnis nötig ist, um zu wissen, wie man selbstorganisierten Teams eine Umgebung schafft, in der sie motiviert arbeiten und möglichst grosse Wirkung haben können (also das tun, was eigentlich jeder in seinem Beruf möchte).
Dienstag, 8. Juli 2025
Stakeholder
Bevor es losgeht muss ich mich kurz entschuldigen, und zwar für das Symbolbild auf dieser Seite. Aber was soll ich sagen, nach all den Jahren, in denen ich den Begriff so oft falsch geschrieben gesehen habe - es gibt Gags, die muss man mitnehmen. Aber genug davon, werden wir seriös. Wer irgendwo im agilen oder nicht agilen Produkt- und Projektmanagement unterwegs ist, wird an dieser Stelle bereits ahnen, um was es heute geht - die Stakeholder, wer sie sind und was sie tun.
Der Begriff ist natürlich nicht abgeleitet von dem Steak, sondern von dem Stake, einem dieser unglaublich vieldeutigen englischen Worte. Es kann (Wett-)Einsatz, Beteiligung, Wagnis, Risiko, Anteil oder Interesse bedeuten,1 und wird in der Wirtschafts-Literatur häufig als "Interessenvertreter" übersetzt. Das ist generisch genug um jede mögliche Person oder Gruppen einzuschliessen, aufgrunddessen aber auch sehr vage. Es macht daher Sinn konkreter zu werden und häufige Stakeholder-Rollen zu beschreiben.
Interne Anwender
Die häufigste und offensichtlichste Stakeholder Rolle ist die derjenigen Personen, die ein Produkt benutzen sollen oder es bereits tun. Der Untertyp der internen Anwender arbeitet dabei im selben Unternehmen, das das Produkt auch entwickelt. Er ist damit ansprechbar und bekannt, kann aber oft zur Nutzung gezwungen werden, was die Beziehung zu ihm tendenziell einseitig gestaltet.
Externe Anwender
Im Gegensatz zum internen Anwender arbeitet der externe Anwender nicht im selben Unternehmen, das das Produkt entwickelt. Er kann durch seine Nutzungs- und ggf- Kaufentscheidung (bzw. durch seine Entscheidung, etwas nicht zu nutzen) sehr viel stärkeren Einfluss auf die Produktentwicklung nehmen, ist der Entwicklungsorganisation dafür aber vor allem aus der (fehleranfälligen) Marktforschung bekannt.
Käufer
Eine häufig vergessene, dafür aber sehr einflussreiche Stakeholdergruppe. Grosse Firmenanwendungen wie ein CMS, ein CRM oder ein ERP werden praktisch nie von den eigentlichen Anwendern eingekauft, sondern fast immer von einer zentralen Organisationseinheit, die oft andere Interessen hat als nur die Nutzerfreundlichkeit. Zum Beispiel einen niedrigen Einkaufspreis.
Verkäufer
In gewisser Weise das Gegenstück zum Einkäufer, im Gegensatz zu diesem aber in den meisten Entwicklungsorganisationen deutlich präsenter und einflussreicher. Klassische Interessen von Verkaufs-Abteilungen sind regelmässige neue Funktionen, das Einbauen von Sonderwunsch-Features ihrer Kunden und Vorführ-geeignete Showeffekte des Produkts.
Eigentümer
Mit dem Eigentümer ist hier der Inhaber der Firma gemeint, durch die das jeweilige Produkt entwickelt wird. Häufig ist der Eigentümer auch der Gründer, bzw. einer seiner Nachkommen. Immer wieder anzutreffen sind dabei die "kleinen Könige", die es gewohnt sind widerspruchslos zu führen, auf der anderen Seite aber auch sehr sozial eingestellte Menschen, denen familiäre Verhältnisse wichtig sind.
Inverstoren/Risikokapitalgeber
Vor allem im Startup-Umfeld anzutreffen, zum Teil aber auch in der Variante, dass älteren innovativen Unternehmen der nächste Wachstumsschritt ermöglicht wird. Das investierte Geld soll bei ihnen nicht sofort Rendite abwerfen, sondern sich eher mittelfristig vermehren - dann aber auch richtig. Zentrale Anliegen sind die Förderung von Innovation und der Aufbau skalierbarer Stukturen.
Shareholder
Wie der Name es sagt, handelt es sich bei diesen Stakeholdern um Anteilseigner börsennotierter Unternehmen, zum Beispiel Rentenfonds oder Vermögensverwalter. Von ihnen wird meistens ein möglichst stetiges Einkommen bei möglichst geringem Aufwand gewünscht, was in der Entwicklung bedeutet, die Produkte in einen stabilen Cash Cow-Modus zu bringen.
Interne Unterstützer/Sponsoren
Im gleichen Unternehmen angesiedelt, das das Produkt entwickelt, kann der interne Unterstützer oder Sponsor aus ähnlichen Motiven handeln wie der externe Investor oder Shareholder, kann aber auch politische Motive haben, zum Beispiel das an sich ziehen möglichst prestigeträchtiger Projekte oder das Aufbauen möglichst grosser eigener Entwicklungsmannschaften.
Interne Entwickler
Eine weitere häufig vergessene Stakeholder-Gruppe sind die internen Entwickler, also die, die das Produkt selbst bauen, testen und ggf. betreiben. Ein häufiges (und zu vielen anderen Stakeholdern gegenläufiges) Interesse ist die Investition von Zeit und Aufwand in Infrastruktur, Abbau technischer Schulden, Modernisierung, etc. Ein häufiges Problem ist, dass die Sinnhaftigkeit dessen nicht gut vermittelt wird.
Externe Entwickler
Egal ob einzelne Freelancer oder ganze Dienstleister-Teams - viele Entwickler sind nicht intern fest angestellt sondern "gemietet". Das kann zu sehr stark ausgeprägten Egoismen führen, von der Maximierung der "billable Hours" bis hin zum "Resume-driven Development", andererseits aber auch zu im Vergleich höheren Qualitätsansprüchen, um durch gute Arbeit eine Wiederbeauftragung zu sichern.
Interne Entwicklungspartner
Interne Entwicklungspartner sind im Einfachsten Fall andere Entwicklungs-Einheiten, mit denen man sich Produkte, Systeme, Kunden oder Vorgesetzte teilt. Im Fall ständig weiterentwickelter Produkte kommen ggf. auch solche dazu, die den Betrieb übernehmen, die für Support und Kundenservice zuständig sind oder die mit Hilfe des Produkts selbst eine Dienstleistung für einen Kunden erbringen.
Externe Entwicklungspartner
Externe Entwicklungspartner können kooperierende andere Firmen sein, die ein ihnen geliefertes (Teil-)Produkt in ihre eigenen Produkte integrieren (z.B. ein Betriebssystem in eine Hardware), es können aber auch solche sein, die selbst vorgefertigte Teilprodukte zuliefern, oder Open Source-Communities (wenn Teile des Produkts unter einer entsprechenden Lizenz erstellt werden).
Interne Regulierer
Zu diesen Stakeholdern können sehr unterschiedliche Personenkreise gehören, deren Gemeinsamkeit es ist, den Entwicklungseinheiten Vorgaben machen zu können. Die Software Architekten gehören etwa dazu, die Rechtsabteilung oder die Abteilung die das Corporate Design verantwortet. Je nach Einzelfall können zahlreiche weitere dazukommen.
Externe Regulierer
Im Wesentlichen verschiedene Gesetzgebende oder Gesetze durchsetzende Behörden. Das können auf internationaler Ebene untergeordnete Behörden der Europäischen Union, auf nationaler Ebene die Bundesanstalt für Finanzdienstleistungsaufsicht oder die Bundesnetzagentur, auf Landesebene der Landesdatenschutzbeauftragte, etc. etc. Sie alle können verbindliche Vorgaben erlassen und überprüfen.
Interne Anspruchsteller
Eine schwächere Variante der internen Regulierer. Anders als diese können sie zwar keine Verbindlichen Vorgaben machen, können aber auf Selbstverpflichtungen des Unternehmens aufmerksam machen und durch Thematisierungen in grösseren Runden Druck machen. Beispiele dafür wären die Gleichstellungs- und Nachhaltigkeitsbeauftragten.
Externe Anspruchsteller
Zu diesen Stakeholdern gehören zivilgesellschaftliche Gruppen jeglicher Art, etwa solche die Jugendschutz oder Umweltschutz als Ziel haben. Auch ihnen steht zwar kein unmittelbares Druckmittel zur Verfügung, durch Kauf- oder Boykottaufrufe, Demonstrationen, Öffentlichkeitsarbeit und ähnliche Massnahmen können sie aber durchaus Einfluss nehmen.
Wettbewerber
Nochmal eine Gruppe, an die man nicht sofort denkt, dabei eine durchaus einflussreiche. Durch Feature-Wettrennen, Copycat-Produkte, Preiskämpfe, besseres Design oder höhere Qualität können sie eine Entwicklungsorganisation beeinflussen und von ihr beeinflusst werden, wodurch sie definitiv die Kriterien erfüllen um zu den Stakeholdern zu gehören.
Geschäftspartner
Zu diesen letzten hier genannten Stakeholdern gehören alle, die zwar eigenständige Unternehmen sind, trotzdem aber zum Erfoolg eines Produkten beitragen können oder müssen. Das können Reparatur- und Vertriebspartner sein, Händler, Logistiker, Messeveranstalter, Werbeagenturen, Influencer, Reseller und noch zahlreiche weitere.
Und viele mehr ...
Diese Übersicht ist bereits lang, sie könnte aber vermutlich noch beliebig verlängert werden. Am Ende ist schliesslich auch die Anzahl potentieller Interessen an einem Produkt tendenziell unendlich, und damit auch die Anzahl der Interessenvertreter, bzw. der Stakeholder. Und genau wie Produkte und Märkte können auch Stakeholder sich ändern, es macht also Sinn, die immer wieder aufs neue zu analysieren, um zu wissen, wer sie sind, und wie man sich auf sie einstellen sollte.
1Aber auch Pfahl, Stab, Stütze, abgegrenzter Bereich, Stollen, Halterung, Daube, Überwachung, Scheiterhaufen und Vieles mehr
Freitag, 4. Juli 2025
Ein Bild sagt mehr als 1000 Worte (XLIX)
