Agilität? Haben wir probiert! Funktioniert nicht! – Teil 6

Seit Teil 5 dieser Serie sind nun wieder einige Monate ins Land gegangen. Damals habe ich damit eingeleitet, dass einige “New Work”-Utopien Realität geworden sind: Homeoffice, Kommunikation über Videokonferenzsysteme, Nutzung von digitalen Whiteboards und anderen Tools zur Online-Zusammenarbeit. Und damit ging auch einher, dass Führungskräfte ein Stück weit loslassen und darauf vertrauen mussten, dass die Mitarbeitenden ihren Job auch dann machen, wenn niemand kontrolliert. Damals schrieb ich u. a. über Führung und Orientierung als Rahmenbedingung für Autonomie und Selbstorganisation.

An dieser Stelle möchte ich auf das “Transparency Paradox” hinweisen, eines von vielen “Gesetzen” der (Zusammen-)Arbeit, die ich in den letzten Monaten zusammengetragen habe: Wenn Mitarbeitende wissen, dass ihre Vorgesetzten (dieses Wort sagt so viel aus!) sie beobachten, bremst das ihre Produktivität und Innovation. Einfach ausgedrückt: Menschen ändern ihr Verhalten, wenn sie wissen (oder ahnen), dass sie beobachtet werden. Und zwar nicht in jene Richtung, die sich die Kontrolleure durch ihre Kontrolle eigentlich erhoffen!

Doch zurück zur Artikelserie: Im ersten Artikel meiner kleinen Serie ging es vor allem um die Frage, ob Agilität überhaupt der passende Ansatz für Organisationen ist und falls ja, welcher konkrete Ansatz auf welche Situation passen könnte. Im zweiten Teil ging es vor allem um typische Probleme bei der Einführung und Umsetzung von Agilität. In der dritten Folge lag der Fokus vor allem auf den Menschen selbst. Im vierten Artikel habe ich einige gefährliche Missverständnisse thematisiert. In Teil 5 ging es um Krisen und den Umgang damit, um Führung und Orientierung und um Veränderung. Für den sechsten Artikel habe ich ein paar weitere Phänomene und Fallstricke skizziert, die ich in Veränderungsprozessen und Transformationen beobachten durfte. Spoiler: Es ist komplex, nicht einfach, einen passenden Übergang und eine gute Mischung aus Bewährtem und Neuem zu finden!

Weiterhin gilt: Auch dieses Mal werde ich weder universelle Lösungen noch Kochrezepte für erfolgreiche Agilität liefern können. Die eine oder andere aufmerksame Leserin wird vielleicht erkennen, dass sich meine Argumente teilweise sogar widersprechen. Willkommen in der Realität: Mehrdeutigkeit bzw. Ambiguität ist – ja nach Experte – eine Ausprägung oder ein Begleiter von Komplexität, auf jeden Fall: unvermeidbar. Und dennoch bin ich überzeugt, dass die geneigte Leserin mit dem einen oder anderen meiner Impulse etwas anfangen können wird.

Und bevor es losgeht noch einmal der Hinweis: Auch dieser Beitrag kann wieder Spuren von Ironie beinhalten!

Sie können einfach nicht loslassen, Teil 4: Wie sollen sich die neuen agilen Rollen entfalten, solange die alten Rollen noch im Weg herum stehen?

Es klingt ja auch zu schön um wahr zu sein: Scrum kommt mit nur drei Rollen aus! (Ja, klar – außerhalb der Scrum Teams gibt es natürlich auch noch Rollen, aber das ist hier nicht das Thema.) Nur drei Rollen? Und der Rest ist Selbstorganisation? Und das soll funktionieren?

Ja, das funktioniert oft sehr gut. Wenn man es funktionieren lässt. Wenn man die Rahmenbedingungen dafür schafft.

Und natürlich geht während der Übergangsphase auch erst einmal einiges schief. Da bleibt mal etwas liegen, weil das niemand auf dem Schirm hatte und somit nicht klar war, wer sich darum kümmert.

Und um solche “Kinderkrankheiten” zu vermeiden, kommen einige Organisationen auf die vermeintlich großartige Idee, den Übergang möglichst sanft zu gestalten. Man führt also die neuen agilen Rollen ein, lässt aber die alten Rollen noch bestehen, quasi als Sicherheitsnetz, damit nichts schief geht.

