24. Juli 2019 

 

"Viele sind hartnäckig in Bezug auf den einmal eingeschlagenen Weg, weniger in Bezug auf das Ziel."

Friedrich Nietzsche (1844-1900)

 

Von den Schwierigkeiten Scrum zu leben

 

Derzeit sind viele Organisationen dabei, agile Methoden auch außerhalb der klassischen Softwareentwicklung einzuführen. Dabei sind viele agile Transformationen nicht so erfolgreich, wie sich die Unternehmen das wünschen würden. Dennoch ist der Hype ungebrochen. Erfolgsgeschichten der Digitalisierung, wie Facebook, Salesforce, Google, Airbnb und Uber, die Hand in Hand mit agilen Methoden gehen, regen zur Nachahmung an. Aus der IT kamen Geschäftsmodelle, die viele traditionelle Branchen erschüttert haben. Airbnb hat mit einer Applikation Hotelketten verunsichert, Uber die Taxibranche und die Anwendungen von Google sind so breit aufgestellt, dass viele Branchen davon direkt oder indirekt tangiert sind. Diese neuen Geschäftsmodelle basieren auf digitalen Applikationen und sozialen Netzwerken. Es gibt viele Studien, die traditionelle und agile Vorgehensweisen verglichen haben und die Überlegenheit der agilen Vorgehensweise belegen.[1]

 

Agile Projektmanagementmethoden sind schlank. So kann Scrum in seinen Grundzügen mit wenigen Worten erklärt werden. Der Scrum Guide, die Bibel des Scrums, umfasst mit Deckblatt, Inhaltsangabe und Danksagungen gerade mal 17 Seiten. Trotz der Einfachheit der Methode, stellt die Einführung von Agilität die Unternehmen vor große Herausforderungen.

 

Eine erfolgreiche Implementierung von Scrum setzt voraus, dass Teams sich selbstorganisieren und ihre Produkte regelmäßig in kurzen Abständen an Kunden ausliefern und deren Feedback berücksichtigen. Selbstorganisation ermöglicht, dass Mitarbeiter ihre jeweiligen Stärken optimal einbringen können. Die Produktivität des Teams wird nicht durch Steuerung von außen bzw. oben behindert. Micromanagement beschränkt die Produktivität des Teams und führt bei den Führungskräften zu Überlastung. Die Manager stellen meist den limitierenden Faktor bei der kleinteiligen Überwachung da. Die Leistung des Teams hängt von ihrer Verfügbarkeit und Fähigkeit ab, die Mitarbeiter entsprechend einzusetzen und zu überwachen. Die Aufgabensteuerung ist besser auf den breiten Schultern eines vielköpfigen Teams verteilt. Neben der Selbstorganisation ist ein wichtiger Erfolgsfaktor von Scrum die häufige Rückkoppelung mit dem Kunden. Die kurzen Feedbackzyklen gewährleisten, dass die Produkte Wert für den Kunden haben.

 

Die Einführung von Selbstorganisation und häufigen Rückkoppelungsschleifen ist herausfordern, da man zentrale Prozesse, Strukturen und Werte von Organisationen verändert. Wir wollen im Folgenden die Herausforderungen im Einzelnen betrachten. Bevor man eine agile Transformation einleitet, sollte man mögliche Probleme antizipieren. Bei dieser Aufstellung habe ich nicht den Anspruch, die Probleme vollständig aufzulisten. Die beschriebenen Probleme bedingen sich wechselseitig, die Auflistung ist damit in gewisser Weise künstlich und dient nur zur leichteren Lesbarkeit. Auch sind die Punkte nicht nach Schwere geordnet und weisen eine mehr oder weniger willkürliche Anordnung auf.

 

Motivation der Mitarbeiter

 

Mitarbeiter haben häufig Vorbehalte gegen Änderungen ihrer Organisation. Dahinter können eine Reihe unterschiedlichster Befürchtungen stehen, die teilweise berechtigt, teilweise unberechtigt sein können. Mitarbeiter fürchten, sie könnten erarbeitete Vorzüge verlieren und sich neue Probleme einhandeln. Aufgaben könnten sie erwarten, denen sie sich nicht gewachsen fühlen. Neues Wissen wird ihnen abverlangt und sie fühlen sich überfordert.

 

Eventuell betrachten die Mitarbeiter die Veränderungen mit Misstrauen, da sie dahinter Umstrukturierungen vermuten, deren Notwendigkeit sie nicht erkennen können. Wenn sich auch Teamstrukturen verändern, wird es noch schwieriger die Akzeptanz der Mitarbeiter zu gewinnen. Mitarbeiter können lieb gewonnene Kollegen verlieren und sich in einem neuen Team wiederfinden, an das sie sich erst gewöhnen müssen. Mitarbeiter, die befürchten müssen, einmal gewonnene Privilegien zu verlieren, sind kaum für den Wandel zu gewinnen.

 

Die Akzeptanz agiler Rollenmodelle wird häufig auch dadurch erschwert, dass im agilen Kontext kein Karrieremodell erkennbar ist. Um die Rollen langfristig attraktiv zu gestalten, müssen Organisationen ein fachliches Karrieremodell entwickeln, ohne sich dabei klassischer Hierarchien zu bedienen.

 

