On Lean and Agility

Eine steile These: die immer weiter um sich greifende Integration von KI-Agenten in die Softwareentwicklung führt dazu, dass gerade aus DevOps ein neues Vorgehendmodell entsteht, das zwar grundsätzlich die selben Tätigkeiten und Ideen umfasst, sie allerdings in der Schwerpunktsetzung so stark vertauscht, dass dadurch etwas Neues entsteht. Einen "offiziellen" Namen dafür gibt es noch nicht, naheliegend wäre aber "OpsDev".

Um kurz zu erklären, wie ich zu dieser These komme: unter DevOps verstehe ich nicht nur die Zusammenfassung von Development und Operations in einer Einheit, sondern auch eine dazugehörende Gewichtung. Entwicklung/Development macht darin den Grossteil der Arbeit aus, da sie nicht automatisierbar ist (bzw. bisher war). Damit das so bleiben kann, wird versucht, Betrieb/Operations weitgehend zu automatisieren, entweder durch die Entwickler selbst oder durch Plattform-Teams.

Gleichzeitig wird in DevOps das Releasen, Deployen, Betreiben und ggf. Reparieren der Software einfacher und schneller, da diejenigen die dafür zuständig sind auch die sind, die die Software ursprünglich geschrieben haben. Während reine Operations-Mitarbeiter oft rätseln müssen, warum sich der für sie fremde Code in bestimmter Weise verhält, fällt dem ursprünglichen Erzeuger eine Analyse und Fehlerbehebung meistens leichter.

Im Umfeld von KI-getriebener Softwareentwicklung ist es dagegen auf einmal die Entwicklung, die weitgehend automatisiert ist, oder zumindest teilautomatisiert (je nachdem ob bereits Agentic Development stattfindet oder ob nur gepromptet wird). Für diesen Tätigkeitsbereich den Grossteil der Arbeitszeit freizuhalten ist damit nicht mehr nötig, stattdessen bleibt mehr Zeit für andere Tätigkeiten übrig. Und damit kommen wir zum Betrieb.

Betrieb/Operations kann in der KI-getriebenen Softwareentwicklung auf einmal unerwartet aufwändig werden, da die Entwickler plötzlich vor dem selben Problem stehen wie früher die reinen Operations-Mitarbeiter. Die Anwendungen die deployt, released, betrieben, gewartet und repariert werden müssen, bestehen wieder aus fremdem Code, nur mit dem Unterschied, dass der "fremde Erzeuger" jetzt nicht mehr ein anderer Mensch ist, sondern ein KI Agent, also ein Computerprogramm.

Durch diese beiden Verschiebungen verändern sich auch die Anteile der beiden Tätigkeitsgebiete an der Arbeitszeit. Nicht mehr die Entwicklung steht im Vordergrund und der Betrieb im Hintergrund, sondern umgekehrt: im Vordergrund steht der Betrieb, im Hintergrund die nur noch in Teilen selbst durchgeführte Entwicklung. Und diese Umkehrung kann man auch in der Benennung deutlich machen, daher der Name OpsDev anstelle von DevOps.

Angesichts der Geschwindigkeit und der Tiefgreifenden Natur des aktuellen Umbruchs kann es natürlich sein, dass die These der Bewegung von DevOps zu OpsDev nur eine temporäre Gültigkeit hat und die Situation sich schon bald ganz anders darstellt, für den Moment entspricht sie aber dem, was ich gerade in verschiedenen Firmen wahrnehmen kann. Wenn des diese Seite in ein paar Jahren noch gibt kann ich ja überprüfen, wie die Entwicklung weitergegangen ist.

Bild: Pexels / Ekam Juneja - Lizenz

Nigel Thurlow: Why High Utilization Slows Knowledge Work

John Cutler: Tokens, Hours, Points, and Other Curious Proxies

Marty Cagan: A Fresh Definition of The Product Role

Roman Pichler: Product Operating Model - The Crucial Enabler for AI Success

Relativ schnell habe ich diesen Vortrag von Matt Dailey mit der Neurasthenie oder "amerikanischen Kankheit" assoziiert, die um das Jahr 1900 bei vielen Menschen diagnostiziert wurde, die glaubten, dass sie mit dem technischen und sozialen Wandel nicht mithalten könnten. Die Velocity Sickness hat ähnliche Ursprünge, manifestiert sich aber anders: in höherer Arbeits- und Informationsdichte durch gesteigerter Anwendung künstlicher Intelligenz - ohne nennenswerte Steigerung der Ergebnismenge oder Qualität.

