Kommentierte Links (LXXXV)

Bild: Pixabay / Buffik - Lizenz

Das Internet ist voll von Menschen die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.

Timothy R. Clark : Agile Doesn’t Work Without Psychological Safety

Dass die blosse Einführung von neuen Methoden und Tools einer Firma nur selten zu mehr Agilität verhilft sollte sich eigentlich mittlerweile herumgesprochen haben, noch immer gibt es aber Firmen die genau so vorgehen und ihre Ziele dann nicht erreichen. Timothy Clark weist auf einen entscheidenden kulturellen Aspekt hin der ausserdem berücksichtigt werden sollte: die Psychologische Sicherheit. Für die Veranschaulichung übertreibt er ein bisschen, z.B. ist das von ihm genannte "swimming in fear" ein Zustand der in der Realität auch in schlechten Methodenumsetzungen eher selten ist. Mit dieser kleinen Relativierung im Hinterkopf ist sein Artikel aber sehr erhellend.

Ray Arell: The Rise of Hybrid Work and What it Means For Agile

Schon im letzten Sommer gab es die ersten Firmen die ihre Büros wieder für ihre Mitarbeiter geöffnet haben, eine Entwicklung die gerade wieder neu beginnt und sich in den nächsten Monaten verstärken dürfte. Kaum eine will aber in die vollständige Präsenzarbeit zurück, die Hybrid-Arbeit mit abwechselnden Präsenz- und Remote-Anteilen dürfte damit ein Trend der nächsten Jahre werden. Ray Arell stellt in diesem Zusammenhang zwei wichtige Aspekte heraus: Agilität geht auch als Hybrid-Arbeit, aber dafür braucht es die passenden Rahmenbedingungen in Form von Technik, Räumlichkeiten, etc.

Bill Wake: Refactoring, a Whole-Team Guide

Das was Bill Wake hier versucht ist wertvoll: er versucht Refactoring zu erklären, jene Tätigkeit von der viele Entwickler sagen, dass sie zwingend notwendig ist, die aber von vielen Produkt- und Projekt-Managern nicht verstanden und darum niedrig priorisiert wird. Da es sich um ein wirklich IT-spezifisches Thema handelt hilft es hier Vorkenntnisse zu haben, das meiste ist aber auch ohne sie zu verstehen. Für alle die den Begriff schon irgendwo gehört haben sich aber wenig Konkretes darunter vorstellen können eine klare Leseempfehlung.

Michael Mahlberg: Is the user story overrated? Some story patterns and formats to learn from

Apropos wertvoll. Auch diesen Text von Michael Mahlberg würde ich in diese Kategorie einsortieren. Irgendwie hat sich über die letzten 25 Jahre die Auffassung entwickelt, dass das in agilen Teams häufig verwendete Anforderungsformat "Story" eine Abkürzung oder ein Synonym von "User Story" wäre. Michael zeigt anhand verschiedener weiterer Story-Formate auf, dass das keineswegs so ist. Und natürlich fehlt auch der wichtige Hinweis nicht, dass das Entscheidende an einer Story nicht das Format oder der exakte Inhalt ist sondern die sie umgebende Unterhaltung der Beteiligten.

Willem-Jan Ageling: Here’s a Shocking Revelation - You Can Create Long-Term Plans with Scrum

Als Letztes ein Klassiker: nein, agil zu arbeiten bedeutet nicht, dass man auf langfristige Planung verzichten muss. Sie sieht an einigen Stellen etwas anders aus, das aber aus guten Gründen. Diese und die Möglichkeiten die Scrum für die langfristige Planung bietet arbeitet Willem-Jan Ageling hier sehr schön und differenziert heraus.

Der Team-Raum

Bild: Pexels / Fauxels - Lizenz

In der Arbeitswelt beschränkt sich das Hin und Her der Moden und Notwendigkeiten nicht nur auf Tools, Techniken und Methoden sondern betrifft auch Arbeitsflächen und Bürogestaltungen. Verschiedene unserer aktuellen und ehemaligen Kunden gestalten gerade nach einer längeren Phase der Heimarbeit ihre Büros neu, um Präsenzarbeit wieder zu ermöglichen. Eine zentrale Frage dabei: wie soll die ideale Arbeitsumgebung für ein agiles Team aussehen?