Bei Non-Software Teams ist die Unsicherheit, dem sich die Mitarbeiter ausgesetzt sehen, ungleich größer. Während im Softwarebereich viele Firmen Agilität erfolgreich eingeführt haben und als Modell dienen können, ist im Non-Softwarebereich unklar, wie eine erfolgreiche Implementierung aussehen könnte. Es muss jeweils erarbeitet werden, wie sich Scrum von der Softwareentwicklung auf andere Bereiche, wie Marketing, Sales oder Personalmanagement, übertragen lässt. Man begibt sich auf eine Reise mit ungewissen Ausgang, was sich auf die Motivation der einzelnen Mitarbeiter nicht unbedingt förderlich auswirkt.

 

Agile Transformation fordert den einzelnen Mitarbeitern viel ab, da Arbeitsweise, Rollen­ver­ständnis und Teamzusammensetzung verändert werden.

 

Umgang mit der ‚neuen‘ Offenheit

 

Selbstorganisation setzt auf Offenheit. Das Team definiert, wie es die an sie gestellten Anforderungen umsetzen will. Dabei bringt sich jedes Teammitglied ein. Es gibt keinen Manager, der Aufgaben definiert, zuteilt und überwacht. Vielmehr definiert das Team die Aufgaben selbst und achtet darauf, dass sie in der richtigen Reihenfolge, Qualität und Quantität erledigt werden. Dazu muss die Kommunikation im Team stimmen. Die einzelnen Teammitglieder müssen bereit sein, sich offen über ihre Tätigkeiten auszutauschen. Jeder muss wissen, woran die anderen jeweils arbeiten, wo sie Probleme haben und was sie bereits erledigt haben. Das gesamte Team muss Überblick über den Status-Quo des Projekts haben, der bis dato dem kontrollierenden Manager vorbehalten war. Um die Tätigkeiten transparent zu machen, nutzen Scrum-Teams Task-Boards. Innerhalb einer agilen Organisation sind diese Boards für jeden Mitarbeiter nutzbar. In IT-Projekten ist es darüber hinaus üblich, auch Arbeitsergebnisse, wie Softwarecode, Architekturen und Modelle für alle Mitarbeiter der Organisation zur Verfügung zu stellen.


Diese Offenheit ist in unseren traditionellen Teamstrukturen nicht üblich. Die Mitarbeiter geben erstmal ungern ihren Kollegen preis, woran sie täglich arbeiten, wo ihre Probleme liegen und was sie gestern erledigt haben. Kollegen können in der Regel ziemlich genau einschätzen, wie schwierig und aufwändig die jeweiligen Aufgaben ihrer Teamkollegen sind. Außerdem gibt es unausgesprochenes Gerangel um Aufgaben. Offen über die Aufgaben innerhalb eines Teams zu sprechen, ist daher erstmal keine Selbstverständlichkeit und muss geübt werden. Dinge, die bislang unter den Teppich gekehrt wurden, werden für alle transparent: Schnell wird am Aufgabenboard sichtbar, dass Mitarbeiter für gleiche oder ähnliche Aufgaben unterschiedlich lange brauchen. Der Umgang mit unbeliebten Themen wird offengelegt. Man erkennt, dass immer dieselben Mitarbeiter lästige Aufgaben erledigen und andere sich die ‘Rosinen’ herauspicken.

 

Diese Offenheit kann ein Non-Software Team vor große Probleme stellen. Wenn das Bonussystem Einzelleistungen honoriert, wie das beim Vertrieb üblich ist, kann man nicht erwarten, dass Mitarbeiter sich offen austauschen. Sie würden dadurch ihre Bonuszahlungen gefährden. Hier sind zunächst die Bonussysteme anzupassen und Teamleistungen zu honorieren. Dass aber bereits die Einführung eines neuen Bonussystems auf erheblichen Widerstand stoßen kann, versteht sich von selbst.

 

Schwierigkeiten mit dem agilen Rollenverständnis

 

Das agile Rollenverständnis ist aus vielerlei Gründen in Organisationen schwer zu leben. Das Rollengefüge ist schlank und es sind klare Verantwortlichkeiten aber keine Hierarchien definiert. Natürlich gibt es in agilen Organisationen auch Führung, deren Selbstverständnis weicht aber von üblichen Vorstellungen ab. Agile Führungskräfte überlassen Entscheidungen über das Produkt dem Product Owner und Entscheidungen, die die Umsetzung betreffen, dem Team.

 

In einer agilen Organisation hat der Product Owner Produktverantwortung mit entsprechenden Befugnissen inklusive der Budgetverantwortung. Er kann alle Entscheidungen treffen, die ‘sein’ Produkt betreffen. Damit wird gewährleistet, dass Entscheidungen schnell fallen und das Team handlungsfähig bleibt. In der Praxis sind für einzelne Produkte meist eine Gruppe hochrangiger Manager verantwortlich. Es ist nicht realistisch, dass sie ihre Verantwortung einem einzelnen agilen Product Owner übertragen. Vielmehr wird der Product Owner die Manager bei Produktentscheidungen abholen müssen. Damit werden Entscheidungen verzögert und plötzliche Richtungswechsel der Produktstrategie sind vorprogrammiert. [2] Hängen Produktentscheidungen von einem Gremium ab, leidet die Performance (bei Scrum spricht man auch von Velocity) des Teams, das auf Entscheidungen warten muss.

 

