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.

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).

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,¹ 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.

Ein Bild sagt mehr als 1000 Worte (XLVIV)