Als jemand der schon einige Firmen von innen gesehen hat darf ich Impulse und Beratung beisteuern, über die ich hier etwas reflektieren möchte. Um mit dem Wichtigsten anzufangen: Arbeits-Räume und -Flächen sollten meiner Meinung nach nichts sein, das möglichst stark optimiert wird, d.h. bei dem eine möglichst hohe Auslastung angestrebt wird. Die mag zwar verlockend sein um Kosten zu sparen, in der Realität führt sie aber in schlechte Arbeitsbedingungen und Produktivitätsverluste.

Das heisst natürlich nicht, dass wirtschaftliche Betrachtungen hier nicht sinnvoll sind, gerade aus einer wirtschaftlichen Sicht ist eine zu starke Optimierung aber nicht zielführend. Das in Nutzungs-optimierten Grossraum-Büros übliche eng gedrängte Sitzen, das lange Suchen nach freien Plätzen und die Verteilung von Teams über die gerade freien Plätze führen in einem Ausmass zu Effektivitäts-Verlusten, dass Kostenersparnisse dadurch wieder aufgefressen werden (mehr dazu steht hier).

Was dagegen sinnvoll ist, ist ein Arbeitsraum in dem ein Team durchgehend gemeinsam sitzen und arbeiten kann, der gross und hell genug ist um kein Gefühl der Beengung aufkommen zu lassen, nach aussen schallgeschützt ist und ständig verfügbare Rückzugs- oder Konzentrationsbereiche bietet. Bei den letzten sollte es sich explizit um keine allgemein buchbaren Meetingräume handeln (die dadurch meistens nicht kurzfristig verfügbar sind) sondern um eine Erweiterung des Team-Raumes selbst.

Derartige Räume wurden bereits in den 90er Jahren im Extreme Programming beschrieben, von agilen Pionieren wie Ken Schwaber und Martin Fowler empfohlen und haben später sogar ihren Weg zu SAFe gefunden, ich selbst habe sie schon in verschiedenen Variationen erlebt. Ein sehr guter Aufbau derartiger Arbeitsflächen könnte so wie in der folgenden Grafik zu sehen:*

Die zentralen Elemente sind sofort erkennbar: die grosse gemeinsame Tischgruppe an der das Team zusammenarbeiten kann (mit freien Plätzen für Onsite Customer o.Ä.), das schallgeschützte Séparée für Pair Programming, Telefonate oder 1:1-Gespräche und die Fläche für Stand up-Meetings vor einem Whiteboard oder Bildschirm. In anderen Varianten kann die letztgenannte Fläche auch Teil des Arbeitsraumes sein, so dass das Board von den Arbeitsplätzen aus durchgehend sichtbar ist.

Zu beachten ist, dass diese Raum-Anordnng von einer Konstellation ausgeht in der alle Team-Mitglieder regelmässig gemeinsam ins Büro kommen können und wollen. Aber auch da wo Teile der Teams zu anderen Standorten gehören oder viel von zu Hause aus arbeiten sind Teamräume möglich. z.B. so wie die in dieser Darstellung:*

Was man hier erkennt sind kleinere Tischgruppen, deren Achse auf einen grossen Wand-Bildschirm mit eingebauter Kamera ausgerichtet ist. Dadurch ist es möglich geografisch entfernte Kollegen im Raum sichtbar zu machen und auch für diese als Team sichtbar zu sein. Ihre Einbindung in implizite und beiläufige Kommunikation wird so wieder möglich. Séparées für Pairing und Telefonate gibt es auch hier, in diesem Beispiel gemeinsam von zwei Teams genutzt.

Egal welche dieser Varianten (zu denen natürlich noch zahllose weitere dazukommen) man vorstellt, die Reaktion ist zu Beginn in den meisten Fällen die gleiche: das geht so nicht, es ist zu teuer, zu gross, zu aufwändig einzurichten. Und tatsächlich ist es so - die meisten Firmen müssten Geld in die Hand nehmen um ihre Gebäude entsprechend umzubauen, viele müssten sogar umziehen und neu bauen. Sind derartige Büro-Konzepte damit überhaupt noch realistisch?