Die Lösung, die Dailey vorschlägt, ist passenderweise von den aktuellen Trends der KI-getriebenen Softwareentwicklung geprägt. Zur Stabilisierung und Rationalisierung der oft halluzinierenden und erratischen KI-Agenten (die für ihn die Ursache der  Velocity Sickness sind) empfiehlt er, den Focus weniger auf die unmittelbare (und flüchtige) Interaktion mit den Agenten zu legen, und sich stattdessen auf grosse, langlebige und einordnende Dokumente zu konzentrieren, die den Agenten dann gemeinsam mit dem jeweiligen Prompt vermittelt werden.

Während ich bei seiner Initialen Problembeschreibung spannende Anstösse (und eine überfällige Thematisierung einer unterschätzten Gesundheitsgefahr) sehe, bin ich bei seiner Lösungsfindung nicht ganz sicher: selbst wenn das funktionieren sollte - ist das am Ende nicht nur Context Engineering?

Bild: Wikimedia Commons / Matthias Mullie - CC BY-SA 4.0

Es ist nicht mehr ganz nachvollziehbar wann die agile Community zum ersten mal mit der Idee der Monte Carlo-Simulation in Berührung gekommen ist, aber mit der Zeit hat sie sich zu einem Trend entwickelt, und wird immer wieder als alternative (oder sogar als bessere) Prognose-Methode im Vergleich zur Velocity genannt. Bei einer neutralen Betrachtung ist sich auch erstmal ein weiteres interessantes Werkzeug, nur bei der normativen Bewertung sollte man vorsichtig sein.

Um zuerst zu verstehen worum es geht: in agilen Teams wird mit der Monte Carlo-Simulation versucht die wahrscheinliche Umsetzungsdauer zukünftiger Arbeitspakete vorherzusagen, indem mit ähnlichen Arbeitspaketen der Vergangenheit Simulationen durchgeführt werden. Z.B. wird 1000 mal die durchschnittliche Umsetzungsdauer aus zehn jeweils zufällig ausgewählten bereits abgeschlossenen Arbeitspaketen ermittelt (mehr dazu hier). Das Ergebnis sieht dann etwa so aus.

Auf der X-Achse sieht man hier die Menge fertiger Arbeitspakete pro Woche, auf der Y-Achse die Häufigkeit in der so ein Ergebnis aufgetreten ist. Aus diesen Daten lassen sich Prozentzahlen ableiten: in über 80% der Simulationen wurden mindestens 50 Arbeitspakete geschafft, in 50% mindestens 60 Arbeitspakete, etc. Und daraus werden dann Prognosen abgeleitet: mit 80% Wahrscheinlichkeit werden wir 50 Arbeitspakete pro Woche schaffen, mit 50% Wahrscheinlichkeit 60, usw.

Diese Prognosen sind zwar etwas kompliziert formuliert, basieren dafür aber nicht auf Bauchgefühl sondern Empirie. Gleichzeitig gibt es aber auch Kritik: der Lean Experte Nigel Thurlow kritisierte etwa, dass Wartezeiten und Übergaben der Arbeitspakete in diesem Vorgehen nicht erfasst werden. Ein weiterer Kritikpunkt ist, dass es nur dann gut funktioniert, wenn die einzelnen Arbeitspakete ähnlich geartet sind, während bei Unterschieden zwischen ihnen die Aussagekraft schwindet.

Ein zusätzlicher Kritikpunkt kommt ausserdem von dem hier schon mehrfach erwähnten Oxford-Professor Bent Flyvbjerg, und in ihm wird die Monte Carlo-basierte Prognose für agile Teams gewissermassen mit ihren eigenen Waffen geschlagen: mit Statistiken, die auf historischen Daten beruhen. In einem Paper, das er zusammen mit anderen dänischen und englischen Wissenschaftlern verfasst hat, macht er auf ein unterschätztes Risiko aufmerksam - die dicken Enden (Fat Tails).