Also gibt es nun selbstorganisierende Scrum Teams mit Product Owner, Scrum Master und Entwicklern sowie Projektleiter, Delivery Manager, Systemarchitekt, Qualitätsmanager, UX/UI Designer, …

Aus meiner Sicht ist eine solche Situation ein ganz typischer Fall von “gut gemeint ist die kleine Schwester von Sch…”. Man möchte den neuen Teams helfen, sie nicht einfach ins kalte Wasser schubsen. Doch Hand aufs Herz: Wer hat mit Schwimmflügeln richtig schwimmen gelernt? Also ich persönlich habe erst dann richtig Radfahren gelernt, als meine Eltern endlich die Stützräder abmontiert hatten. Vorher musste ich mich ja gar nicht wirklich bemühen, das Gleichgewicht zu halten – ich hatte ja schließlich Stützräder! Und meine Eltern haben sich gewundert, warum ich “trotz der Stützräder” einfach nicht mit dem Rad klar komme …

Doch zurück zu alten und neuen Rollen*: Bedenken Sie die möglichen Risiken und Nebenwirkungen! Es ist wie immer komplex, das bedeutet: Es muss nicht schief gehen, aber es besteht die Gefahr! Wenn Sie sich also für die temporäre Koexistenz von alten und neuen Rollen entscheiden sollten, dann achten Sie bewusst auf mögliche unerwünschte Auswirkungen!

• Es können Rollenkonflikte entstehen: Je mehr Rollen es gibt, desto komplizierter ist es, diese Rollen voneinander abzugrenzen und die Aufgaben und Verantwortlichkeiten sinnvoll aufzuteilen.
• Achten Sie auf die Trägheit alter Gewohnheiten: Die alten Rollen sind etabliert und eingespielt, insbesondere auch im Rest der Organisation und darüber hinaus (bei Kunden und Partnern). Im Zweifel – und vor allem: wenn es mal schnell gehen muss – wende ich mich an eine Rolle, mit der ich gute Erfahrungen gemacht habe, der ich vertraue.
• Es kann ein Gegeneinander statt Miteinander aufkommen: Die alten Rollen (bzw. die Personen, die diese Rollen ausfüllen) fühlen sich bedroht und sind verunsichert, was mit ihnen passieren wird, falls es künftig nur noch die neuen Rollen geben wird. In diesem Fall werden sie nur wenig motiviert sein, die neuen Rollen zu unterstützen und sich selbst auf das Abstellgleis zu schieben. Eher werden Sie ihre eigenen Rollen festigen z. B. indem sie ihr wertvolles Erfahrungswissen für sich behalten, um sich so unabkömmlich zu machen, oder durch – unbewusste oder sogar gezielte – Sabotage der neuen Rollen.

Fragen Sie sich selbst: Denken Sie, dass Agilität und Selbstorganisation der richtige Weg für Ihre Organisation ist? Denken Sie, dass Ihre Mitarbeiter:innen das hinbekommen? Können Sie es sich leisten, dass zunächst einmal nicht alles rund läuft?

Falls ja, dann sollten Sie vielleicht mutig sein und auf den sogenannten “Volksmund” hören: Lieber ein Ende mit Schrecken als ein Schrecken ohne Ende!

Das bedeutet allerdings nicht, dass Sie die neuen Rollen von 0 auf 100 sich selbst überlassen sollten! Es gibt nicht nur schwarz und weiß, nicht nur “ins kalte Wasser schubsen” und “Schwimmflügel im Planschbecken”. Bieten Sie den neuen Rollen Orientierung und Unterstützung an, gehen Sie regelmäßig in den Austausch, in die gemeinsame Reflexion. In Teil 5 habe ich einige Hinweise dazu gegeben.

Und ebenfalls in Teil 5 habe ich davor gewarnt, über das Ziel hinaus zu schießen und die alten Rollen und deren Verdienste nicht zu wertschätzen! Auch das wäre keine gute Basis für die Zukunft der neuen Rollen …

*) Hinweis: Tatsächlich hat das nichts mit Agilität zu tun, diese Phänomene können bei jeder Veränderung, bei jeder neuen Rolle auftreten.

Sie verwechseln die neuen Rollen mit einem Sparprogramm: Product Owner werden nicht durch Ernennung zu Superhelden der Agilität!

