On Lean and Agility

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.

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

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.

Grafik: Pixabay / Brian Penny - Lizenz

Itamar Gilad: The Product Operating Model Explained

Liam Kane: An Agile Transformation Dashboard

Mike Bowler: The big rewrite

Maret Kruve: ADEPT - The Product Discovery Framework that Fits on a Sticky Note

Celine Nguyen: The Perils of ‘Design Thinking’

Dass die öffentliche Verwaltung an manchen Stellen agiler ist als man vermuten würde, habe ich schon an der einen oder anderen Stelle geschrieben. Ich muss aber zugeben, dass jeder neue Fall auch mich etwas überrascht, so viele sind es schliesslich auch wieder nicht. Die aktuelle Überraschung tritt dabei an einer besonders prominenten Stelle auf, nämlich in der Bundesregierung, genauer gesagt im neuen Bundesministerium für Digitales und Staatsmodernisierung (BMDS).

Die erste Anwendung agiler Praktiken findet dabei gleich im Rahmen des Organisationsaufbaus statt. Statt möglichst lange möglicht im Verborgenen an einem möglichst perfekten Organigramm zu arbeiten, das dann nicht mehr verändert werden soll, hat das BMDS bewusst einen noch unfertigen Entwurf veröffentlicht, in gewisser Weise ein MVP. Dadurch sollen möglichst viele der zukünftigen Mitarbeiter früh Wünsche und Feedback äussern können, die dann in spätere Versionen einfliessen können.

Und damit nicht genug - diese Transparenz und Offenheit für Rückmeldungen soll nicht nur einmal stattfinden sondern mehrfach, das Ministerium plant "die Umsetzung in eine feste Struktur [...] in Form eines iterativen Prozesses", es wird also mehrere Veröffentlichungs-, Feedback- und Ansassungs-Schleifen geben, bis irgendwann ein Organisationsaufbau in einer Form definiert worden ist, die eine zeit lang stabil bleiben kann (so ähnlich habe ich auch schon einmal gearbeitet).

Alleine das ist für eine Behörde bereits beeindruckend genug, bei der Süddeutschen Zeitung kann man aber nachlesen, dass noch weitergehende Organisationsdesign-Prinzipien umgesetzt werden sollen: in einer Abkehr von sonst üblichen Paradigmen sollen die entstehenden Abteilungen nicht in Form von Silos auf Fach- oder Aufgabenteilungs-Basis entstehen, sondern um so genannte "Missionen" gruppiert sein, also um konkrete Modernisierungs- und Digitalisierungs-Aufgaben.

Eher der Umbruchssituation geschuldet, trotzdem aber bemerkenswert ist der Improvisationsgeist, von dem die Süddeutsche Zeitung berichtet. Statt sich lange mit den in der öffentlichen Verwaltung legendär langwierigen und komplizierten Bestellprozessen aufzuhalten werden Büroausstattungen gebraucht gekauft oder geliehen, unbürokratisch verteilt und bei Bedarf zweckentfremdet. Und noch etwas erinnert mich an ein eigenes Erlebnis: die pragmatische Beschaffung von dringend nötigem Klopapier.

Ob sich der "agile Geist" in diesem neuen Ministerium halten wird, ist natürlich noch nicht absehbar. Bestenfalls wird er in die Organisationskultur übergehen, schlimmstenfalls wird er sich nach und nach verflüchtigen. Aber alleine dass Agilität an einem solchen Ort, an dem man sie nicht vermuten würde, möglich ist, ist schon für sich genommen eine bemerkenswerte Geschichte. Eine die man durchaus weitererzählen könnte, wenn wieder jemand undifferenziert auf Behörden schimpft.

Ich bin ein Fan der Vorträge von Jeff Patton, zum einen wegen der inhaltlichen Tiefe, zum anderen wegen seines besonderen Stils, Life Visualisierungen für seine Ausführungen zu erstellen. In diesem Fall zum Thema des Minimum Viable Product (MVP).

Spannend an diesem Vortrag ist unter anderem, dass er durch die Erläuterung des MVP scheinbare Gewissheiten der agilen Produktentwicklung in Frage stellt, zum Beispiel die Definition of Done - aber nicht etwa, weil er in dieser Idee keinen Sinn sieht, sondern weil er aufzeigen kann, dass sie nur Teile dessen abdeckt, was man unter agil verstehen kann. 

Grafik: Wikimedia Commons / Craig Chelius - CC BY 3.0