Die Antwort: natürlich sind sie es, wenn die Unternehmen denn in ihnen einen Wert erkennen. Und Wert ist auch ein entscheidender Punkt in den dazugehörigen Überlegungen. Was wird mehr wertgeschätzt, eine möglichst effiziente Flächennutzung oder eine effektivitätsfördernde Arbeitsumgebung? Und worin wird der grössere Mehrwert erkannt, in einem möglichst kleinen Budget für Mieten oder in gut ausgestatteten Mitarbeitern, die ihren Job motiviert (und damit auch schnell und gut) erledigen?

In vielen Fällen wird es so sein, dass tatsächlich die optimale Flächennutzung und die möglichst geringen Kosten für die Büro-Räume in der Priorität weiter oben stehen als das ungestörte und motivierte Arbeiten der Teams. Dort wo das der Fall ist wird das bessere Büro-Design allerdings auch nicht der nächste Schritt auf dem Weg zum agilen Arbeiten sein, da sind andere viel, viel grundlegender und dringender.

*Ggf. stimmen die Grössenverhältnisse nicht ganz, die Grafiken sind nicht mit professioneller Floorplan-Software erstellt.

8 Guiding Principles for Agile Coaches

Jason Yip ist einer jener Menschen denen ich schon lange auf Medium folge um Inspirationen zu sammeln. "In echt", also im Bewegtbild hatte ich ihn bis vor kurzem aber noch nicht zu Gesicht bekommen, bis ich zufällig auf seinen Vortrag auf der Agile India-Konferenz aufmerksam geworden bin. Und siehe da, auch zuhören kann man ihm gut.

Um seine Worte kürzestmöglich zusammenzufassen: Agile Coaches (und Scrum Master) tun sich keinen Gefallen damit ihre Arbeit auf die Teamebene zu beschränken. Nur wenn sie auch im Gesamtunternehmen wirksam und sichtbar sind können sie ihren Job richtig machen.

Driven Development

Grafik: Wikimedia Commons / Nevit Dilmen - CC BY-SA 3.0

Was motiviert eigentlich die Menschen bei ihrer täglichen Arbeit? Gerade im Rahmen der agilen Produktentwicklung ist diese Frage zentral, schliesslich beruht das ganze Konzept darauf, dass (teil-)autonome, selbstorganisierte Teams ohne Detailsteuerung durch einen Manager ihre Arbeit erledigen. Der Antrieb muss also von innen kommen, und nicht nur das - es sollte auch einer sein, der sich in einem Team- und Ergebnis-orientierten Verhalten manifestiert.

Auf diese Überlegung lässt sich noch weiter aufbauen. Bedingt durch Unternehmenskultur, Belohnungs- und Bestrafungs-Muster, berufliche Sozialisierung und Personalauswahl werden die Antriebe der verschiedenen Mitarbeiter in vielen Fällen ähnlich sein (oder über die Zeit ähnlich werden). Die verbreitetsten unter den Motivationen werden damit auch zu den (inoffiziellen) Treibern der gesamten Produktentwicklung. Deshalb ist es wichtig zu differenzieren: welche derartig von Motivationen angetrieben Entwicklungs-Typen gibt es und was bewirken sie?

Fear Driven Development 

Gleichzeitig der unschönste Typ und einer der am weitesten verbreiteten. In ihm werden die Menschen von Angst getrieben, sei es die Angst vor der Kündigung, die Angst vor öffentlich vorgetragenen Schuldzuweisungen oder die Angst vom Chef angeschriehen zu werden. Die Auswirkung ist eine Kultur in der versucht wird Fehler zu vermeiden (mit mehr Sorgfalt, aber auch mit mut- und risikolosen Entscheidungen) oder in der gemachte Fehler versteckt und vertuscht werden.

Incentive Driven Development