Hinter diesem Begriff verbirgt sich die Auffälligkeit, dass in komplexen Umgebungen (IT-Projekten, grossen Bauprojekten, etc.) das Risiko extremer Ausschläge an den Rändern extrem steigt. Um ein Beispiel in der Sprache der Monte Carlo-Prognosen zu nehmen: in nur 10% Prozent aller Fälle werden weniger als 20 Arbeitspakete pro Woche geschafft, aber in fast allen dieser Fälle sind es nur eines oder zwei oder Null - oder eine negative Zahl (d.h. bereits geschlossene müssen erneut bearbeitet werden).

Diese auf zahlreichen statistischen Daten echter Projekte beruhende Erkenntnis relativiert die Aussagekraft der Monte Carlo-Simulationen sehr stark. Denn wenn man mit 80-prozentiger Wahrscheinlichkeit einen stabilen Arbeitsdurchsatz prognostizieren kann, in den restlichen 20 % aber ein Risiko mit hoher Eintrittswahrscheinlichkeit steckt, das den gesamten Umsetzungsplan über den Haufen werfen kann, dann ist die versprochene Prognostizierbarkeit nicht wirklich gegeben.

Bevor Missverständnisse aufkommen: die Alternative zu Monte Carlo-Simulationen ist in komplexen Umfeldern nicht etwa eine andere Prognosemethode, sondern ein Vorgehen, das extreme Ausschläge früh zu entdecken versucht, und genug Zeit und Ressourcen hat um auf sie zu reagieren: Product Discovery, Lean Startup, Chaos Engineering, Extreme Programming oder Rapid Prototyping. Aber für das Arbeiten "zwischen den Ausschlägen" ist Monte Carlo natürlich geeignet (genau wie die Velocity auch).

Bücher zum Thema Unternehmenskultur gibt es mittlerweile unübersehbar viele, und wer einige davon gelesen hat wird gemerkt haben, dass auch die Vorstellungen davon, was Kultur eigentlich ist, ebenfalls unübersehbar vielfältig sind. Das Schöne daran: es gibt immer wieder interessante neue Sichtweisen, so wie in- dem Buch Making Organizational Culture Great - Moving Beyond Popular Beliefs, geschrieben von den amerikanischen Wirtschaftswissenschaftlern Jennifer A. Chatman and Glenn R. Carroll.

Passend zum von ihnen gewählten Untertitel ist es das Ziel der beiden Autoren, die Diskussion über Unternehmenskulturen zu versachlichen, weshalb der Aufbau um fünf populäre Annahmen kreist, die anhand realer und bekannter Beispiele validiert und in diesem Rahmen bestätig oder widerlegt werden (oder differenziert betrachtet, wenn das Ergebnis nicht eindeutig ist). Bei diesen fünf untersuchten Annahmen handelt es sich um die folgenden:

Unternehmenskultur entsteht irgendwie, existiert einfach so wie sie ist und kann nicht geändert werden

Diese Annahme ist in den Augen von Chatman und Carroll nicht völlig falsch, aber auch nicht zwangsläufig richtig. Während z.B. bei Kodak und PanAm ein Kulturwandel scheiterte war er bei Ford und Roche erfolgreich. Und bei Apple scheiterte er zunächst, um unter später unter neuer Führung (der von Steve Jobs) zu gelingen. Entscheidend ist jeweils der Kontext.

Unternehmenskultur kann verändert werden, aber nut Top-Down durch das Management

Auch hier ist die Antwort differenziert. Auf der einen Seite wird an Beispielen wie dem Southwest Airlines-CEO Herb Kelleher gezeigt, wie gross die Gestaltungsmöglichkeiten hoher Manager sein können, auf der anderen Seite wird an Firmen wie Boeing (vor der Fusion mit McDonnell Douglas) gezeigt, dass Kultur (in diesem Fall Ingenieur-Kultur) auch dezentral entstehen kann.

Unternehmenskultur ist etwas Weiches und Amorphes und kann nicht konkretisiert oder quantifiziert werden

Vermutlich das kontroverseste Kapitel des Buches. In ihm wir klar davon ausgegangen, dass Kultur konkretisierbar und messbar ist, und dass nicht nur qualitativ (etwa durch Zufriedenheits-Erhebungen) sondern auch quantitativ (etwa durch Umfang und Geschwindigkeit der Aneignung von Insider-Sprache). Praxisbelege gibt es auch hier, über deren Repräsentativität kann man aber diskutieren.