Bleiben wir bei neuen Rollen. Im vorherigen Absatz habe ich ein (über-) vorsichtiges Verhalten skizziert: Sie lassen die alten Rollen (zunächst) einmal parallel zu den neuen Rollen laufen, damit nichts schief geht. Nun blicken wir auf ein anderes Extrem, eine (über-) optimistische Herangehensweise: Sie streichen nicht nur die alten Rollen, Sie streichen auch direkt Personal.

Ja, im aktuellen Scrum Guide (Version 2020) steht “The Product Owner is one person, not a committee”! Das bedeutet aber nicht, dass diese Person damit automatisch Superkräfte erhält, um alle Arbeit zu erledigen, für die zuvor die Projektleitung und ein fünfköpfiges Project Office zuständig war.

Klingt absurd, aber ich habe schon Product Owner erlebt, die komplett überlastet waren, weil sie genau in diese Situation hinein geschubst wurden und einfach nicht mehr wussten, wo ihnen der Kopf steht.

Auch hier gilt: Das kann funktionieren!

Unter der Annahme, dass sich Arbeit immer so weit ausdehnt, wie sie Platz bekommt (frei nach den Parkinsonschen Gesetzen), müsste Arbeit auch weniger werden, wenn sie weniger Platz bekommt, wenn es also weniger Menschen gibt, die sie tun, wenn es also künftig nur noch 1 Product Owner statt 1+5 Project Office gibt.

Anekdote: Während meines Studiums habe ich ein Praktikum bei einem selbstständigen Unternehmensberater (ein “Freund” von Roland Berger, wie er mir erzählte) gemacht, der damals oft vom Bertelsmann Vorstand gerufen wurde, um Firmen wieder profitabel zu machen. Eines Tages weihte er mich in sein Geheimnis ein: “Jede etablierte Organisation, die ein paar Jahre lang nicht verschlankt wurde, hat etwa 30% zu viel Personal. Meine Aufgabe ist es, diejenigen 30% zu identifizieren, auf die das Unternehmen verzichten kann.” Er hat mir gegenüber Parkinsons Law zwar nicht erwähnt, vielleicht kannte er es auch gar nicht, doch seine Erfahrungen aus Dutzenden solcher Projekte untermauern dieses “Gesetz”. Sein Weg (Firmen wieder profitabel machen durch Personalabbau) ist zwar nicht meiner, ich helfe lieber dabei, mit dem vorhandenen Persönlichkeiten innovativer und erfolgreicher zu werden, doch er war damit sehr erfolgreich und hat viele Firmen gerettet.

Also ist doch alles gut? Naja! Ein solches Vorgehen kann auch grandios schief gehen und es können im schlimmsten Fall auch Menschen dabei zu Schaden kommen!

Ich erwähnte schon überlastete Product Owner: Mindestens einer hat sich nach kurzer Zeit mit Burnout aus dieser neuen Rolle und der Firma verabschiedet. Vielleicht war diese schnelle und heftige Reaktion für ihn sogar langfristig gesünder als eine schleichende Überlastung über viele Jahre hinweg und chronischen Stresssyndrom. Ich bin kein Psychologe, kein Mediziner, doch wir alle tragen Verantwortung für die Folgen unserer Handlungen und im Rahmen der Fürsorgepflicht sind Arbeitgeber verpflichtet, das Leben und die Gesundheit von Arbeitnehmer:innen zu schützen.

Und selbst wenn wir gesundheitliche Aspekte außer Acht lassen: Überlastete Product Owner machen im Zweifel auch keinen so guten Job, treffen unter ständigem Druck eher schlechtere Entscheidungen und sind kaum in der Lage, gute Beziehungen zu Stakeholdern, Partnern etc. zu pflegen.

Und dann heißt es: Er (oder sie) kann das einfach nicht! Sie suchen die Schuld für das Scheitern also bei der einzelnen Person, die diese Rolle bzw. Bürde nicht gestemmt bekommen hat. Also suchen Sie einen kompetenteren, stressresistenteren Ersatz.

Oder es heißt: Agilität funktioniert (bei uns) nicht! Sie suchen die Schuld für das Scheitern also im gewählten Ansatz bzw. Modell. Also versuchen Sie einen anderen Ansatz oder kehren zurück zur alten Organisationsform.

Beides sind mögliche Ursachen. Es gibt aber noch eine dritte, die gerne verdrängt wird: Die Umsetzung im eigenen Kontext/System hat so einfach nicht funktioniert.