In gewisser Weise das Gegenstück zum letzten Typ, allerdings wird eine positive Sanktionierung angestrebt statt eine negative. Es tritt dort auf wo Gehaltserhöhungen oder Bonuszahlungen an bestimmte Ziele gekoppelt sind. Das Problem - Geld kann zwar motivationssteigernde Auswirkungen haben, häufig sind sie aber auch negativ: nicht incentivierte Arbeit wird nachlässig erledigt, ungleiche Lohn-Niveaus entstehen und um das Geld zu bekommen werden mitunter Ergebnisse geschönt.

Promotion Driven Development

Eine Variante die das Incentive Driven Development enthält aber noch darüber hinausgeht. Zusätzlich zu mehr Geld umfasst die Belohnung jetzt auch einen höheren Status und einen grösseren Einfluss. Auch diese Aussicht kann zwar zu Leistungssteigerungen führen, aufgrund der beschränkten Anzahl der Positionen in die befördert werden kann entsteht oft aber auch eine Ellenbogen-Mentalität, bei der der eigene Erfolg wichtiger ist als der des Teams.

Resume Driven Development

Eine Sonderform die in erster Linie externe Mitarbeiter betrifft (oder interne die bald den Job wechseln wollen). Der damit verbundene Antrieb ist es, möglichst viele beeindruckend klingende oder den eigenen Marktwert steigernde Tätigkeiten in den Lebenslauf schreiben zu können um so auf dem Job-Markt bessere Aufträge zu bekommen. Aus Team- und Firmensicht ist das ein eher schädlicher Motivationstreiber, da er dazu führen kann, dass andere Themen bewusst vernachlässigt werden.

Hype Driven Development

Egal ob es die neuesten Tools, die gerade angesagte Programmiersprache oder die zur Zeit moderne Methode sind, das Hype Driven Development wird davon getrieben, dass die Beteiligten immer auf die aktuellen Trends aufspringen und sie bei sich umsetzen möchten. Das kann Vorteile haben (Stillstand und veraltende Herangehensweisen werden vermieden), kann aber auch zu unnötig häufigen Umstellungsaufwänden führen, durch die wichtigen Themen weniger Kapazität zur Verfügung steht.

Ego Driven Development

In gewisser Weise der Hype einer Person um sich selbst. Dort wo das eigene Ego so gross ist, dass man sich nur noch mit den wichtigsten und forderndsten Aufgaben beschäftigen will tritt es genauso auf wie bei eher kleinen Egos, die wichtige Aufgaben zu Kompensationszwecken benutzen. In die richtige Richtung gelenkt kann man zum geschätzen Experten werden (der dann aber oft zum Flaschenhals wird), häufig sind aber auch Besitzstandsdenken und fehlende Kritik- und Zusammenarbeits-Fähigkeit.

Responsibility Driven Development

Dafür würde das deutsche Wort "Pflichterfüllung" passen. Getrieben von einem Arbeitsethos das Zufriedenheit aus der guten Ausübung der übertragenen Aufgabe zieht trägt hier jeder seinen kleinen teil zum grossen Ganzen bei. Aus Organisationssicht eine gute Variante, wenn auch eine die nicht ganz ohne Risiko ist - schlimmstenfalls werden hier auch missverstandene oder obsolet gewordene Aufgaben unbeirrt ausgeführt, sogar dann wenn das Gesamtsystem davon geschädigt wird.

Altruism Driven Development

An dieser Stelle geht es schon sehr stark in Richtung Selbstorganisation. Der Motivationstreiber ist die Zufriedenheit die aus dem erfolgreichen Helfen und Reparieren entstehen kann. Das führt dazu, dass nicht nur die eigene Aufgabe erledigt wird sondern auch dort eingesprungen wird wo es Kapazitäts- und Prozesslücken gibt. Aus Gesamtsicht etwas Gutes, mit dem kleinen Mangel, dass inoffizielle und damit auch intransparente Strukturen entstehen können.

Passion Driven Development

Hinter dem Passion Driven Development steht der glückliche Umstand, dass ein Themenfeld für das man sich begeistern kann auch Gegenstand der eigenen Arbeit ist. Die intrinsische Motivation für Engagement und hohen Qualitätsanspruch ist damit gegeben, und das ggf. sogar in Verbindung mit Selbstlosigkeit. Dort wo das Thema wichtiger ist als das eigene Ego liegt es im Eigeninteresse auch andere zu unterstützen und ihnen zu helfen. Aus Organisationssicht eine sehr gute Variante.