Auch die präzise Trennung der Verantwortlichkeiten zwischen Product Owner und Team fällt schwer. In gewachsenen Strukturen werden Produkt-Entscheidungen auch gerne mal vom Umsetzungsteam getroffen. Andererseits haben viele Product Owner tiefes technisches Verständnis und treffen durch ihre Vorgaben Umsetzungsentscheidungen.

 

Die Rolle des Scrum-Masters wird ebenfalls häufig missverstanden und als klassische Führungsrolle interpretiert. Der Scrum-Master sollte die agile Transition begleiten und dafür Sorge tragen, dass die Prinzipien und Werte von Scrum gelebt werden. Häufig nimmt er aber eine Führungsrolle ein und organisiert die Arbeit des Teams.

 

In vielen Organisationen gibt es Projektmanager, deren Aufgaben und Verantwortlich­keiten sich mit dem agilen Rollenverständnis überschneiden. So trägt ein klassischer Projektleiter häufig Budget- und Zeitverantwortung (Aufgabe des Product Owners), bestimmt die Arbeitsweise des Teams (Aufgabe des Umsetzungsteam) und sorgt für reibungslose Kommunikation (Scrum Master). Daher ist es nicht unproblematisch Projektmanager in ein Scrum Team mit einem neuen Rollenverständnis zu integrieren oder ihre Rolle neu zu definieren.

 

Sich an die Rollendefinition zu halten, verlangt von den Mitarbeitern Umdenken und Disziplin. Wir alle wissen selbst, wie schwer Verhaltensänderungen im persönlichen Bereich sind. Viel schwieriger ist es aber, wenn ein eingespieltes soziales System ein neues Rollenverständnis leben will. [3]

 

Bestimmung des Produkts und des Teams

 

In der Softwareentwicklung ist die Produktdefinition einfach und klar. In regelmäßigen Abständen wird ein Release ausgeliefert. Ist das Produkt klar umrissen, lässt sich relativ einfach ein Cross-funktionales Team zusammenstellen. Ganz anders sieht das im Non-Software Bereich aus. Hier ist zunächst unklar, was von dem, was täglich geleistet wird, als Produkt betrachtet werden kann. Ist aber schon die Produktdefinition unklar, wie soll dann ein Team zusammengestellt werden?

 

Aber auch, wenn relativ klar ist, wie sich das Team zusammensetzen sollte, können weitere Probleme auftreten. Teams sind klassisch nach Bereichen zusammengestellt, wie Marketing, Sales und Entwicklung. Scrum-Teams benötigen aber Mitarbeiter mit unterschiedlichen Fähigkeiten und damit aus unterschiedlichen Bereichen. Das Zusammenstellen eines Teams mit Mitarbeitern verschiedener Bereiche kann sehr aufwändig und schwierig sein, da es einen Eingriff in die Organisationsstruktur darstellt.

 

Ausrichtung am Kundenwert

 

Agile Teams sollen in möglichst kurzen Zyklen Wert für ihre Kunden schaffen. So offensichtlich dies auf den ersten Blick erscheint, so selten trifft man die Fokussierung auf den Kundenwert in größeren Organisationen tatsächlich an. Teams konzentrieren sich häufig darauf, möglichst viel zu leisten. Ob ihre Arbeit für den Kunden von Wert ist, können sie häufig gar nicht beurteilen. Jeder Mitarbeiter will Sinn machen, um seinen Arbeitsplatz zu sichern. Wenn der Mitarbeiter keinen Kontakt zum Kunden hat, versucht er, im Rahmen seines Einflussbereichs Wert zu schaffen. In diesem Szenario kann er nur für die Menschen Wert schaffen, mit denen er Kontakt hat, den sogenannten ‘internen Kunden’.

 

Ob die Leistungen an internen Kunden, im Resultat auch zu einer empfundenen Wertsteigerung beim Endkunden führt, ist nicht einfach zu beantworten. Schon die Formulierung ‘Endkunde’ ist seltsam, als wenn es neben dem eigentlichen Kunden noch weitere Kunden gäbe. Der interne Kunde ist ein Konstrukt. Der agile Fokus ist eindeutig: Wert kann nur vom Kunden beurteilt werden und dazu muss ihm das Produktinkrement möglichst häufig ausgeliefert werden, um aus seinem Feedback lernen zu können.

 

Diese Forderung macht agile Transition in großen Unternehmen zu einer Herausforderung. Es hat sich bei Scrum-Teams eingebürgert als Kunden den Anforderer, also den internen Kunden zu betrachten. Die große Gefahr an dieser Vorgehensweise ist, dass das System zwar effizienter, aber nicht effektiver wird oder anders ausgedrückt, man leistet zwar mehr, aber nicht unbedingt mehr vom Richtigen. Diese Mehrleistung könnte der Organisation sogar schaden, wenn der Kundennutzen kaum steigt, aber die Organisation beschäftigt ist und dabei vermehrt Ressourcen verbraucht. [4]

 

Langfristige Budgetplanung

 