Vielleicht wäre es viel besser gelaufen, wenn Sie dabei unterstützt oder zumindest die Zeit dafür eingeräumt hätten, die bisherigen Aufgaben von Projektleitung und Project Office zu analysieren: Was übernimmt die Rolle Product Owner, was übernimmt die Rolle Scrum Master, was wird im Rest des Scrum Teams aufgeteilt? Was kann vielleicht sogar außerhalb des Scrum Teams besser übernommen werden? Und ganz wichtig: Was kann künftig wegfallen?

Wenn sie die Zeit und Aufmerksamkeit dafür haben, kann ein Scrum Team auch ganz bewusst kleine Experimente durchführen, um empirisch herauszufinden, welche Arbeit wirklich notwendig und wertstiftend ist. Wenn Zeit und Aufmerksamkeit dafür fehlen, bleibt einem ja gar nichts anderes übrig, als zu versuchen, alles so gut es geht zu erledigen.

Sie kennen sicher diese Metapher: Zwei Holzfäller sind völlig außer Atem vom Baumfällen. Kommt ein Wanderer vorbei und fragt: “Merkt Ihr nicht, dass Eure Äxte stumpf sind? Warum schärft Ihr sie nicht?” Antworten die Holzfäller: “Dafür haben wir keine Zeit, wir müssen Bäume fällen!”

Ein kleines Beispiel, das ich selbst begleiten durfte:

Ein Scrum Team in einem Konzern war genervt davon, in drei verschiedene Berichtswege und IT Systeme den Projektstatus melden zu müssen. Das war Thema in einer Sprint Retrospektive. Bei einem dieser Systeme war auch nicht ersichtlich, was mit den Daten überhaupt passiert, die sie wöchentlich dort eintrugen. Also schrieben sie die nächsten drei Wochen Lorem Ipsum Fülltexte in die Texteingabefelder. Und siehe da: Es kam keinerlei Reaktion. Offensichtlich schaute sich niemand diese Informationen an, die jedes Projekt wöchentlich dort eintragen musste. Auf Basis dieser empirischen Erkenntnis war es leicht, diesen Berichtsweg generell zu eliminieren. Hätte das Scrum Team nicht die Zeit und Aufmerksamkeit zum Axtschärfen gehabt, hätten sie (wie viele andere Teams in dem Unternehmen) diesen Berichtsweg zähneknirschend und genervt Woche für Woche bedient.

Fazit: Wenn Sie die Veränderung als Chance nutzen wollen, um unnötige Arbeit zu reduzieren, dann sollten Sie das auch ermöglichen! Auch das Identifizieren und Eliminieren von nicht wertschöpfender Arbeit ist erst einmal Arbeit! Und diese Arbeit braucht Zeit und Aufmerksamkeit. Betrachten Sie das als Investition, die Ihnen künftig eine gute Rendite (freigewordene Kapazität für mehr wertschöpfende Arbeit) einbringen wird. Vielleicht werfen Sie dazu auch noch einmal einen Blick in den Abschnitt zur Transformation?

Sie können einfach nicht loslassen, Teil 5: Wasch mich, aber mach mich nicht nass!

Das mit dem Loslassen ist ein vielfältiges Thema. In den ersten vier Teilen ging es um generell um die Trägheit alter Gewohnheiten, um Kennzahlen, um Tools und (etwas weiter oben) um Rollen.

Es gibt natürlich noch viele weitere Möglichkeiten, um “dem Neuen” das Leben schwer zu machen:

Schauen Sie sich Ihre etablierten Prozesse an: Sie fordern Projektanträge mit komplizierten Wirtschaftlichkeitsberechnungen natürlich auch von Projekten, die agil vorgehen wollen. Gleiche Pflichten für alle! Prinzipiell ein gutes Prinzip! Es macht nur dann überhaupt keinen Sinn, wenn das Projekt gerade deshalb ein agiles Vorgehen gewählt hat, weil es sich um ein ungewisses/komplexes Vorhaben handelt. Weil eben noch nicht klar ist, was das Ergebnis im Detail sein und was es bringen wird. Weil noch nicht klar ist, wie lange man daran arbeiten und was man dazu brauchen wird. In solchen Fällen ist ein Projektantrag mit Business Case pure Verschwendung von Zeit und Energie! Und nervend!