Mission Driven Devolopment

Dem letzten Typ nicht unähnlich, aber mit einer entscheidenden Unterscheidung: wenn nicht nur das Vorantreiben eines bestimmten Themas ein Motivator ist sondern der Erfolg eines ganzen Unternehmens (bzw. seiner Mission) steigt die Bereitschaft auch Themen zu übernehmen und gut umzusetzen die für sich genommen nicht begeisterungsfähig wären. Aus Organisationssicht ein Ideallfall unter den Motivationstreibern.

---

Natürlich gibt es sicher noch weitere Typen von in der Produktentwicklung anzutreffenden Motivationstreibern, die wichtigsten dürften aber hier aufgeführt sein. Und selbst wenn es die eine oder andere Führungskraft schmerzen dürfte: Jahres-, Meilenstein-, Produktivitäts-, Gewinn-, Einsparungs- und ähnliche Ziele stehen hier mit gutem Grund nicht. Die sind zwar in den meisten Fällen gut und richtig, wirklich motivierend sind sie aber praktisch nie.

[Edit] Danke für den Input, es wurden noch einige Varianten ergänzt.

Nachträglich Arbeit in den Sprint aufnehmen

Bild: Unsplash / Jason Goldman - Lizenz

In der Theorie ist es ganz einfach: wenn einem Scrum Team während des Sprints die Arbeit ausgeht zieht es neue nach, und zwar die jeweils am höchsten priorisierte Aufgabe im Product Backlog. Das macht erstmal intuitiv Sinn, in der Realität kann die Situation aber deutlich vielschichtiger sein, bis zu dem Punkt an dem sich dieses scheinbar naheliegende Vorgehen als eines erweist das man gerade nicht wählen sollte. Schauen wir uns das Ganze mal näher an.

Um mit dem Naheliegendsten anzufangen: zuerst stellt sich die Frage warum es keine zu erledigende Arbeit mehr im Sprint gibt. Es ist keineswegs immer so, dass bereits alles erledigt wurde - oft ist zwar noch Arbeit da, die aber durch fehlende Zulieferungen oder ausgefallene Systeme nicht beendet werden kann. Statt neue Arbeit nachzuziehen sollte man sich in solchen Situationen zuerst fragen ob die nötigen Zulieferungen und Reparaturen im Sprint nicht auch selbst erledigt werden können.

Selbst wenn alle Aufgaben im ursprünglichen Sprint Backlog erledigt sind müssen nicht zwangsläufig neue gesucht werden. Stattdessen kann es auch sein, dass zu der bereits erledigten Arbeit sinnvolle Ergänzungen möglich sind. Refactorings des Code können durchgeführt werden, Tests können automatisiert werden, Dokumentationen können vereinheitlicht werden, etc. etc. Das jetzt schon zu tun kann verhindern, dass später "Aufräum-Sprints" nötig werden.

Und noch etwas kann man mit der bereits fertigen Arbeit machen wenn im Sprint noch Zeit übrig ist: sie den Anwendern und Stakeholdern vorführen, deren Feedback einholen und das gegebenenfalls noch im selben Sprint nutzen um die Arbeitsergebnisse noch weiter zu verbessern. Dieser Austausch kann in Scrum auch deutlich vor dem Sprint Review stattfinden, schliesslich steht nirgendwo geschrieben, dass die Neuerungen erst da gezeigt werden dürfen.

Aber unterstellen wir, dass all das nicht möglich (oder bereits erledigt) ist und noch immer Kapazität im Sprint übrig ist. Auch dann ist die oberste Aufgabe im Product Backlog nicht automatisch die Beste. Sie sollte auch im verbleibenden Sprint abschliessbar sein. Ist das nicht der Fall besteht das Risiko, dass sich im nächsten Planning die Prioritäten ändern und dass das halbfertige Ergebnis danach so lange auf Halde liegt bis es veraltet ist und die Arbeit umsonst investiert wurde.