Budgetplanungen werden in Unternehmen in der Regel einmal jährlich frei vergeben und erfordern langfristige Zeitplanung. In agilen Teams ist langfristige und verbindliche Kosten- und Zeitplanung nicht vorgesehen. Zur langfristigen Planung dienen in agilen Teams Produktvision und Roadmap. Sie geben dem Team die Richtung vor und bestimmten die Produktstrategie. Als lebendige Konstrukte werden sie im Rahmen der Produktentwicklung auf Basis von Kundenfeedback und Erfahrungen angepasst und präzisiert.

 

Dass die langfristige Kosten- und Zeitplanung auch bei nicht agil durchgeführten Projekten nicht funktioniert, ist ein offenes Geheimnis. Dennoch liefern traditionell aufgestellte Teams bereitwillig Zahlen für die langfristige Planung. In agilen Methoden ist es aber per Definition nicht vorgesehen, langfristig stabile Pläne zu erstellen. Agilisten weigern sich, langfristig verbindliche Zahlen zu liefern und für deren Schätzung und Erhebung Zeit zu investieren. Sie gehen davon aus, dass diese Zahlen und Pläne nur falsch sein können und es nicht sinnvoll ist, dafür Zeit zu investieren. Der Product Owner muss die widersprüchlichen Interessenlagen der langfristigen Budgetplanung und der agilen Vorgehensweise bedienen.

 

Formulierung der Produktvision

 

Das Erstellen einer Produktvision erfordert visionäre Kraft und Mut. Häufig sind Produktvisionen unzureichend und es fehlt ihnen, die visionäre Kraft zur Ausrichtung der Mitarbeiter.

 

Dies wird im agilen Kontext sehr schmerzlich bewusst. Fehlt langfristige Planung ist die Existenz einer Produktvision zur Richtungsbestimmung ungleich bedeutsamer. Sie ermöglicht es, den Nutzen eines Produktes über die prognostizierte Lebensdauer zu bewerten und Investitionsentscheidungen zu tätigen. Über den Horizont des Sprints sind Kosten und Nutzen vor dem Hintergrund der Produktvision und einer langfristigen Roadmap zu bestimmen. Nur so kann strategische Produkt-entwicklung erfolgreich vorangetrieben werden.

 

Rahmenbedingungen für selbstorganisiertes Arbeiten

 

Agilität setzt gute Rahmenbedingungen voraus, die häufig erstmal nicht gegeben sind. Zum einen verstehe ich darunter gut ausgestattete Räumlichkeiten. Ein Team, das sich effektiv selbst organisieren soll, sollte zusammensitzen und die nötigen Tools haben. Ein verstreut sitzendes Team ist um mindestens 40% weniger produktiv als ein Team, das in einem Projektbüro sitzt. Dieser Faktor tritt übrigens bereits bei wenigen Metern Entfernung zum nächsten Büro auf.[5]

 

Aber auch die Ausstattung ist wichtig. Diskussionen sind fruchtbarer, wenn man sich vor einem Whiteboard treffen und Ideen skizzieren kann. Teammeetings erfordern Moderationskoffer, Flipcharts, Post-its etc. Mitarbeiter müssen in der Lage sein, sich ihr Arbeitsumfeld selbst zu gestalten, um effizient arbeiten zu können. Einige Mitarbeiter benötigen, um konzentriert arbeiten zu können, die Möglichkeiten sich abzuschirmen, andere Raum, um sich spontan austauschen zu können. Wände oder Fenster sollten zur Dokumentation langfristiger Veränderungen und Pläne nutzbar sein. Räume sind für die Produktivität und das Wohlbefinden der Mitarbeiter wichtig. Die Arbeitsflächen agiler Teams sind lebendig und erzeugen Wohlbefinden. Allerdings ist die agile Gestaltung der Räume in vielen Organisationen kein Selbstverständnis und muss erst ‘erkämpft’ werden. [6] 

 

Ein leistungsfähiges agiles Team stellt auch hohe Anforderung an die technische Infrastruktur. Ich führe regelmäßig mit meiner Firma Senecom Scrum Cooking Workshops durch. Der intensive Ressourceneinsatz agiler Teams wird dabei sehr deutlich.  Mehrere agile Kochteams bereiten gemeinsam ein Mahl in einer Eventküche zu. Die Ressourcennutzung, wie Kochplatten, Töpfe oder Messer ist beim Scrumcooking viel intensiver als bei klassischen Kochkursen. Häufig sind die Vermieter der Eventküchen von dem geschäftigen Treiben zunächst stark irritiert.

 

Dasselbe Phänomen kann man auch bei der agilen Softwareentwicklung beobachten. So werden Server durch automatisierte Prozesse stärker belastet als bei herkömmlichen Verfahren. Engagierte Mitarbeiter eines selbstorganisierten Teams definieren ihre Arbeitsweise selbst. Dabei entwickeln sie häufig spezifische Wünsche nach Arbeits­mitteln und Tools. Die Schwarm-Intelligenz findet Lösungen, auf die ein einzelner nicht käme. Dies führt zu höherer Geschwindigkeit, aber gleichzeitig auch zu erhöhtem Ressourcenbedarf. Wo viel gehobelt wird, fallen Späne und wo mehr gehobelt wird, fallen mehr Späne.

 