Die Geschichte der Agilität ist voller Missverständnisse, besonders dann wenn es darum geht, wie das, was wir heute die agile Bewegung nennen, entstanden ist. Das liegt zum Teil einfach daran, dass die "agiler Vor- und Frühgeschichte" der 80er und 90er Jahre mittlerweile schon etwas länger her ist, zum anderen aber auch daran, dass sie sich zu Beginn in den Schatten abgespielt hat, ohne Namen und ohne Bekanntheit. Und an dieser Stelle wird es interessant.

Bevor wir dazu kommen aber kurz zu den beiden verbreitetsten Missverständnissen über die Entstehung des agilen Produkt- oder Projektmanagements: das erste ist, dass sie 2001 in Snowbird, Utah entstanden sind, als dort das Manifest für agile Softwareentwicklung verfasst wurde. Das zweite erkennt zwar an, dass Frameworks wie Scrum, Crystal und XP deutlich älter sind als das Manifest, geht aber davon aus, dass ihre Erfinder erst in Snowbird ihre Gemeinsamkeiten erkannten (und einen Namen dafür suchten).

Dass die Wahrheit nochmal anders geartet war, kann man im Podcast The Pragmatic Engineer erfahren, genauer gesagt in der Episode TDD, AI agents and coding, in der Kent Beck zu Gast ist, der Erfinder von XP (Extreme Programming) und der erste Unterzeichner des agilen Manifests. Neben XP-Praktiken und seinen Erfahrungen mit dem Einsatz von künstlicher Intelligenz teilt er auch Geschichten rund um die Verfassung des besagten Manifests, unter anderem, das dieses einem bestimmten Zweck diente.

Und damit kommen wir zurück zur Zeit, in der die agile Bewegung keinen Namen und keine Bekanntheit hatten, denn laut Beck sollte die Zusammenkunft in Snowbird genau das ändern. Es war nämlich kein gegenseitiges Kennenlernen, das dort stattfand (fast alle Beteiligten kannten sich bereits) und auch kein Erarbeiten von Gemeinsamkeiten (das war bereits früher passiert, u.a. bei einer gemeinsamen Hurtigruten-Kreuzfahrt einiger Teilnehmer). Es ging um Marketing und Brand Building.

Die angehenden Verfasser des agilen Manifests waren sich bewusst, dass sie bereits über eine kleine aber treue Gruppe von Anhängern verfügten, der Grossteil ihrer Zielgruppe (Software-Entwickler und IT-Manager) aber noch nicht bereit war, sich auf die neuen Arbeitsweisen einzulassen. In Anlehnung an das Technology Adaption-Modell aus dem Buch Crossing the Chasm suchten sie nach einem Weg, um die Lücke zwischen den ersten Anhängern und der Mehrheit der Anwender zu überwinden.

"Agile" oder die anderen in Snowbird erwogenen Namen, wie "Adaptive" oder "Lightweight" waren bewusst gedacht als einfache, attraktive und wirkmächtige "Dachmarken", mit deren Hilfe es einfacher werden sollte, die verschiedenen dahinterstehenden Frameworks bekannt und populär zu machen und so dafür zu sorgen, dass möglichst viele Softwareentwickler zu deren Anwendern werden konnten, wollten und in ihren Firmen auch durften.

Die Ironie dieser Geschichte liegt darin, dass der gewählte Vermarktungsansatz am Ende zu erfolgreich war - zumindest in der rückwirkenden Betrachtung von Kent Beck. Dadurch, dass fast ausschliesslich die positiven Effekte im Mittelpunkt der Aussendarstellung standen, wollten plötzlich auch Menschen und Organisationen dieses Label tragen, die die notwendigen Kriterien gar nicht erfüllten. Hierin liegt sicherlich einer der Ursprünge von Cargo Cult Agile und dem agil-industriellen Komplex.

Wie es besser gegangen wäre hat im Übrigen ebenfalls Kent Beck gezeigt, und auch darüber berichtet er im Pragmatic Engineer-Podcast. Für sein eigenes Framework Extreme Programming hat er einen Namen gefunden, der einerseits gut vermarktbar ist, andererseits aber klar macht, dass es anspruchsvoll und anstrengend sein kann, so zu arbeiten. Man kann lange darüber spekulieren, welchen Weg die agile Bewegung wohl gegangen wäre, wenn man sie auf diese Weise vermarktet hätte.