Und Hand aufs Herz: Wer ein Projekt genehmigt haben möchte, rechnet es so, dass es genehmigt wird, ob agil oder nicht. Denn wie oft kommt es vor, dass die initialen Berechnungen noch einmal angeschaut werden? Und selbst wenn: Dann haben sich seitdem wichtige Rahmenbedingungen verändert, sodass einige Annahmen nicht mehr stimmten! Wozu also den Aufwand überhaupt betreiben?

Was also stattdessen tun? Vielleicht ist ein offener Kickoff eine Möglichkeit? Alle, die am Vorhaben interessiert sind, können Fragen stellen, auf Gefahren hinweisen, Einwände einbringen, Alternativen vorschlagen etc. Und vielleicht kann die Entscheidung über Projekte auch viel dezentralisierter erfolgen als bisher? Und viel öfter und in kleineren Schritten? Der Gefahr, dass das Rad dann unbemerkt mehrfach erfunden wird oder Liebhaberprojekte aus dem Boden sprießen, kann mit maximaler Transparenz (u. a. offene Sprint Reviews) begegnet werden.

Oder schauen Sie sich Ihre etablierten Gremien an: Sie haben zwar ermächtigte Product Owner, die Entscheidungen treffen dürfen, und regelmäßige Sprint Reviews, die für alle Stakeholder offen sind. Doch die schöne Tradition des Lenkungsausschusses möchten Sie lieber nicht aufgeben? Es kann doch nicht schaden, eine weitere Instanz zu haben, die ja auch nur im Ausnahmefall Entscheidungen treffen muss.

Das kann funktionieren. Vielleicht läuft alles rund und alle paar Wochen sitzt man im Lenkungskreis zusammen und feiert das erfolgreiche, weil agile und selbstorganisierte Projekt. Und sich selbst.

Aber bitte achten Sie auch hier auf Risiken und Nebenwirkungen: Kommen die Stakeholder regelmäßig zum Sprint Review oder vertrauen sie darauf, im Steuerungskreis vom Product Owner eine Zusammenfassung (Fokus auf einen Statusbericht mit Zahlen, Daten, Fakten statt auf das nutzbare Produkt als Ergebnis) zu bekommen? Bekommt das komplette Scrum Team regelmäßig Feedback zum Sprint Ergebnis? Werden Probleme/Hindernisse früh, offen und lösungsorientiert besprochen? Oder kommt die Vertreterin des Projektes als Bittstellerin oder gar als Angeklagte, die sich erklären muss, weil bspw. ein Budgettopf früher als geplant leer geworden ist? Wieviel Zeit investiert das Scrum Team für die Vorbereitung einer Vorstellung (Statusbericht, Folienpräsentation, …) des Projektes in einem Gremium zusätzlich?

