Inhalt dieses Artikels
- 1. Agile Transformation: Ein Kulturwandel
- 2. Was genau ist eigentlich eine digitale Transformation?
- 3. Agiles Arbeiten erfordert eine grundlegend andere Herangehensweise.
- 4. Immer mehr Unternehmen, freiwillig oder notgedrungen sich mit der Digitalisierung beschäftigen.
- 5. Scrum Methoden
- 6. Die drei Rollen in Scrum
Agile Transformation: Ein Kulturwandel
Agile Transformation ist mehr als das Einführen von Rollen und Regeln. Warum Agile Transformation ein Kulturwandel ist, der die gesamte Organisation betrifft und nicht unterschätzt werden darf…
Immer mehr Unternehmen und Organisationen stehen heute vor der Herausforderung einer digitalen Transformation. Sei es, um Kosten zu sparen, neue Produkte zu entwerfen oder gar neue Märkte zu bedienen. Wir haben die Ära der Globalisierung hinter uns gelassen und stehen nun an der Schwelle einer neuen Ära, der Virtualisierung und damit eröffnen wir eine neue Dimension.
Die Reise von einer 2D Welt in eine 3D Wirklichkeit verläuft gerade über das Zwischenziel Digitalisierung und begründet den Druck vieler Unternehmen zur digitalen Transformation.
Und natürlich reist mit ihr oft genug ihr kleiner Bruder, die agile Transformation, denn viele Unternehmen merken auf ihrer Reise sehr schnell, dass eine umfassende digitale Transformation mit herkömmlichen Management-Methoden schnell an Grenzen stößt.
Warum das so ist und welche Konsequenzen sich daraus für Organisationen, ergeben beschreibt dieser Artikel.
Was genau ist eigentlich eine digitale Transformation?
Eine digitale Transformation ist zunächst einmal weit mehr, als nur für den einen oder anderen Geschäftsprozess ein Tool einzuführen und damit z.B. lästige und in der ganzen Organisation herumflatternde Excel-Tabellen abzulösen.
Ziel einer digitalen Transformation ist, wesentliche Geschäftsprozesse zu automatisieren, um schneller liefern zu können, Kunden bessere Services zu bieten, Transaktionskosten zu senken, sich neue Märkte zu erschließen oder neue Marktkanäle zu bedienen oder sogar neue Produkte am Markt anbieten zu können. Es sind in jedem Fall ernsthafte ökonomische Interessen und Zielsetzungen, die hinter der Motivation zu einer digitalen Transformation stehen sollten. Und erreicht werden sie durch das Automatisieren von ganzen Geschäftsprozessketten.
Wir denken hier also
end-to-end und vertikal.
Denn es bringt ja nicht viel, wenn nur vereinzelte Geschäftsprozesse durch Software-Tools unterstützt werden und dazwischen dann wieder viel manuell gearbeitet wird.
Die Einführung einer digitalisierten Kreditantragsstrecke mit anschließender manueller Einzelprüfung der Anträge führt in der Regel nicht zum gewünschten Erfolg. Eine stringent vertikale Digitalisierung der ganzen Geschäftsprozesskette, also vom Posteingang über die Kreditabteilung bis zur Kontoeröffnung durchläuft ja nicht nur viele Geschäftsprozesse, sondern auch viele und oft horizontal (also nebeneinander liegend) organisierten Abteilungen. Damit wird klar, dass sich eine digitale Transformation schnell quer durch die gesamte Organisation zieht und daher vom Unternehmensmanagement initiiert werden sollte.
Dabei ist die Digitalisierung einer Organisation selbst schon eine nicht gerade triviale Aufgabe, an der herkömmliche Methoden sehr schnell an ihre Grenze stoßen.
Schon die Beschreibung einer Applikation für die Automatisierung eines einzelnen Geschäftsprozesses ist für viele Business Analysten heute schon kaum noch machbar. Time-to-Market Anforderungen, also immer kürzer werdende Deadlines für die Lieferung bei gleichzeitig steigender Funktionalität und Komplexität von Softwaresystemen lassen heute realistisch nur noch agile Methoden wie z.B. Scrum für die Erstellung solcher Systeme zu.
Hinzu kommt dann noch, dass die einzelnen Prozesse der gesamten Geschäftsprozesskette auch noch präzise aufeinander abgestimmt werden müssen. An dieser Stelle und mit dieser Einsicht kommt dann eine agile Transformation ins Spiel. Dabei spielt es oft gar keine so große Rolle, ob eine Organisation die Digitalisierung wesentlich outsourcen will oder nicht.
WHITEPAPER
Wie plane und messe ich eine digitale Transformation?
Digitalisierung ist kein Selbstzweck und muss einem Controlling unterliegen.
Agiles Arbeiten erfordert eine grundlegend andere Herangehensweise.
Oft wird in der Literatur und in den Communities nur auf den iterativen Aspekt der Umsetzung von Digitalisierungsprojekten eingegangen. Aber diese Darstellung greift noch wesentlich zu kurz. Viel wesentlicher ist dabei meiner Meinung der Aspekt des Umgangs mit den Akteuren. Während klassische Methoden (z.B. Wasserfall) sich mehr mit Prozessen und Architekturen beschäftigen, fokussiert sich agile Methodik auf die Menschen und deren Interaktion.
Das ist auch absolut folgerichtig, denn zur allgemeinen Risikominimierung können wir uns nicht mehr auf die präzise Beschreibung von Prozessen und Architekturen verlassen.
Wegen des iterativen Ansatzes gibt es sie schlicht nicht mehr. Wir müssen uns daher viel mehr auf die Kompetenzen der unmittelbar beteiligten Akteure verlassen. Und bitte beachten Sie den Ausdruck „unmittelbar beteiligten“, denn dieser wird gleich dafür verantwortlich sein, warum eine agile Transformation einen Kulturwandel erfordert.
Es klingt ja fast wie Ironie, dass in der Ära der totalen Digitalisierung, die ja von vielen Kulturpessimisten als der Tod des Individuums, mindestens aber die Entmündigung des Menschen wahrgenommen wird, nun wie gerade beschrieben der Mensch mit seinen Fähigkeiten und Kompetenzen zum kritischen Erfolgsfaktor wird. Ja, ich gebe es zu, ich bin in der Tat auch eher ein Kulturoptimist und sehe in der Digitalisierung bzw. dann folgend der Virtualisierung unserer Realität mehr Chancen denn Katastrophen.
created by agile natives for agile natives
Die erste all-in-one scaled agile Projektmanagement Suite für SharePoint.
Immer mehr Unternehmen, freiwillig oder notgedrungen sich mit der Digitalisierung beschäftigen.
Tatsache ist, dass immer mehr Unternehmen, freiwillig oder notgedrungen sich mit der Digitalisierung beschäftigen.
Gleichzeitig und das ist kein Zufall werden dabei immer häufiger agile Methoden eingesetzt. Und es ist ebenfalls kein Zufall, dass in diesem Zuge auch mehr agile Projektmanagement bzw. Organisationsmanagement Methoden auf der Bildfläche erscheinen.
Die aktuell populärste – und ich verwende sie hier auch als Beispiel – ist sicher SAFe (scaled agile framework).Es vereint dabei konsequent Ideen aus dem ja schon viele Jahre existierenden „Lean Management“- Konzept (Kaizen & Co.) und agiler Methodik (ScrumX) und formt daraus ein agiles Management- und Organisations Framework.Auch der Begriff „Framework“ ist dabei mit Bedacht gewählt, denn Unternehmen sind heute derart komplex und ausdifferenziert, dass sehr dedizierte Konzepte mit sehr expliziten Templates (z.B. ITIL) nicht mehr so ohne weiteres adaptierbar sind.
Die Menschen in einer Organisation stehen hier jetzt wieder über den Prozessen und sind das höchste Gut.
Dieser Wandel beginnt zunächst mit einer notwendigen Dezentralisierung von Entscheidungen. Ich sagte oben, dass die Kompetenzen und Fähigkeiten der unmittelbar beteiligten Akteure zum entscheidenden Erfolgsfaktor werden und ebenso entscheidend zur Risikominimierung beitragen. Damit dies gelingen kann, müssen sie natürlich unmittelbar an den Entscheidungen beteiligt sein, bzw. sie selbst treffen dürfen. Mit Micromanagement ist da nichts zu machen.
Scrum Methoden
Exemplarisch können wir das an der Zusammensetzung eines Scrum Teams ablesen. Scrum Teams bilden auch die Basis im SAFe Framework. Scrum Teams bestehen aus einem Product Owner, einem Scrum Master und einem Entwicklungs-Team.
Nehmen Sie den Begriff „Entwicklungs-Team“ nicht zu ernst, die Scrum Methode lässt sich auch problemlos auf andere Branchen anwenden, es könnte ein Marketing-Team oder eine Baubrigade sein.
Wichtig ist, dass die Scrum-Methode von drei Rollen ausgeht. Während klassische Projektmethoden bzw. die Organisationen, die solche einsetzen, oft den ganzen Tag dabei sind, für jedes neue Problem eine neue Rolle zu erfinden (Implementierungsverantwortlicher, Compliance-Manager, Manager für gute Laune oder für’s Kaffeekochen, etc.), gibt es in Scrum nur drei Rollen, unabhängig vom Projekt, der Branche, der Technologie, der Größe, etc.
Auch sind in Scrum die Iterationen (Sprints oder darüberliegend PI’s in SAFe) reine Timeboxes, deren Länge fest definiert ist. Die Iteration ist zu Ende, wenn die Timebox abgelaufen ist.
Damit ist es genau umgekehrt wie in klassischen Methoden (z.B. Wasserfall), wo die Länge einer Phase (z.B. Spezifikationsphase, Implementierungsphase, Testphase) inhaltlich bestimmt ist und erst dann abgelaufen ist, wenn der Zweck erfüllt ist.
Agile in a day
Wir trainieren Ihr Team, coachen Ihre Stakeholder und führen Ihr Projekt zum Erfolg.
Die drei Rollen in Scrum
Die drei Rollen in Scrum haben für ihren jeweiligen Bereich Entscheidungshoheit. Leider wird gerade dies in vielen Organisationen, die von sich behaupten agil zu sein, gar nicht so gelebt und führt infolgedessen zu ziemlich großen Problemen. In skalierten Organisationen geht das weiter, Business Owner, Solution Owner etc. um in der SAFe Terminologie zu bleiben.
Da die Interaktion zwischen diesen nun dezentral entscheidenden Akteuren enorm an Wichtigkeit gewinnt, kann es nicht verwundern, dass hier sehr bald ein neues Kommunikationskonzept eingeführt werden muss. Kommunikation wird von uns oft als der „Austausch von Informationen“ wahrgenommen. Das ist zwar nicht falsch, führ uns hier aber nicht zum Erfolg. Denn es ist nicht weitreichend genug.
Wir fassen Kommunikation in diesem Kontext eher als „Wechselseitige Einladung in einanders Wirklichkeit zu kommen“.
Das klingt auch gleich viel schöner, geradezu romantisch. Es weist aber auf etwas sehr wesentliches in der Interaktion von „unmittelbar beteiligten“ Akteuren.
Selbstverständlich haben Product Owner, Scrum Master und Entwickler – um im Scrum Beispiel zu bleiben – eine sehr unterschiedliche Herkunft in der Organisation und eine sehr unterschiedliche Perspektive, vielleicht sogar unterschiedliche Interessen, kurz – sie leben in einer unterschiedlichen Wirklichkeit.
Die eine eher fachlich-funktional, die andere eher methodisch, die dritte wohl eher technische. Gemeinsam sollen sie und eigenverantwortlich und selbstorganisiert Wertschöpfung betreiben, unter enormen time-to–market Anforderungen und an unglaublich komplexen Gegenständen arbeitend. Mit dem bloßen Austausch von Informationen ist das nicht zu machen. Die Akteure brauchen heute viel mehr die Fähigkeit, Gegenstände aus mehreren Perspektiven gleichzeitig zu betrachten.
Als wäre das nicht schon Kulturwandel genug, dahinter wartet für Organisationen noch eine ganz andere Herausforderung, die gemanagt werden muss. Denn richtig zu Ende gedacht bringt diese Dezentralisierung von Entscheidungen unsere herkömmlichen und tief in unserer Sozialisierung verankerten Autoritätsmodelle durcheinander. Unsere Autoritäten sind aktuell noch entweder Wissensautorität (epistemische Autorität) oder Zuschreibungsautorität (deontische Autorität).
Im agilen Kontext haben die Akteure (z.B. Product Owner, Scrum Master, Entwickler) gleichzeitig Autorität und Verantwortung. Das ist weder rein epistemisch noch rein deontisch. Es ist eine Art teamorientierte Autorität (nicht Teamautorität). Vielleicht fällt Ihnen ja ein besserer Begriff ein, lassen Sie es mich wissen. Organisationen werden sich zum Höhepunkt der digitalen- und agilen Transformation und des bevorstehenden Kulturwandels auch mit der fundamentalen Veränderung unseres uralten Autoritätsmodells beschäftigen müssen.
Das muss uns jetzt keine Angst machen, denn darin liegt ein gewaltiges Entwicklungspotential für Unternehmen. Diese sitzen ja oft, ohne es zu wissen, auf einer Goldader von motivierten, innovativen und verantwortungsbewußten Mitarbeitern.
Diese anzuzapfen ist gleichermaßen Herausforderung und Riesenchance.