Dieser erhöhte Ressourcenbedarf und die Forderung nach einer Vielzahl unterschiedlicher Tools stellt viele Organisationen vor große Heraus­forderungen. Organisationen verwalten ihre Arbeitsmittel meist zentral und bemühen sich daher, die Toollandschaft überschaubar zu halten. Ein selbstorganisiertes Team beißt hier nicht selten mit seinen Anforderungen auf Granit. Agile Organisationen haben sich auf den herausfordernden Ressourceneinsatz durch die Umsetzungsteams vorzubereiten und ihn zu unterstützen, wobei gleichzeitig sicher­zustellen ist, dass sich die Teams bezüglich ihrer Arbeitsmittel sinnvoll abstimmen.

 

Fokussierung auf ein Projekt

 

Agile Methoden setzen voraus, dass sich ein Team auf ein Produkt fokussieren kann. Nur dann sind agile Projekte planbar und Steuerungsgrößen wie Story Points aussagekräftig. Darüber hinaus sinkt die Produktivität beim Wechsel zwischen mehreren Aufgaben beträchtlich. Multi-Tasking führt zu starken Einbußen der Produktivität. Weinberg führt au5s, dass jedes zusätzliche Projekt rund 20% Produktivität für das geistige Umrüsten fordert.[7] Dieser Beobachtung wird in Organisationen aber kaum Beachtung gezollt. Mitarbeiter werden in großem Umfang in mehreren Projekten eingesetzt, wobei ihre Kapazität meist ohne Abzüge verplant wird. Über Jahre hinweg wurden Mitarbeiter zu Spezialisten ausgebildet, so dass es nun schwierig ist, Projekte mit den erforderlichen Fähigkeiten zu besetzen. Die Mitarbeiter selbst fördern ihren Spezialisten-Status, der sie scheinbar unersetzbar macht.

 

Unternehmen mit ausgeprägter Spezialisierung der Mitarbeiter tun sich bei der Bildung cross-funktionaler Teams schwer. Die Teams werden zu groß, wollte man alle notwenigen Fähigkeiten und Kenntnisse in einem Projekt-Team bündeln. Darüber hinaus kann ein Team in diesem Setting die einzelnen Spezialisten nicht ausreichend beschäftigen. Aber auch unter diesen Bedingungen können Sie ein Scrum Team zusammenstellen, das sich auf ein Projekt fokussieren kann, wenn Sie Abstriche machen. Sie können auf ausgemachte Spezialisten im Projekt zu verzichten, vom Ideal der Vollauslastung abrücken und das Projekt mit der verfügbaren Besetzung angehen. Es ist erstmal unüblich und in vielen Organisationen unvorstellbar, dass man Mitarbeiter zwar voll bezahlt, aber nicht voll auslastet. Auch wenn es ein offenes Geheimnis ist, dass in großen Organisationen nicht jeder immer seine gesamte Arbeitszeit sinnbringend einsetzen kann, leben wir die Illusion der Vollauslastung. Vollauslastung kann aber im Sinne der Effizienz des Gesamtsystems durchaus schädlich sein. Dies hat Leonhardt sehr überzeugend ausgeführt.[8]

 

Disziplin der Reflexion

 

Agile Methoden setzen auf empirische Prozesssteuerung, will sagen, man richtet sich an den Erfahrungen aus. Feedbackschleifen und Reflexion sind institutionalisiert und Teil des Standardprozesses. Eigene Arbeitsweise und erzeugte Produkte werden in regelmäßigen Abständen betrachtet und verbessert. Diese Retrospektiven und Reviews können mühsam und unangenehm sein. Nur zu leicht verfällt ein Team im Wohlgefallen des eigenen Prozesses und Produkts. Agilität wird sehr häufig mit Spaß verbunden. Dabei wird übersehen, dass empirische Prozessteuerung dem Team ein hohes Maß an Disziplin und Selbstreflexion abverlangt. Es ist die Aufgabe des Scrum Masters, das Team auf dem Pfad der kontinuierlichen Verbesserung[9] zu halten.

 

Betrachtung der Mitarbeiter als Ressourcen

 

Menschliche Leistungsfähigkeit, insbesondere im geistigen Bereich, hängt im starken Ausmaß davon ab, ob sich die Mitarbeiter in ihrem Arbeitsumfeld mit ihren Kollegen und Aufgaben wohl fühlen. Die Leistung eines Teams hängt nicht nur von der Leistungsfähigkeit ihrer Mitglieder ab, sondern auch von deren Interaktionen und sozialen Beziehungen. Leistungsfähige Teams haben sich über die Phasen des Storming, Forming und Normings gefunden.[10] Teambuilding erfordert Zeit und aufmerksame Menschenführung. Unternehmen, die ihre Mitarbeiter als Ressourcen betrachten, ignorieren dies und verschieben im Geiste der Ressourcenoptimierung Menschen wie seelenlose Maschinen. Dabei gefährden sie die Leistungsfähigkeit des Teams. Ein Hochleistungsteam wächst über einen langen Zeitraum zusammen. Die einzelnen Mitglieder kennen und respektieren die wechselseitigen Stärken und Schwächen und haben sich aufeinander eingespielt.

 

Unterwanderung der Selbstorganisation

 