Unternehmenskultur erfordert, dass Mitarbeiter sich an sie anpassen, wenn sie Wirksamkeit entfalten oder keine Nachteile erfahren wollen

Für Chatman und Carroll ist das zu einfach gedacht. Zum einen erfordern viele Unternehmenskulturen (z.B. in innovativen Umfeldern) eine gewisse Nonkonformität, was im Widerspruch zum angepasst Sein steht, zum anderen ist Kultur oft implizit oder dynamisch, was Anpassungen erschwert. Sehr deutliche Kulturunterschiede sind aber meistens nachteilig, wie anhand von Disney und Netflix gezeigt wird.

Unternehmenskultur kann zu Mitarbeiterzufriedenheit beitragen, aber nicht zu wirtschaftlichem Unternehmenserfolg

Diese Annahme drehen die beiden Autoren zunächst um. Was eine (schlechte) Unternehmenskultur definitiv bewirken kann, ist ein wirtschaftlicher Schaden, wie sie u.a. am Beispiel Volkswagen zeigen. Darüber hinaus können eine Leistungs- oder Innovationskultur erkennbar zu wirtschaftlichem Erfolg beitragen, wofür Walmart und SpaceX als Belege genannt werden.

Nach diesen zentralen Kapiteln endet Making Organizational Culture Great mit einem weiteren, in dem konkrete Ratschläge zur Kulturgestaltung gegeben werden, auch hier wieder basierend auf vielen Praxisbeispielen. Vieles davon ist naheliegend, etwa die gezielte Personalauswahl oder Weiterbildung. Andere, wie das Verfassen von kulturellen Leitbildern oder das oben genannte Messen von Kultur sind kontrovers. Und einige, wie das Feuern kulturell unpassender Mitarbeiter, wären in Deutschland illegal.

Am Ende spiegelt sich aber in dieser Mischung, warum das Buch lesenswert ist. Es verbindet das Hinterfragen scheinbarer Gewissheiten mit konkreten Praxiserfahrungen und -anleitungen sowie kontroversen Standpunkten, an denen man sich Reiben kann. Das regt an zum Nachdenken, Hinterfragen und Ausprobieren - was passenderweise auch ein erfolgsversprechender Ansatz für die Erforschung und Gestaltung von Unternehmenskulturen ist. 

Bild: Unsplash / Chase Chappell - Lizenz

Dass viele "agile Methodiker" (Agile Coaches, Scrum Master, RTEs etc.) mit der Zeit eine eher negative Sicht auf die Arbeitswelt entwickeln ist bedauerlich, aber erklärbar. Wer sich täglich mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue, Overcompliance und Konzern-Trolle beschäftigen muss, kann leicht zynisch und sarkastisch werden. Um nicht selbst irgendwann so zu enden, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.

Diese hier hat auf den ersten Blick kein besonders agiles Ergebnis gehabt, schliesslich handelte es sich bei ihm um die Einführung von Quartalsplanungen. Eine Quartalsplanung - wie soll das mit den kurzen Lieferzyklen zusammenpassen, die Erkennungsmerkmal der agilen Arbeitsweisen sind? Um das zu erklären muss ich etwas ausholen, denn wie immer steckt auch hinter dieser Geschichte eine Entstehungsgeschichte, die man kennen sollte.

In der Vergangenheit hatte das Unternehmen mit dem ich zu dieser Zeit zusammengearbeitet habe einen eher klassischen Planungsansatz. Am Anfang stand die so genannte "Mifri" (die mittelfristige Finanzplanung), die jeweils für die nächsten drei Jahre die vorgesehenen Budgets festlegte, und das z.T. auf erstaunlich detailliertem Niveau. Den Budgets wurden dann für jeweils das nächste Jahr Ressourcen (also Mitarbeiter) zugeordnet. Für die ganzen zwölf Monate, ebenfalls in hohem Detailgrad.

Ob es jemals den Fall gegeben hatte, dass ein solcher Plan aufgegangen war, konnte keiner sagen. In den letzten zehn Jahren war das aber nicht der Fall gewesen, ständig liefen Plan und Realität auseinander. Zu Beginn eines Jahres wurde das versucht mit Mehrarbeit zu kompensieren, in der Mitte des Jahres gab es bürokratische Plananpassungen, ab Herbst floss ein Grossteil der Arbeit dann in Rechtfertigungen dafür, dass die Planziele nicht erreicht worden waren. So lief es jedes Jahr.