Was wäre die Alternative? Vielleicht können wichtige Stakeholder wirklich nicht an jedem Sprint Review teilnehmen – vielleicht ist das dann aber auch eine gute Gelegenheit, um Verantwortung zu teilen, zu delegieren? Vielleicht braucht es auch andere Formate – in einem großen deutschen Automobilkonzern habe ich das sogenannte Puls-Meeting kennengelernt: Jede Woche treffen sich Vertreter aller Projekte eines Bereiches mit entscheidungsberechtigten Vertreter:innen aus der Linie (z. B. Einkauf, Personal, …). Jedes Projekt hat ein bis zwei Minuten Zeit, um allen Anwesenden aufzuzeigen, wofür es welche Unterstützung aus der Linie braucht. Danach sprechen Projekte und Linie kurz miteinander, treffen Entscheidungen oder vereinbaren nächste Schritte. Der gravierende Unterschied ist die Haltung, mit der alle Beteiligten in dieses Meeting gehen: Die Linie kommt, um den Projekten zu helfen. Die Projekte kommen, weil sie so schnell und direkt Hilfe bekommen, wenn sie Themen nicht selbst lösen können. (Mehr dazu im Buch #PM2025.)

Traditionelle Projektstatusberichte hatte im im Abschnitt zuvor schon erwähnt. Aber schauen Sie sich einmal in Ruhe um, sicher finden Sie noch weitere Traditionen, die es allem Neuen nicht leicht machen, sich und die eigene Wirkung zu entfalten.

Ich plädiere nicht dafür, alles Etablierte radikal zu stoppen und von heute auf morgen alles neu zu machen, das ist gefährlich. Stellen Sie sich einmal vor, Sie gehen “agil” vor: Sie nehmen Sie sich regelmäßig Zeit zur Reflexion und erlauben sich, alles jederzeit kritisch in Frage zu stellen. Und dann priorisieren Sie und nehmen Sie sich einen Aspekt nach dem anderen vor. Und Sie machen das schrittweise: Sie machen kleine, zeitlich begrenzte Experimente (z. B. die nächsten zwei Lenkungsausschusstermine streichen und stattdessen alle zum Sprint Review einladen, danach entscheiden Sie gemeinsam, wie es weitergehen soll) und Sie achten dabei aufmerksam auf etwaige Risiken und Nebenwirkungen.

Sie können einfach nicht loslassen, Teil 6: Sie fordern von den crossfunktionale Teams Zusammenarbeit ohne Silodenken und Selbstorganisation, behalten die funktionale Organisationsstruktur aber bei …

Ich verstehe es ja. Der Scrum Guide beschreibt – vereinfacht gesagt –, wie ein crossfunktionales Team Produkte entwickelt. Der Scrum Guide beschreibt nicht – jedenfalls nicht konkret –, was das für den Rest der Organisation und vice versa bedeutet. Also fangen Sie auf der Ebene der Produkt- bzw. Projekt-Teams an.

Und das funktioniert oft auch erstaunlich gut: Stabile Teams, die eine gemeinsame Vision/Mission verfolgen, sind vielleicht sogar der(!) große Hebel, wie der wunderbare Dr. Eberhard Huber schon 2011 beim ersten PM Camp in Dornbirn in der Session “Des Agilen Pudels Kern” herausstellte: Nach Auswertung von über 300 IT-Projekten kam er zu der Erkenntnis, dass der statistisch signifikanteste Faktor für den Projekterfolg die Entwicklungsphase des Teams darstellt. Eingespielte Teams sind signifikant erfolgreicher bei der Umsetzung ihrer Projekte als Teams, die (noch) nicht so aufeinander eingestimmt sind.

Wenn also crossfunktionale Teams erfolgreich funktionieren, ohne dass sich im Rest der Organisation etwas ändern muss, dann ist doch alles fein, oder?

Wenn das so ist: klar! Jedoch gibt es auch hier Risiken und Nebenwirkungen, ich würde sogar sagen: Sollbruchstellen!

Szenario 1: Sie nennen es “Team” und es ist auch aus mehreren Abteilungen interdisziplinär zusammengesetzt und sie verwenden auch das eine oder andere agile Ritual. Doch die Teammitglieder sind parallel noch in einigen anderen Teams bzw. Projekten tätig. Und die Arbeit passiert auch nur in begrenztem Ausmaß im Team selbst – wie denn auch bei so vielen Projekten gleichzeitig. Das Team koordiniert die Arbeit, die dann von den Teammitgliedern in ihre Linienorganisation mitgenommen und dort erledigt wird. Dass in einem solchen Setting überhaupt eine Teamidentität entstehen kann, finde ich immer wieder faszinierend! Es sollte aber niemanden verwundern, dass in einem solchen Fall im Zweifel allen Teammitgliedern die eigene Linienorganisation und deren Interessen viel näher ist, also das – vermeintliche – Team.

Szenario 2: Ab jetzt gehen wir davon aus, dass es sich um ein “echtes Team” handelt, also um eine Gruppe von Menschen, die (idealerweise) mit annähernd 100% ihrer Zeit in diesem Team arbeiten. Nun kommt es im Projekt (oder im Verlaufe der Produktentwicklung) zu Problemen, bspw. zu Terminproblemen, zu Budgetproblemen, zu technischen Problemen, Qualitätsproblemen o. ä. In einem solchen Fall kann die funktionale Organisation durchaus agil reagieren, indem bspw. die Linienverantwortlichen dem Team ihre Unterstützung anbieten, z. B. durch beschleunigte Einkaufsverfahren, schnelle Nachbesetzung einer Stelle etc. (Weiter oben hatte ich das “Pulse-Meeting” als einen dazu passenden Ansatz skizziert.)

In der Realität beobachte ich jedoch zu oft, dass ein solches Problem in mehreren beteiligten Funktionsbereichen des Unternehmens parallel zu lokalen Eskalationen führt. Jede Linie versucht erst einmal selbst, möglichst unbeschadet aus dieser Situation heraus zu kommen und nimmt dazu Einfluss auf das Verhalten der eigenen Vertreter:innen im Team. In einer solchen Situation ist es quasi nur gespaltenen Persönlichkeiten möglich, sowohl der eigenen Abteilung als auch dem Team treu zu bleiben.

Szenario 3: Im Team kommt es zu Konflikten. Ein sehr reifes Team wird die meisten Konflikte intern klären, u. a. dafür sind regelmäßige Retrospektiven und die Rolle Scrum Master o. ä. gedacht. Manchmal kommt es aber vor, dass Teammitglieder ihren Vorgesetzten von dem Konflikt berichten. Vorgesetzte mit einer agilen Haltung nehmen den Konflikt ernst und unterstützen ihre Mitarbeitenden dabei, den Konflikt selbst zu lösen. Manchmal kommt es aber vor, dass Vorgesetzte ihre traditionelle Rolle spielen und den Konflikt per Anweisung selbst aus dem Weg räumen. Das fördert Selbstorganisation, die Identität als und die Motivation im Team immens! Nicht.

Etwas ähnliches durfte ich letztens live beobachten: Im Team kam es zu einem Konflikt und nach einem anstrengenden Prozess hatte man gemeinsam eine Lösung gefunden. Nun war der Konflikt zwischendurch nach außen gedrungen. Die Vorgesetzten wollten helfen, haben sich untereinander abgestimmt und eine Lösung gefunden, die sie dann dem Team präsentierten, ohne die Lösung des Teams zu kennen. In der Tat waren beide Lösungen mehr oder weniger identisch. Doch die Motivation und das Commitment im Team sackte buchstäblich in sich zusammen.

Szenario 4: Und selbst wenn im Team alles glatt läuft, besteht die Gefahr, dass die Unruhe von außen kommt. Es braucht nur geringfügige Konflikte in den Zielen der Abteilungen der Teammitglieder, um das Verhalten der Teammitglieder zu beeinflussen. Oder eine:r der Linienvorgesetzten möchte die eigene Mannschaft künftig öfter sehen und lädt die eigenen Leute zu Meetings ein, die nicht immer perfekt zum Arbeitsrhythmus des Teams passen.

Nein, Sie müssen nicht gleich die komplette Organisationsstruktur Ihres Unternehmens von heute auf morgen über den Haufen werfen. Aber es schadet sicherlich nicht, mit den Führungskräften über Agilität zu sprechen und wofür das gut sein soll und wie sie sich verhalten können, um agile Teams in ihrer Selbstorganisation zu unterstützen, zumindest aber nicht zu stören. Sie können die Position der Scrum Master oder Agile Coaches stärken und ihnen die Möglichkeit einräumen, ihre Teams vor dem Einfluss der Linie zu schützen. Und Sie können regelmäßig mit allen Beteiligten reflektieren, was gute Beispiele sind und wo es vielleicht noch nicht so gut lief, um gemeinsam miteinander zu lernen.

Ausblick

Ich hoffe, Sie können aus den hier geschilderten Phänomenen und Fallstricken im Wandel von Bewährtem zu Neuem den einen oder anderen Impuls für Ihre Realität entnehmen.

Ich habe schon oft gedacht und implizit angekündigt, dass diese Serie alsbald ein Ende finden könnte. Doch sobald ich etwas schreibe, fallen mir weitere Aspekte ein, die ich auch noch beschreiben möchte. Mein Backlog wird derzeit also eher größer als kleiner. Und wahrscheinlich wird es auch niemandem wirklich weiterhelfen, jetzt schon zu wissen, wann der letzte Teil dieser Serie erscheinen wird. Also werde ich künftig keine Energie mehr mit Schätzungen und Prognosen verschwenden, sondern einfach so lange weiter schreiben, bis mir nichts mehr einfällt (oder es niemand mehr lesen möchte). In diesem Sinne: Bleiben Sie gespannt, bleiben Sie neugierig, bleiben Sie gesund!

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Dies ist ein Best of Blog 2022 Beitrag. Hier können Sie sich die besten Beiträge aus 2022 herunterladen.

Und hier finden Sie weitere Teile der Beitragsserie Agilität? Haben wir probiert! Funktioniert nicht!

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.