Gewachsene Rituale können die Selbstorganisation des Teams unterwandern. Selbstorganisation braucht Raum und muss geübt werden. Erlebt ein Team immer wieder, dass Entscheidungen über seinen Kopf hinweg getroffen werden, dass Manager unmittelbar Anweisungen an einzelne Teammitglieder geben, statt ihre Wünsche dem Product Owner mitzuteilen, nimmt die Bereitschaft zur Selbstorganisation ab. Mitarbeiter, die wie Kinder behandelt werden, verhalten sich auch so und lehnen Verantwortung ab. Verantwortung zu übernehmen ist erstmal unangenehm. Mitarbeiter sind dazu nur bereit, wenn sie gleichzeitig Respekt für ihre Entscheidungen und Wünsche erleben. Wenn Mitarbeiter nur dann Verantwortung übernehmen sollen, wenn es gerade genehm ist, werden sie diese Verantwortung verweigern.

 

Mitarbeiter werden nicht unmittelbar bei Einführung einer agilen Methode Verantwortung übernehmen, sondern müssen erleben, dass sich ihr Einsatz auszahlt und ihnen Vertrauen und Respekt entgegengebracht wird. Essenziell ist dabei eine ausgereifte Fehlerkultur. Mitarbeiter, die befürchten müssen, bei Fehlern sanktioniert zu werden, werden nicht bereitwillig Verantwortung übernehmen. Häufig wird bei Problemen, vor allem der Schuldige gesucht. Entspricht dies der Kultur ihres Unternehmens, wird es schwierig sein, Selbstorganisation zu leben. Mitarbeiter, die befürchten müssen, für ihre Initiative an den Pranger gestellt zu werden, werden kaum aus dem Schatten treten. Einige Firmen greifen zu drastischen Maßnahmen, um eine positive Fehlerkultur einzuführen. Dark House Consulting bspw. ‘belohnt’ jährlich den größten Irrtum mit einer Geldprämie.

 

Über die Jahre hinweg sind in Organisationen Kommandostrukturen entstanden, um die Leistungen der Mitarbeiter zu kontrollieren. Dies konterkariert die Selbstorganisation, die Freiraum braucht. Funktionierende Selbstorganisation basiert auf Vertrauen. Die im Laufe der Zeit entstandenen Kontrollsysteme entmündigen Mitarbeiter und kosten Zeit. Diese Systeme werden mit der Einführung von Agilität nicht einfach abgeschafft, sondern existieren weiter, da sie sich über Jahre hinweg etabliert haben.  

 

Ego-Kultur konterkariert Teamgeist

 

In agilen Teams steht die Teamleistung im Vordergrund. Das Team verpflichtet sich, ein Produkt zu liefern und steht gemeinsam für Erfolg und Misserfolg ein. Unsere sozialen Strukturen hingegen fördern vorrangig die Leistungen Einzelner. In unserer Kultur wird Individualität geschätzt und gefördert. Unsere Heldengeschichten handeln von Einzelnen, die sich in widrigen Umständen gegen Andere erfolgreich durchgesetzt haben. Bei unseren Spielen geht es vorrangig ums Gewinnen. Auch Mitarbeiter streben danach, sich von den anderen abzuheben. Gelingt ihnen dies, wird dies häufig entlohnt.

 

Erfolgreich im Team zu handeln, setzt hingegen ganz andere Qualitäten voraus. Die Fähigkeit aufeinander einzugehen, sich zuzuhören und zu unterstützen. Hier ist ein Umdenken in unseren Organisationen erforderlich. In funktionierenden agilen Teams können einzelne schnell lernen, ihr persönliches Ego zurückzustellen. Hierzu hatte ich ein schönes Erlebnis: Ich leitete ein Team mit einem absoluten Experten der Datenbankentwicklung. Er war mit seinen außergewöhnlichen Kenntnissen und Intellekt ein großer Gewinn für das Team. Schade war nur, dass er sich dessen allzu gut bewusst war und sich entsprechend arrogant verhielt. Er hatte häufig das Auftreten einer Diva und machte sich über die agilen Teamprozesse lustig. Da er zu einem eingespielten Scrum-Team dazustieß, störte er den Ablauf nicht. Das Team lebte selbstbewusst seine agile Praxis und forderte auch die ‘Diva’ immer wieder zum Mitmachen auf. Eines Tages musste er dem Team widerwillig eine seiner Umsetzungen erklären. Bei seinen Ausführungen stellte ihm eine Junior-Entwicklerin eine Frage, die ihn erbleichen ließ. Er hatte einen wichtigen Punkt übersehen und die junge Frau hatte ihm mit ihrer Frage viel Zeit und Arbeit erspart. Einige Wochen später hörte ich ihn sagen:

 

„Ein gutes Team ist immer besser als der intelligenteste Mitarbeiter.“

 

Seine Aussage hat mich sehr bewegt und ich folgerte daraus, dass die Erfahrungen im Scrum Team ihm geholfen haben, sein Ego zurückzustellen.

 

