Derzeit sind viele Organisationen dabei, agile Methoden wie SCRUM 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.
Der Hype ist 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.
Viele sind hartnäckig in Bezug auf den eingeschlagenen Weg, weniger in Bezug auf das Ziel.
Friedrich Nietzsche
Agile Projektmanagementmethoden sind schlank
Scrum kann 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.
Die Implementierung
Eine erfolgreiche Implementierung von Scrum setzt voraus, dass Teams sich selbst organisieren 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 herausfordernd, 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.
Außerhalb der Software-Entwicklung
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 ungewissem Ausgang, was sich auf die Motivation der einzelnen Mitarbeiter nicht unbedingt förderlich auswirkt.
Agile Transformation fordert den einzelnen Mitarbeitern viel ab, da Arbeitsweise, Rollenverstä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.