Ein weiterer zu berücksichtigender Fall tritt ein, wenn der Backlog-Eintrag für sich genommen noch keine nutzbare Funktionalität erzeugt.¹ Es mag zwar verlockend erscheinen durch eine frühe Umsetzung "Vorarbeit" für das nächste Sprint-Ziel zu erledigen, zum einen besteht aber auch hier das Risiko, dass es im nächsten Planning zum Umpriorisierungen kommt, zum anderen führt eine solche asynchrone Fertigstellung oft zu nicht gut abgestimmten Ergebnissen und zu höheren Integrationsaufwänden.

Um es auch von der positiven Seite zu betrachten - was kann man denn guten Gewissens in einen Sprint nachziehen? Idealerweise Arbeitspakete deren Umsetzung bereits für sich genommen einen Mehrwert erzeugt und die in der noch verbleibenden Zeit des Sprints vollständig umsetzbar sind. Selbst wenn sie nicht die höchste Priorität im Backlög haben sollten stiften sie einen Mehrwert, gleichzeitig können die in den letzten Absätzen genannten Risiken vermieden werden.

Falls sie alle in der verbleibenden Zeit umsetzbar sind können auch mehrere zusammengehörende Backlog-Einträge in den Sprint gezogen werden, die sich dann durch ein "Zusatz-Sprintziel"² verbinden lassen. Gegebenenfalls ist es zu diesem Zweck auch möglich aus einem für die verbleibende Sprintdauer zu grossen Ziel einen Spike, ein Proof of Concept oder ein MVP herauszulösen, das auch allein für sich genommen von Wert ist.

Was ich auch schon erlebt habe ist, dass sich Teams die ihr Sprintziel vorzeitig erreicht haben aus dem Backlog eine "Carte Blanche" ziehen konnten, mit der sie an allem arbeiten konnten wozu sie sonst nicht gekommen sind, vom Abbau technischer Schulden über die Verbesserung der eigenen Entwicklungstools bis hin zum Erlernen neuer Programmiersprachen. Für viele war das ein zusätzlicher Anreiz um ihre Arbeit möglichst schnell und gut zu erledigen.³

Und ganz zuletzt - vielleicht muss man auch gar keine Arbeit nachziehen und kann stattdessen Überstunden abbauen. Auch das passiert in manchen Teams viel zu selten.

¹Dass in Scrum jeder Backlog-Eintrag zwingend potentiell nutzbare Funktionalität erzeugen müsste ist ein Mythos, das trifft nur auf Sprint-Ziele zu.
²Ggf. mit anderem Namen, da es ja eigentlich nur ein Sprintziel geben soll.
³Nur um es klarzustellen: natürlich sollte man auch unabhängig vom Sprint-Status an diesen Themen arbeiten können.

A long time ago, in an agility far far away ...

Es gibt einige ältere Dinge die so cool sind, dass sofort zwei Reaktionen hochkommen wenn man sie sieht: 1) "Wow, das gibt es schon so lange?" Und 2) "Oh Mann, warum wurde davon nicht viel mehr gemacht?"
Die Seite Something Agile Lean Something gehört auf jeden Fall in diese Kategorie, denn auf Ihr wurden schon 2015 eine Reihe von Begriffen aus dem agilen Kosmos mit gezeichneten Star Wars-Lego-Figuren erklärt. Leider sind insgesamt nur acht Panels zusammengekommen, die sind aber alle wirklich sehenswert. Hier ist mein Favorit, die Erklärung verschiedener Typen von MVPs:

Zum Vergrössern auf die Grafik klicken

Dieses und die anderen Panels können auf der Seite somethingagileleansomething.com in hoher Auflösung heruntergeladen werden, alle unter der Creative Commons-Lizenz CC BY-NC-ND 2.0.

Fehlt noch etwas um den Popkultur- und Methoden-Nerd vollkommen zu begeistern? Natürlich, ein Easter Egg. Bitte noch einmal alle Augen auf die oben zu sehenden "MVP-Flavors". In ihnen gibt es eine Referenz auf eines der bekanntesten MVPs der Technik-Geschichte. Noch nicht gefunden? Die Auflösung gibt es hier.

Enterprise Awareness

Bild: Wikimedia Commons / José Sáez - CC BY-SA 3.0