Dies sind nur einige von vielen möglichen Herausforderungen bei der agilen Transition. Ich habe sie aufgeführt, um deutlich zu machen, dass agile Transition mit einem Paradigmenwechsel verbunden ist, man könnte auch von einer ‘stillen Revolution’ sprechen. Wagen Sie diesen Weg, machen Sie sich auf Ärger und Probleme gefasst, aber es ist der Mühe wert. In dem Ausmaß, indem es ihnen gelingt, die Kräfte der Selbstorganisation zu mobilisieren, werden Produktivität, Effizienz und die Freude an der gemeinsamen Arbeit wachsen.[11]

 

 

 


[1] Vgl. hierzu Cohen, Mike (2010); S. 10 ff.;

[2]  Vgl. Maximini, Dominik (2018); Kapitel 10.2

[3] Vgl. Schäfer, Frank (2009); S 97 ff.

[4]  Vgl. hierzu Leonhardt

[5] Vgl. Maximini, Dominik (2018); Kapitel 10.2

[6] Vgl. Maximini, Dominik (2018); Kapitel 10.2

[7] Weinberg, Gerald M. (1992); S. 284 ff.

[8] Vgl. Leopold, Klaus (2017); S. 6 ff.;

[9] Im agilen Kontext wird hier häufig auf die japanische Philosophie des Kaizen verwiesen. Kaizen umfasst die Lehre um Streben nach kontinuierlichen Verbesserung.

[10] Vgl. hierzu das Phasenmodell; Tuckman, Bruce W. (1965);

[11] Diese positiven Effekte konnte ich persönlich vielfach erleben. Wie eingangs erwähnt, gibt es zahlreiche Studien zusammengefasst, die dies untermauern. 

 

Literaturangaben

Cohen, Mike (2010): Succeeding with Agile: Software Development Using Scrum; Michigan; 2010;

Leopold, Klaus (2017): Kanban in der Praxis: Vom Teamfokus zur Wertschöpfung; München; 2017;

Maximini, Dominik (2018): Scrum – Einführung in die Unternehmenspraxis: Von starren Strukturen zu agilen Kulturen; Hattenhofen; 2018;

Schäfer, Frank (2009): Erfolgreiche Kooperation im Unternehmen: Warum wir heute mehr brauchen als gute Führungskräfte; Frankfurt / New York 2010

Tuckman, Bruce W. (1965): Developmental sequences in small groups; Psychological Bulletin , 63, S. 348-399;

 

Weinberg, Gerald M. (1991): Quality Software Management: System Thinking; New York; 1992;


25. Januar 2019

Kanban für das Management

Wie lässt sich Kanban für das Management einsetzen? Um Ihnen dies zu beantworten, muss ich etwas ausholen.

Die jahrelange Beobachtung von Organisationen hat mir vor allem eins gezeigt:
Organisationen beschäftigen sich vorwiegend mit sich selbst. Es ist überraschend und wahrscheinlich nur der Automatisierung zu verdanken, dass trotz allem noch Gewinne eingefahren werden. In diesem Zusammenhang werde ich in Folge von „verfetteten Organisationen“ sprechen. Diese Analogie spielt darauf an, dass Organisationen ihre Ressourcen nicht sinnvoll einsetzen können und dadurch unbeweglich werden.

In großen Organisationen ist es häufig schwierig Mitarbeiter zu finden, die für einen Endkunden Leistungen erbringen. Die Mehrzahl der Mitarbeiter hat interne Kunden. Dabei ist es schwer feststellbar, ob das was der einzelne Mitarbeiter leistet, tatsächlich wertschöpfend ist. Es genügt oftmals, wenn alle hinreichend beschäftigt sind. Schwierig zu akzeptieren ist nur der Leerlauf. So sehen auch Manager ihre Aufgabe häufig darin, ihre Mitarbeiter gut – am besten zu 100% - beschäftigt zu halten. Nun ist es offensichtlich, dass nicht wertschöpfende Prozesse und Leistungen nur Kosten ohne Nutzen erzeugen. Außerdem ist es für Mitarbeiter frustrierend und die Gesamtorganisation wird unflexibel.

Doch Untätigkeit ist schwer zu ertragen – vor allem im beruflichen Kontext. Hier steht ja auch die Entlassung zu befürchten, wenn auffällt, dass eigentlich nichts Sinnvolles zu tun ist. Um die Illusion aufrecht zu erhalten, glaubt das ganze System mit Inbrunst an den Sinn des Geleisteten. Zynische Bemerkungen spart man sich für die Café-Pause oder den Stammtisch auf.

 

Und dabei tragen Menschen eigentlich furchtbar gerne für einen gemeinsamen Erfolg etwas bei. Und in einem überschaubaren Kontext gelingt uns dies auch gut. Schwierig wird es nur in komplexen Systemen. Kanban kann für diese Führungsaufgaben eine gute Lösung bieten. 

Kommentare: 0

Scrum meets Kitchen – Einblicke aus einer völlig neuen Perspektive

Ich durfte jetzt schon einige Teams durch die Scrum Cooking-Erfahrung führen und möchte mit euch teilen, was ich dabei beobachten konnte.

 

Ganz kurz: Was ist Scrum Cooking?
Scrum Cooking ist Kochen nach der Scrum Methodik. Dabei lernt und erlebt man im Team, wie Scrum funktioniert, hat Spaß und vergisst das Gelernte nicht mehr, denn es wurde erlebt. Soviel dazu, wer mehr wissen will, siehe www.scrumkitchen.de

 

