Geduldig bleiben und lernen
Nicht wenige Unternehmen orientieren sich bei ihrer agilen Transformation an bestimmten Modellen wie Scrum. Marcus Raitner ist von Scrum fasziniert und hat in unterschiedlichen Rollen schon so manche Transformation einer IT-Organisation mitgemacht. Ein Gespräch darüber, was Frameworks leisten können, die Vorzüge von Scrum und welche Elemente bei jeder agilen Organisation vorhanden sein sollten.
Marcus, angenommen wir haben eine klassische Organisation, die in Abteilungen organisiert und stark hierarchisch geprägt ist. Das Projektmanagement läuft nach dem Wasserfall-Modell. Nun möchte sie sich agiler aufstellen. Hilft dieser Organisation ein Framework, das Leitplanken zum Vorgehen und/oder zu einem Zukunftsbild als Orientierung vorgibt?
Eine solche Situation, wie du sie beschreibst, gibt es häufig. Das Erste, was ich oft erlebe, ist, dass die Struktur nicht hinterfragt wird. Deshalb nimmt man die klassische, funktional organisierte Organisation und sagt: „Abteilung xy versucht jetzt agiler zu werden.“ Und diese Abteilung führt dann beispielsweise Kanban oder Scrum ein. Doch macht es überhaupt einen Unterschied, wenn diese eine Abteilung agiler wird?
Denn wenn man den ganzen Wertstrom und die Wertschöpfung in der Organisation betrachtet, dann ist die Wahrscheinlichkeit sehr hoch, dass die eine Abteilung nur ein kleiner Ausschnitt in einer langen Kette von Übergaben ist.
Deshalb ist die spannende Frage: Was soll mit einer agilen Organisation überhaupt erreicht werden? Was ist das „Wozu“? Die Beantwortung dieser Frage sollte am Anfang stehen.
Es gibt einige Merkmale, die eine agile Organisation auszeichnen. Was wären für dich die wichtigsten, die entscheidenden Kernelemente einer agilen IT-Organisation?
Ein entscheidendes Element ist für mich immer die kontinuierliche Entwicklung eines gemeinsamen Produktes. Das kann ein IT-Produkt sein, das kann eine Software sein oder das, was die Organisation als Produkt versteht.
Du hast viele Jahre Erfahrung mit Scrum. Was fasziniert dich ganz allgemein daran?
Mich fasziniert daran das Bestreben, sich auf das Wesentliche zu fokussieren.
ich auf das zu konzentrieren, was Wert erzeugt. Es geht um die Entwicklung von bestmöglicher Software – mit dem genau richtigen Maß an Dokumentation. Es wird alles weggelassen, was nicht wertschöpfend ist: „Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell“, heißt es deshalb in den Prinzipien des agilen Manifests.
Scrum war ursprünglich in der Softwareentwicklung im Einsatz. Doch sein Einfluss geht weit über den IT-Bereich hinaus.
Der Ursprung von Scrum liegt eigentlich nicht in der Softwareentwicklung. Der Begriff „Scrum“ wurde erstmals 1986 von Hirotaka Takeuchi und Ikujiro Nonaka in einem Artikel der „Harvard Business Review“ erwähnt, in dem sie einen neuen Ansatz für die Produktentwicklung beschrieben, der sich durch schnellere Iterationen, mehr Teamautonomie und einen flexibleren Umgang mit Änderungen auszeichnete. Dieser Ansatz wurde mit dem Rugby-Begriff „Scrum“ verglichen, der die dynamische und teamorientierte Art der Produktentwicklung widerspiegeln sollte. Erst auf diesen Ideen ist das Scrum-Framework für die Softwareentwicklung entstanden, das 1995 erstmals vorgestellt worden ist.
Aber du hast natürlich auch Recht. Das, was wir heute als Scrum bezeichnen, wird als Softwareprodukt-Entwicklungsmethode gesehen.
Und nach meiner Beobachtung ist Scrum über die Softwareentwicklung hinaus sehr populär geworden. Die Prinzipien, Rollen und Artefakte sind Inspiration für die Gestaltung von Organisationen und Zusammenarbeit geworden. Insbesondere denke ich dabei an das iterative Vorgehen, die Verteilung von Verantwortung auf mehrere Schultern, die selbstorganisierten, interdisziplinären Teams. Scrum hat die Art, wie wir grundsätzlich zusammenarbeiten im Unternehmen, maßgeblich beeinflusst. Oder wie siehst du das?
Ja, das stimmt. Prinzipien aus Scrum haben sicherlich Einfluss gehabt auf die Art, wie Organisationen gebaut werden. Ich denke, das hat damit zu tun, dass die Prinzipien aus Scrum mit vielen Aufgabenstellungen in den Organisationen resonieren. Denn:
Das plangetriebene Vorgehen aus den 80ern und 90ern ist irgendwann zu langsam geworden.
Mittlerweile ist eher das empirische Vorgehen gefragt, was Scrum letztendlich ist. Für einen Sprint oder für einen Release wird eine Hypothese aufgestellt, es wird entwickelt und dann gibt es Feedback. Auf Basis dessen wird angepasst oder gar die Richtung geändert. Das ist Agilität im Kern, ein empirisches Vorgehen.
Und in einer zunehmend komplexen und schnelllebigen Welt macht dieses empirische Vorgehen mehr Sinn als ein klassisches plangetriebenes Vorgehen.
Inwieweit taugt Scrum als Orientierung gebendes Modell oder Framework für eine agile Transformation einer IT-Organisation?
Überall dort, wo ich einen Produktentwicklungscharakter habe – und das ist in der IT definitiv der Fall –, kann man nach Scrum arbeiten. Die Frage ist: Wo passt Scrum nicht?
Und wo passt es nicht?
Dort, wo man eher transaktional tätig ist. Zum Beispiel wenn Kundenanfragen oder Tickets abgearbeitet werden müssen, im Callcenter zum Beispiel.
Aber könnte man nicht umgekehrt sagen, dass es am Ende immer darum geht, Produkte an den Kunden zu liefern? Egal ob es IT- oder andere Produkte sind. Ein Unternehmen muss sich als Ganzes kundenzentriert ausrichten, um die bestmöglichen Produkte überhaupt bauen zu können.
Nehmen wir an, ein Unternehmen entwickelt und produziert Autos. Das kann man sicherlich bis zu einem gewissen Grad agil machen. Bei BMW habe ich das auch schon gesehen, dass das so passiert.
Aber irgendwann ist das Auto verkauft und dann wird After Sales wichtig oder Garantien werden in Anspruch genommen. Das ist dann transaktionales Business. Das kann man nicht im Produktentwicklungsprozess abbilden. Diese Kundenanfragen würde man nie in Sprints abarbeiten. Dafür ist eher Kanban geeignet.
Zu Kanban hast du auch eine große Nähe.
Wenn es um Agilität in der Automobilindustrie geht, kommt man an Kanban nicht vorbei.
Das ist ein klassischer Begriff aus dem Lean Management, wo die Methode herkommt.
Es gibt Menschen, die behaupten sogar, Scrum wäre Agilität mit Stützrädern und Kanban sei die reine Lehre. Denn Scrum bietet im Vergleich zu Kanban sehr viel Struktur: Sprints, bestimmte Rollen, Meetings und so weiter. Kanban hat das nicht, ist aber ebenfalls ein inkrementeller Entwicklungsprozess.
Du hast bezüglich Scrum vor allem von der Produktentwicklung gesprochen. Aber Scrum basiert doch auch auf bestimmten Prinzipien und Werten wie „Fokus“ und „Mut“. Denkst du, diese Werte können ebenfalls hinsichtlich der Zusammenarbeit und Führung in einer Organisation Orientierung geben?
Ja, Scrum basiert auch auf diesen Werten und davon kann man sich sicherlich inspirieren lassen. Dafür ist Scrum jedoch nicht gemacht. Ich finde, man darf es nicht übertreiben. Scrum will eine Produktentwicklungsmethode sein – nicht mehr und nicht weniger. Man kann sich vermutlich mehr aus dem „Agilen Manifest“ rausziehen, das einen breiteren „Scope“ hat.
So gut wie alle Firmen haben ihre IT-Organisation umgebaut oder haben das vor. Woran orientiert man sich bei einem solchen Umbau, bei dem es meist darum geht, agiler zu werden? Lässt man sich von vorhandenen Modellen inspirieren und entwickelt auf dieser Basis ein eigenes Framework?
Ich habe schon verschiedene Ansätze gesehen. Den Ansatz, den wir damals bei BMW verfolgt haben …
… das Programm „100 % Agile“ …
Ja, genau. Bei BMW haben wir unser eigenes Modell entwickelt. Wir hatten überlegt, was unsere Produkte sind und wie wir die IT entsprechend strukturieren sollen. So entstanden die unterschiedlichen Teams. Danach wurde überlegt, wie diese Teams zusammenarbeiten, nach welcher Methode. Im Kern war das sicherlich Scrum. Die spannende Frage war dabei aber vor allem: Wie arbeiten mehrere Teams zusammen, die am selben Produkt arbeiten? Also, wie skaliert das Ganze? Und wie sieht die Zusammenarbeit
im Großen über mehrere Produkte hinweg aus, wenn es Abhängigkeiten gibt? So wurde im Laufe der Zeit ein eigenes Modell entwickelt, was allerdings Geduld erfordert hat. Wenn man diese Geduld nicht hat, versucht man meistens, irgendein bekanntes Modell wie Spotify oder SAFe einzuführen.
Kannst du kurz noch mal sagen, was SAFe ist?
SAFe ist ein „Scaled Agile Framework“, ein allumfassender Werkzeugkasten für agile Skalierung.
Und dann gibt es beispielsweise noch LeSS, also Large-Scale Scrum. Dessen Anhänger behaupten oft, dass es auf Scrum basiert und ein „reines“ Framework bietet.
Wohingegen SAFe ein umfangreiches Corporate-Framework ist, das sehr viel Anklang in traditionellen Unternehmen findet und dort gut anschlussfähig ist. Doch viele „Agilisten“ sagen, mit SAFe springe man bei einer Transformation nicht weit genug. Ich bin dafür, dass man immer sein eigenes Modell entwickelt. Nur dadurch findet Lernen statt.
Was würdest du aber empfehlen, wie man mit solchen Modellen wie von Spotify oder SAFe umgeht als Unternehmen? Macht es Sinn, sich zumindest von diesen Modellen inspirieren zu lassen?
Absolut. Gerade in SAFe gibt es viele einzelne Praktiken, die wichtig und hilfreich sind, zum Beispiel der vierteljährliche Zyklus, in dem man das PI Planning macht, also das „Program Increment Planning“. Es gibt damit oberhalb des Sprintzyklus noch einen Unternehmenszyklus, bei dem man über Abhängigkeiten und Prioritäten spricht. Das ist sinnvoll.
Man kann sich also von solchen Modellen einzelne Methoden rausnehmen. Aber man muss erst einmal zu diesem Punkt kommen, an dem man feststellt, dass in Sachen Koordination von mehreren Teams eine Herausforderung besteht.
Man muss selbst den Schmerz einmal spüren?
Genau. Und dann findet Lernen statt, dann ist es nachhaltig.
Du hast schon die Transformation der IT-Organisation bei BMW erwähnt, das Programm mit dem Namen „100% Agile“. Das Vorhaben war damals auch in den Medien. Was war der Grund für das Vorhaben?
Wir sind weggegangen von diesem klassischen IT-Modell, das darauf beruht, dass die IT eigentlich stabil sein muss. Dieses Paradigma hat früher geherrscht. Aber damit ist man heute zu langsam. Man kann nicht immer, wenn sich etwas verändert, erst einmal ein Projekt aufsetzen. Denn das muss genehmigt werden, dann wird eine Projektorganisation aufgebaut. Das dauert viel zu lang, um eine Veränderung herbeizuführen.
Deswegen haben wir damals gesagt, dass wir gar keine Projekte mehr machen, sondern eine kontinuierliche Entwicklung der IT in Form von IT-Produkten – 100 Prozent agil. Eine Veränderung oder eine neue Anforderung wurde über den Weg des Backlogs und über die Product Owner reingebracht und schnell umgesetzt, ohne ein Projekt machen zu müssen.
Auch wenn es eine Zeitlang gedauert hat, bis wir den Zuschnitt in der IT und die IT-Produktlandkarte finalisiert hatten, war das der richtige Weg. Zudem war es wichtig, sich wirklich Zeit zu lassen, das gemeinsame Arbeitsmodell zu entwickeln. Ich glaube, zwischen der Entscheidung, eine agile Produktorganisation aufzusetzen, und der ersten Version des agilen Arbeitsmodells lagen zwei Jahre.
Und wenn du vom „gemeinsamen Arbeitsmodell“ sprichst, dann meinst du auch die Zusammenarbeit mit den Fachbereichen, mit dem Business?
Ja, genau. Es geht um ein Modell der Zusammenarbeit. Dazu gehören unter anderem die notwendigen Rollen, unterschiedliche Arten von Meetings, Entwicklungsmethoden. Auch das Business ist in diesem Modell berücksichtigt. Zum Beispiel gibt es bei BMW jeweils einen Product Owner aus der IT und einen Product Owner aus dem Business.
Und nach diesem Modell wird heute immer noch gearbeitet bei BMW?
Ja. Diese Art der Zusammenarbeit gibt es heute auch noch und sie ist sehr erfolgreich. Gerade die Nähe von IT und Business macht einen großen Unterschied. Es wurden aber auch Dinge wieder zurückgenommen im Laufe der Zeit, zum Beispiel die Trennung von fachlicher und disziplinarischer Führung, wie es sie auch beim Spotify-Modell gibt. Sie ist in Teilen wieder aufgehoben worden.
Warum?
Soweit ich weiß, wurde die Trennung als richtig angesehen. Aber in der Zusammenarbeit mit dem Rest der Organisation gab es wohl zu viele Herausforderungen. Die geteilte Führung war nicht anschlussfähig.
Angenommen, du müsstest jetzt eine IT-Organisation transformieren in Richtung agile Organisation. Was muss ein Framework liefern, damit es dir Orientierung bietet?
Mir persönlich hilft es, wenn es an klaren Prinzipien orientiert ist. In Scrum gibt es beispielsweise solche Prinzipien.
Was ich nicht gut finde, ist eine detaillierte Blaupause, die jeden Schritt vorgibt.
Das ist nicht hilfreich, weil das Framework dann nur eine Kopie ist.
Wichtig ist meiner Meinung nach, im Großen zu starten und sich mit der Frage zu beschäftigen, was man wirklich erreichen will. Dann sollte man auf die gesamte Organisation blicken oder zumindest auf einen breiten Ausschnitt, sodass man „end-to-end“ denken kann und sich nicht im Kleinen verliert.
Und schließlich muss man sich fragen, wo ein guter Startpunkt ist. Wie könnte vielleicht ein Pilot aussehen, eine Pilotphase, die sich nach den erarbeiteten Prinzipien orientiert? Das Team sollte interdisziplinär, möglichst end-to-end zusammengestellt sein. Und dann macht man eventuell einen zweiten Piloten und versucht beide miteinander zu vernetzen. Anschließend geht es in die Skalierung des Modells, bei dem das Lernen im Zentrum stehen sollte. Dabei hat die psychologische Sicherheit eine enorme Bedeutung: Kann ich mich hier was trauen? Darf hier auch mal was schiefgehen?
In vielen Organisationen hast du dieses Level an Sicherheit gar nicht und deshalb findet dort auch kein wirkliches Ausprobieren statt.
Du sagst, dass jeder sein eigenes Framework oder Vorgehen bei einer Transformation finden muss. Aber gibt es nicht dann doch bestimmte Elemente, die allgemeingültig sind, wenn eine agile Organisation angestrebt wird? In jeder agilen Organisation wird iterativ gearbeitet, arbeiten Teams selbstorganisiert und braucht es psychologische Sicherheit zum Beispiel.
Das stimmt schon. Ausgangspunkt ist die Komplexität, die wir erleben. Und diese Komplexität im Umfeld erfordert ein empirisches Vorgehen. Und sie erfordert ein interdisziplinäres Arbeiten, denn, wenn man es nicht tut, haben wir zu viele „Übergaben“. Die gilt es, zu vermeiden, um nicht Schnelligkeit einzubüßen. Und die psychologische Sicherheit braucht es, sonst traut sich niemand was. Ja, diese Elemente sind durchaus allgemeingültig: Auf diesem Level finde ich Frameworks sehr gut.
Können wir nicht daraus doch eine Blaupause bauen?
Ich würde es aber nicht Blaupause nennen, weil das implizieren würde, dass man es einfach kopieren kann. Und das geht nicht. Aber wir können durchaus von „Leitfaden“ sprechen.
Und die Elemente in diesem Leitfaden wären: iteratives Vorgehen, interdisziplinäres Arbeiten, psychologische Sicherheit?
Ja. Und dann würde ich noch die kontinuierliche Verbesserung der Arbeitsweise dazunehmen. Die Teams verbessern ihr Arbeitsmodell, nicht die Manager, kein Berater, sondern die Teams selbst. Das ist mit Sicherheit auch ein zentrales Prinzip.
Du hast ein neues Buch vor Kurzem veröffentlicht: „Manifest zur menschlichen Führung“. Es ist eine Erweiterung der ersten Veröffentlichung aus dem Jahr 2019. Welche Rolle kann Führung in so einem Framework spielen oder in so einer agilen Transformation? Oder spielt sie eigentlich erst später eine Rolle?
In der agilen Transformation wandelt sich auch die Führungsrolle – von der klassischen Schachmeisterrolle, die die Bauern über das Spielbrett bewegt, hin zur Gärtnerrolle, die die Rahmenbedingungen so gestaltet, dass die Teams gut arbeiten können. Führung zur Selbstführung. Kontext statt Kontrolle, wie das beispielsweise bei Netflix heißt. Diese Veränderung muss in der Transformation ebenfalls stattfinden, sonst ist sie nicht nachhaltig.
Vielen Dank für das Gespräch.
Das Interview führte Jan C. Weilbacher
Autor
Dr. Marcus Raitner
ist überzeugt, dass Elefanten tanzen können. Darum begleitet er Unternehmen als Agile Coach auf ihrem Weg zu mehr Agilität. Er leitet heute bei der Allianz Consulting die Practice Area „Agile“, die mit ihren Agile Coaches die agile Transformation der Allianz Gruppe weltweit unterstützt. Über die Themen Führung, Digitalisierung, Neue Arbeit, Agilität und vieles mehr schreibt Marcus Raitner seit 2010 in seinem Blog. Zuletzt erschien im Verlag Franz Vahlen sein neues Buch „Manifest für menschliche Führung: 6 Thesen und 14 Prinzipien für eine neue Führung im Zeitalter der Digitalisierung“.
»Marcus bei LinkedIn