Es ist ein häufig zu beobachtendes Phänomen: im Rahmen einer Umstellung auf agile Arbeitsweisen lernen die beteiligten Teams, dass sie ab jetzt autonom und selbstverantwortlich sind, treffen mutig erste Entscheidungen - und kollidieren heftig mit Notwendigkeiten der sie umgebenden Organisation. Je nach Kontext folgen Klärungen oder Eskalationen, die aber in der Regel das selbe Ergebnis haben: den Teams werden die Grenzen der Selbstorganisation aufgezeigt.

An dieser Stelle ergibt sich eine spannende (und leider zu selten gestellte) Frage: wie kann es dazu kommen? Oder präziser gefragt: ist derartig handelnden Team nicht bewusst, dass es Vorgaben oder Abhängigkeiten gibt und welche das sind? Die Antwort darauf ist erstaunlich häufig Nein. Die Gründe dafür können vielfältig sein und von fehlendem Interesse bis zu einem Herrschaftswissen hortenden Manager reichen, das Ergebnis ist aber immer ähnlich - die oben erwähnte unschöne Kollision.

Zur Vermeidung dieser Kollision haben die agilen Frameworks mit der Zeit verschiedene Ansätze entwickelt. Scrum (und davon abgeleitet Nexus und LeSS) gehen etwa davon aus, dass die Gesamt-Organisation sich an den Bedürfnissen der Teams ausrichten muss, was prinzipiell richtig, in der Realität aber schwer umzusetzen ist. SAFe stützt sich auf  Top-Down Vorgaben, was das Problem auf Kosten der Agilität löst. Und Flight Levels setzen einfach voraus, dass Abhängigkeiten irgendwie bekannt werden.

Den vermutlich pragmatischsten Weg hat ausgerechnet ein Framework gewählt, das bisher noch keine nennenswerten Impulse einbringen konnte: Disciplined Agile (DA), die "agile Tochter" des Project Management Institute (PMI). DA geht davon aus, dass agile Teams die in einem grösseren Umfeld eingebunden sind "Enterprise Awareness" entwickeln müssen, also ein Bewusstsein dafür, in welche Abhängigkeiten sie eingebunden sind und wo bereits Lösungen für ihre Probleme vorhanden sind.

Da dieses Bewusstsein nicht vom Himmel fällt wird von DA empfohlen, dass die Teams in einen engen Austausch mit Personen gehen die über eine ausreichende Übersicht verfügen und darauf aufmerksam machen können wo Team-übergreifende Zusammenhänge bestehen. Spezifisch genannt werden dafür Enterprise Architekten und Portfolio Manager, aber auch andere Rollen können in Frage kommen (je nach Einzelfall dürfte das unterschiedlich sein).

Natürlich ist auch dieser Ansatz nicht ohne Risiken. Zum einen müssen die Teams überhaupt wissen, dass es diese Ansprechpartner gibt, des weiteren müssen diese auch ausreichend freie Kapazität haben um im Zweifel kurzfristig ansprechbar zu sein und zuletzt müssen sie bereit sein ihre Rolle so auszuüben, dass sie eher beratend und weniger anweisend und kontrollieren ist (was umgekehrt natürlich voraussetzt, dass die Teams bereit sind sich beraten zu lassen).

Am Ende macht aber gerade diese Unklarheit diesen Weg zu einem den man als agil bezeichnen kann. Er gibt einen Rahmen vor, überlässt den Beteiligten wie sie ihn füllen und vertraut darauf, dass sie das entsprechende Verständnis haben um es auch in einer zielführenden Art tun zu können. Und für den Fall, dass die Beteiligten noch nicht das Gefühl haben von sich aus so weit zu sein, sieht auch DA die üblichen helfenden Rollen vor, den Scrum Master und den Agile Coach.

Der 'Gesellschaftsvertrag' über konstruktives Change Management

Bild: Pixabay / Aymanejed - Lizenz