1.       Beobachtung: Menschen lieben es im Team zu arbeiten!

 

Die Stimmung beim Scrum Cooking lässt sich mit einer Klassenfahrt vergleichen. Ist es vorbei, fühlt man sich aus der Wärme der Gemeinschaft entlassen. Ich habe oft die Erfahrung gemacht, dass Teilnehmer bleiben, um aufzuräumen, um diese Erfahrung verlängern zu können. Tatsächlich ist es für Menschen sehr schön gemeinsam etwas zu schaffen.

 

Die Frage beschäftigt mich, warum im Arbeitsleben diese Freude nicht auch immer im gleichen Ausmaß fühlbar ist. Ich habe diese Freude auch in gut funktionierenden Scrum-Teams in der Arbeitswelt erlebt. Ich denke, ein Hindernis für Freude am Arbeiten sind die Hierarchien. Menschen fühlen sich von Vorgesetzten und Organisationsstrukturen gegängelt und ihre Selbstbestimmung ist beeinträchtigt. Hierarchien erzeugen Konkurrenz um Aufstiegspositionen, was egoistische Verhalten fördert. Manager haben oft nicht die Zeit, sich um ihre wesentlichen Führungsaufgaben zu kümmern, weil sie damit beschäftigt, die Arbeitsorganisation zu managen. Durch Scrum kann sich ein Team selbst organisieren, wodurch das Management wieder die Zeit findet, strategische Entscheidungen zu treffen und sich um das Wohlbefinden seiner Mitarbeiter zu kümmern. Damit wird der Rahmen geschaffen, dass Menschen in Freude zusammenarbeiten können.

 

2.       Beobachtung: 3+4 = 15 oder das Ganze ist mehr als die Summe seiner Teile

 

Im Scrum Cooking gibt es immer auch einen kreativen Anteil. Die Teams bekommen ein Motto und denken sich Gerichte selbst aus. Was dort innerhalb kürzester Zeit (45 Minuten) mit vorgegebenen Lebensmitteln gekocht wird, ist unbeschreiblich. Die Buffets können mit den raffiniertesten und besten Restaurants mithalten, wenn sie sie nicht gar übertreffen. Die Köche sind Menschen, die vor kurzem noch behaupten haben, sie könnten nicht kochen. Manche von ihnen wollten noch nicht einmal kochen. Was in diesem kreativen Raum durch wechselseitige Inspiration entsteht, versetzt die Teilnehmer in Begeisterung. Daraus kann man lernen, dass ein gut funktionierendes Team immer eine bessere Lösung findet, als die besten und intelligentesten Einzelkämpfer. Auch diese Erfahrung können Menschen beruflich in Scrum-Teams machen. Überagende Entwickler merken, dass auch sie noch von anderen lernen können und dass ihre Lösung noch besser wird, wenn sie gemeinsam mit anderen kooperieren. Und es ist schön mitzuerleben, wie Einzelne ihr Ego langsam aufgeben und dabei gewinnen. Die Last fällt von ihren Schultern, sie haben ein Team im Rücken, auf das sie sich verlassen und von dem sie lernen können. Und natürlich erleben sie das schöne Gefühl, Teil eines Teams zu sein, für das man seinen Beitrag leistet.

 

3.       Beobachtung: Mehr Freiraum der Gestaltung = Mehr Spaß

 

Ein Scrum Cooking-Event besteht aus zwei Sprints. Im ersten Sprint sind die Anforderungen relativ präzise, im zweiten Sprint besteht viel Raum für Eigengestaltung und Kreativität. Die Teilnehmer fühlen sich zunächst meist überfordert von der Aufgabe des zweiten Sprints. Im Austausch miteinander inspirieren sich die Teilnehmer und finden die Energie, sich der Aufgabe zu stellen. So weicht die Überforderung bald reger Geschäftigkeit. In der abschließenden Retrospektive berichten viele Teilnehmer, dass ihnen der zweite Sprint besonders gut gefallen hat. Der Freiraum war für sie inspirierend und hatte einen großen Spaßfaktor. Auch dies kann man an Scrum-Teams beobachten. Arbeiten im Scrum-Team macht alleine deshalb mehr Spaß, weil Anforderungen gemeinsam ausgearbeitet werden. Menschen unterschiedlicher Kompetenzen wie Entwickler, Product Owner und Business User entwickeln im gemeinsamen Gespräch völlig neue Gesichtspunkte und Einsichten, wodurch die Anforderungen geschärft und präzisiert werden. Das Energielevel ist beim gemeinsamen Arbeiten höher und Ergebnisse werden schneller produziert, vorausgesetzt man arbeitet konstruktiv miteinander. In der Kommunikation miteinander wachsen das wechselseitige Verständnis und die Kenntnisse. Anforderungen hingegen, die im stillen Kämmerlein entwickelt wurden, spiegeln die beschränkte Sichtweise eines Einzelnen wieder. Zudem ist der Prozess für den Anforderungsmanager sehr mühsam. Es liegt auf der Hand, dass Anforderungen, die im wechselseitigen Austausch formuliert wurden, tragfähiger sind.

 

Wenn ihr auch die Erfahrung eines Scrum Cooking-Workshops machen wollt, schreibt uns gerne einfach über die Kontaktseite.

Kommentare: 0