Irgendwann war der durch dieses Vorgehen erzeugte Schmerz zu gross geworden, und das Vorgehen wurde angepasst. Die mittelfristige Finanzplanung gab es zwar noch, sie wurde aber wesentlich weniger kleinteilig durchgeführt. Statt für einzelne Features waren die Budgets jetzt für Systeme oder Services vorgesehen, wodurch der Handlungsspielraum deutlich grösser wurde. In gleicher Art wurden auch die Jahresplanungen abstrahiert und vereinfacht.

Die eigentliche Planung fand ab diesem Zeitpunkt auf Quartalsbasis statt, also immer für drei Monate im Voraus. Und um zu verhindern, dass Überläufer-Themen des letzten Quartals de facto zu einer Verlängerung der Planungszyklen führten, wurden alle Aktivitäten und Prioritäten vor Planungsbeginn auf Null zurückgesetzt, so dass Restaufwände ggf. nicht mehr umgesetzt wurden. Mit der Zeit erwies sich das als wirkungsvolles Mittel gegen die bis dahin weit verbreiteten überoptimistischen Pläne.

Der so entstehende Kontrast zwischen dem alten und dem neuen Vorgehen war drastisch: vorher hatten die Pläne ab Frühling kaum noch Realitätsbezug, stattdessen flossen bemerkenswerte Aufwände in Eskalationen, bürokratische Umplanungen und Rechtfertigungen. Nach der Umstellung führten die kürzeren Planungszeiträume dazu, dass Plan und Realität ständig nah beieinanderlagen, wodurch die gerade genannten Aufwände unnötig (oder zumindest stark reduziert) wurden.

Als zusätzlichen Effekt konnte man eine deutliche Zunahme der Produktivität beobachten. Die gesamte bisher notwendige Eskalations, Umplanungs und Rechtfertigungszeit konnte jetzt für die eigentliche Arbeit verwendet werden, was zu deutlich schnelleren Umsetzungen führte. Und wenn Annahmen oder Planungen sich als unrealistisch erwiesen, belastete das nicht mehr das ganze Jahr, sondern nur die Zeit bis zur nächsten Quartalsplanung, bei der alle Pläne zurückgesetzt wurden.

Eine tatsächliche Erfolgsgeschichte also. Aber auch eine agile Erfolgsgeschichte? Wie oben gesagt, sind dafür drei Monate nicht zu lang? Statt einer eigenen Antwort darauf möchte ich die Primärquelle zitieren, das Manifest für agile Softwareentwicklung, bzw. dessen zweite Seite, die Principles behind the Agile Manifesto. Zu denen gehört nämlich auch eines, dass sich mit den anzustrebenden Umsetzungszeiträumen befasst, und das liest sich so:

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Die Hervorhebung ist von mir, den Rest kann man für sich sprechen lassen.

Das was Randy Shoup hier abliefert ist ein bemerkenswerter Einblick in die Welt grosser (IT-)Organisationen. Seine zentrale Botschaft, die er mit zahlreichen Beispielen aus seiner Zeit bei Ebay unterlegt: wenn ein Unternehmen eine dysfunktionale Unternehmenskultur hat, dann wird eine Modernisierung der Prozesse, Tools und IT-Systeme nur in begrenztem Ausmass zu Verbesserungen führen. Keine neue Erkenntnis, aber sehr anschaulich an einem bekannten Beispiel erklärt.

Eine zweite von ihm erzählte Geschichte, die in der oben genannten Enthalten ist, ist die der bei Ebay vorgenommenen Prozess-, Tool- und System-Modernisierungen, die trotz des letztendlichen Scheiterns an kulturellen Mustern zwischenzeitlich zu deutlichen Verbesserungen geführt haben. Shoup zufolge ist das mit einem geradezu minimalistischen Vorgehensmodell gelungen: der kontinuierlichen Identifikation von verlangsamenden Faktoren und deren sequentieller Abarbeitung durch ein die Entwicklungsteams unterstützendes Plattform-Team. Geradezu das Gegenmodell zu SAFe & Co.