Zu den Konzepten mit denen man sich beschäftigen sollte wenn man in grossen Organisationen arbeitet gehört die Vertragstheorie. Nicht etwa deshalb weil ständig zu allem möglichen Verträge abgeschlossen werden, sondern weil derartige Abkommen an vielen Stellen zwar nur inoffiziell existieren,¹ trotzdem aber von grosser Wirkung sind. Gegenstand dieser so genannten Gesellschaftsverträge kann zum Beispiel die Selbstorganisation in Teams sein (siehe hier) aber auch ein anderer, um den es heute gehen soll: das Change Management.

Um das Thema genauer einzugrenzen: es geht hierbei nicht darum ob die Mitarbeiter sich Umstrukturierungen oder sonstigen Änerungsvorhaben grundsätzlich verweigern können, das wäre nicht zielführend. Worum es geht ist die Art der Durchführung, die von beiden Seiten (denen die Veränderungen anstreben und denen die davon betroffen sind)² sowohl konfliktlastig als auch konfliktvermeidend gestaltet werden kann. Ein konfliktvermeidender Change-Vertrag sähe so aus:

Die Seite die eine Veränderung anstrebt (z.B. eine Umstellung der Arbeitsmethodik) verpflichtet sich dazu, diese Bemühungen nicht im Geheimen zu beginnen und voranzutreiben sondern das in weitestmöglicher Offenheit und Transparenz zu tun. Diese sollte sowohl die zugrundeliegenden Motivationen umfassen als auch die dazugehörigen Massnahmen, die möglichen Folgen für alle Beteiligten (auch die unangenehmen) sowie den angestrebten Zeitplan.

Die Seite die von den Veränderungen betroffen ist verpflichtet sich im Gegenzug, diese früh sichtbar werdenden Veränderungsbemühungen nicht von Anfang an zu behindern, zu verlangsamen oder unnötig aufwändig zu machen. Wichtig dabei ist, dass das auch dann nicht geschieht wenn eine der möglichen Konsequenzen ist, dass der eigene Job tendenziell schwieriger wird. Das ist untrennbar mit dem nächsten Punkt verbunden.

Die Seite die eine Veränderung anstrebt verpflichtet sich dazu,die Sorgen und Einwände der betroffenen Seite ernst zu nehmen und Veränderungsmassnahmen nicht mit Zwang durchzudrücken wenn eine Mehrheit der Betroffenen sich dagegen ausspricht. Dass die Veränderungen in einem derartigen Fall nur abgeschwächt und vielleicht sogar in anderer Form kommen können ist ein Ausgang der von Anfang an als grundsätzlich möglich gelten muss.

Die Seite die von den Veränderungen betroffen ist verpflichtet sich im Gegenzug, die eigenen Partikularinteressen nicht über die berechtigten Gesamtinteressen der Gesamtorganisation zu stellen (z.B. nicht einen besseren Kundenservice zu verhindern um in Ruhe arbeiten zu können). Und dort wo sie die Veränderungen für unzumutbar hält verpflichtet sie sich nach Alternativen zu suchen die dem Gesamtinteresse dienen, selbst wenn dafür Anstrengungen und Umgewöhnungen nötig sind.

Wie immer in der Vertragstheorie gilt auch hier, dass der "Gesellschaftsvertrag über konstruktives Change Management" nur dann Bestand hat, wenn er von beiden Seiten durchgehend respektiert wird, auch dann wenn eine Seite durch den Bruch einen Vorteil gewinnen könnte und auch dann wenn es gerade dringend, wichtig oder weniger anstrengend wäre die jeweils andere Seite zu umgehen. Ihn zeitweise aussetzen geht nicht, es gibt ihn ganz oder gar nicht.

Wie im Fall anderer inoffizieller Gesellschaftsverträge wäre es auch in diesem eine spannende Idee daraus etwas Explizites zu machen, eben durch Ausformulieren und Aufschreiben. Sichtbar auf eine Wand geschrieben dürfte es viele Diskussionen um Change-Vorhaben zwar lebhafter gestalten, dafür aber auch deutlich zielführender machen als es zur Zeit häufig der Fall ist.

¹Mitunter sogar auf einer so impliziten Ebene, dass die Beteiligten sich der Abmachung gar nicht bewusst sind
²Die beiden Gruppen sind in der Realität nicht immer klar zu trennen, lassen sich in den meisten Veränderungsvorhaben aber identifizieren