Es gibt für Retrospektiven kein kategorisch richtiges oder für alle Situationen passendes Format, jedes Team kann seine eigene Variante entwickeln. Umgekehrt gibt es aber Verhaltensmuster, die besser zu vermeiden sind. Ein leider immer wieder anzutreffendes besteht daraus, Probleme nur zu identifizieren, für ihre Lösung aber später stattfindende Folgetermine einzurichten (oder noch schlimmer: sich lediglich vorzunehmen, derartige Termine zu planen).

Dabei ist es natürlich nicht so, dass es gar keine Konstellationen gäbe, in denen dieses Vorgehen Sinn macht. Wenn für eine Problemlösung z.B. Fachexperten oder Kooperationspartner anwesend sein müssen, die nicht zum Team gehören, dann muss man selbstverständlich vorher deren Verfügbarkeit und Bereitschaft in Erfahrung bringen. Aber bei Team-internen Themen, wie z.B. der Überarbeitung der eigenen Definition of Done, ist diese Sinnhaftigkeit nicht gegeben.

Dass trotzdem immer wieder so vorgegangen wird hat verschiedene Gründe. Ein häufiger ist der, dass auf diese Weise (scheinbar) mehr Themen erledigt werden können: nur Fünf Folgetermine zu planen geht schneller als Fünf Themen zu besprechen und zu Ergebnissen zu kommen. Auch dass das Thema für einen Teil der Anwesenden von nur wenig Interesse ist, ist ein  häufiger Grund. Und ein ebenfalls häufiger (wenn auch keineswegs Guter) ist der, dass man schon immer so vorgegangen ist.

Die Folgen dieser Vorgehensweise sind zum einen, dass die Kalender immer voller werden, und zum anderen, dass die angestrebten Lösungen und Ergebnisse immer später entstehen. Diese Phänomene stehen sogar in Beziehung zueinander. Weil für zusätzliche Meeting nicht unbegrenzt Zeit (und Lust) vorhanden sind, kann nur eine begrenzte Zahl zeitnah stattfinden. Schlimmstenfalls können sie sogar erst so weit in der Zukunft stattfinden, dass bis dahin schon die nächste Retrospektive stattgefunden hat.¹

Ein deutlich besseres Vorgehen ist es, die aufgekommenen Themen direkt in dem Termin zu behandeln, in dem sie zum ersten Mal thematisiert wurden. Um beim oben genannten Beispiel zu bleiben: wenn eine Überarbeitung der eigenen Definition of Done nötig ist, dann ist das etwas, was sofort angegangen und erledigt werden kann. Das Gleiche gilt auch für zahlreiche weitere Themen, von Coding Standards über zwischenmenschliche Unstimmigkeiten bis zur Planung des nächsten Team-Events.

Bleiben noch die gerade genannten Einwände. Einfach zu entkräften ist der Erste: mehrere Themen nur kurz anzudiskutieren und dann Folgetermine zu vereinbaren, sorgt eben nicht dafür, dass insgesamt mehr erledigt werden können. Es führt nur dazu, dass die Arbeit an mehreren parallel begonnen wird (ein wichtiger Unterschied). Nur an wenigen zu arbeiten, dafür aber richtig, lässt natürlich andere Themen unbehandelt - aber wenn sie wichtig bleiben, können sie nächstes Mal erneut eingebracht werden.

Dass bei manchen Themen nicht alle Mitglieder eines Teams nicht alle bei allen Themen in gleicher Tiefe mitreden können ist schon ein besseres Argument, aber auch kein wirklich Gutes. Zum einen bietet ein sofortiges und gemeinsames Angehen die Möglichkeit, neue Themen kennenzulernen und in ihnen besser zu werden. Und sollte der Extremfall zweier extrem unterschiedlicher Teilteams gegeben sein, lassen sich ggf. auch zwei Arbeitsgruppen bilden, von denen jede an jeweils einem Thema arbeitet.

So oder so sollten die Vorteile einer sofortigen Problembehandlung durch eine Workshop-artige Retrospektive klar sein. Schnelle Ergebnisse, kein Aufschieben der Lösungsfindung auf zukünftige Zeitpunkte, keine zusätzlichen Meetings, kein paralleles Herumwerkeln an mehreren Themen. Warum nicht alle Teams das so sehen ist mir schleierhaft, aber immerhin ist es meine Erfahrung, dass die meisten sich darauf hinweisen lassen und diesen Impuls dann auch verstehen und annehmen.