Agil verändern: planen, anpacken und anpassen

AgileIn kaum einer IT-Abteilung ist Agile im Jahr 2017 noch ein Fremdwort und die meisten haben erste Erfahrungen mit agiler Software-Entwicklung gesammelt. Der Begriff Agilität ist dabei sehr weit gefasst und kann auch ein ganzes Spektrum an unterschiedlichen Vorgehensweisen und Geschwindigkeiten ausdrücken.

Geht es jenseits des punktuellen Einsatzes agiler Werkzeuge darum, agile Methoden die Scrum konsequent umzusetzen oder Releasezyklen erheblich zu beschleunigen, blicken größere Unternehmen in aller Regel erheblichen organisatorischen Umbrüchen ins Auge. Je größer das Unternehmen oder die vom Umbau betroffene Abteilung, desto komplexer die notwendigen Veränderungen. Stark verflochtene Matrix-Organisationen tun sich schwer besonders damit, einen notwendigen Wandel schnell und adäquat umzusetzen.

Anzeige

In aller Regel sind Reformen mit schwergewichtigen und langwierigen Prozesse verbunden, die Unternehmen auch wegen der hohen Kosten gerne vermeiden. Um Veränderungen besser zu beherrschen können, werden diese oft in kleinere Pakete fragmentiert. Allerdings folgt diese Zerteilung häufig der bestehenden Organisationsstruktur. Jede Abteilung verwaltet dann ihr eigenes, immer noch vergleichsweise groß angelegtes Veränderungsprojekt. Hier tritt bereits das erste Problem auf: Sind IT- und Fachabteilung disjunkt organisiert, zerschneiden die aufgeteilten Veränderungsprojekte möglicherweise abteilungsübergreifende Wertschöpfungsströme. Diese Teile leisten für sich genommen aber keinen Beitrag zur Wertschöpfung. So zum Beispiel eine Entwicklungsabteilung, die einerseits auf Anforderungen aus der Fachabteilung und andererseits die Unterstützung aus dem Betrieb angewiesen ist, um einen Geschäftswert zu erzeugen. Die nur lose zusammengehaltenen Veränderungsmaßnahmen drohen dann den Bezug zueinander zu verlieren und divergieren. Im schlimmsten Fall laufen Fach- und IT-Abteilung in unterschiedliche Richtungen, weil das übergeordnete Ziel der Veränderung nicht ausreichend im Mittelpunkt der Maßnahmen verankert ist.

Am Anfang steht die Definition einer Vision

Am Anfang sollte deshalb immer die Definition einer Vision stehen, welche die Richtung der Veränderung klar formuliert. Im Falle von Agilität wäre es allerdings ein grober Fehler, konkrete Methoden oder Vorgehensweisen in den Mittelpunkt der Zielsetzung zu stellen. Vielmehr muss sich der Erfolg der Veränderung an den übergeordneten Unternehmenszielen messen lassen. Agil zu sein ist dabei nur ein möglicher Weg zu diesem Ziel. Agilität per se bildet allerdings noch keinen eigenständigen Mehrwert für eine Organisation. Das sollte bei der Formulierung der Vision berücksichtigt werden. Hilfreich ist dazu die klare Benennung der Treiber der Veränderung. Das kann beispielsweise eine kürzere Time to Market aber auch eine bessere Rückkopplung mit dem Kunden oder Endanwender während der Produktentwicklung sein.

Steht die Vision einmal, lassen sich auch die Teilschritte der Veränderung grob definieren. Wichtig ist dabei, dass sich partielle Veränderungen auf vollständige Wertströme beziehen. Anstatt die IT-Abteilung in ihrer Gesamtheit umzubauen, könnten einzelne Produkte jeweils der Aufhänger für Veränderungsmaßnahmen sein, die dann ausschließlich für die daran direkt beteiligten Unternehmenseinheiten bis auf die Ebene einzelner Mitarbeiter gelten. Diese überwinden damit zwar auch Abteilungsgrenzen, bleiben aber dennoch kleinteilig und beherrschbar.

Dann folgt die Aufteilung in einzelne Schritte

Einmal identifiziert lassen sich die Veränderungsschritte entsprechend ihrer Priorität und Abhängigkeit in eine Reihenfolge bringen. Ein Produkt in einem besonders umkämpften Markt könnte also Vorrang vor einer internen Anwendung mit geringem Veränderungsdruck bekommen. Daraus ergibt sich ein Backlog, das schrittweise abgearbeitet werden kann. Einer Analogie zu Scrum folgend ist aber das Backlog weder bis ins letzte Detail ausdefiniert noch eine abschließende Sammlung von Maßnahmen. Es gibt vielmehr einen groben Überblick über die aktuell bekannten Veränderungsbedarfe, die alle im direkten Bezug zur Vision stehen. Die Bedarfe mit der höchsten Priorität sind so detailliert beschrieben, dass die Reform direkt starten kann.

Erfolgsfaktoren für Inhalte eines Veränderungs-Backlogs

Bild 1: Erfolgsfaktoren für Inhalte eines Veränderungs-Backlogs

Newsletter
Newsletter Box

Mit Klick auf den Button "Jetzt Anmelden" stimme ich der Datenschutzerklärung zu.

Wie wird mein schwerfälliger Tanker agiler? Fünf Schritte:

Zum Thema agile Veränderungen gibt es verschiedene theoretische Betrachtungen. Leider fehlen häufig die konkreten Ansätze, um erste Erfolge zu erzielen. Ein wichtiger Erfolgsfaktor ist es, nicht zu lange im Planungsmodus zu verharren. Erst in der Umsetzung werden Chancen und Herausforderungen wirklich sichtbar. Das gilt für die Software-Entwicklung genauso wie für den Veränderungsprozess. Besteht beispielsweise die Vision, Produktentwicklungszyklen zu verkürzen, könnte im nächsten Schritt eine Pilotierung für ein konkretes Produkt erfolgen. Die Veränderungsmaßnahme beschränkt sich auf dieses Produkt, wird dabei aber konsequent auch über Abteilungsgrenzen hinweg umgesetzt. Inhalt einer solchen Veränderung könnte beispielsweise die Einführung von Scrum in der Software-Entwicklung sein.

  1. Einer der möglichen Wege zur Lösung beginnt dabei mit der Entflechtung bestehender Strukturen. Die direkt an der produktbezogenen Wertschöpfung beteiligten Mitarbeiter müssen dabei aus ihren Organisationseinheiten herausgelöst werden. Insbesondere die konsequente Befreiung von Nebenaufgaben und Parallelprojekten ist an dieser Stelle ein entscheidender Erfolgsfaktor. Entstehen sollte eine weitestgehend unabhängige, schlagkräftige Einheit, die den Beitrag zur Wertschöpfung des Produkts maximal unabhängig erbringen kann.
  2. Für die inhaltliche Führung dieser neu entstandenen Einheit ist ein Product Owner erforderlich. Dieser muss schnell entscheidungsfähig sein und einen klaren Blick auf die Geschäftsseite haben. Für diese Rolle disqualifizieren sich Product-Owner-Gremien und auch reine Anforderungsmanager, die kein Mandat für eigenständige Entscheidungen haben oder zu weit vom Markt beziehungsweise den Anwendern entfernt agieren.
  3. Die neu geschaffene Einheit ist selbstverständlich nach wie vor auf einige Querschnittsbereiche des Unternehmens angewiesen, die nicht zu ihrem Wertschöpfungsauftrag gehören. Dazu sollten Schnittstellen gebildet werden, die möglichst schlank sind. Wichtig ist, dass an diesen Knotenpunkten kein Bruch des Wertstroms erfolgt, weil beispielsweise mehrere Unternehmenseinheiten ihre Infrastruktur über eine zentrale Unternehmenseinheit verwalten lassen und es dadurch zu Verzögerungen kommt. Die Personal- und die Finanzabteilung dagegen sind als Schnittstelle unkritisch, da sie die Produktentwicklung nicht unmittelbar beeinflussen.
  4. Ein neues und pilotiertes Vorgehen muss sich stets auch innerhalb der Organisation beweisen. Umso wichtiger ist Transparenz über die Erfolge des neuen Vorgehens. Natürlich sollten Lernerfahrungen und Rückschläge nicht verschwiegen werden. Doch für breite Akzeptanz des nächsten Schrittes der Veränderung ist es wichtig, insbesondere die tatsächlich erreichten Verbesserungen in Bezug auf die Vision zu thematisieren.
  5. Im nächsten Schritt kann das Vorgehen skalieren. Dabei ist es von zentraler Bedeutung, die Erfahrungen der Kollegen aus der Pilotierung zu übertragen. Sie sind ungemein wertvoll für die Effizienz des weiteren Veränderungsprozesses.

Mögliche Schritte für eine Agilisierung

Bild 2: Mögliche Schritte für eine Agilisierung

Veränderungen neu denken

Der zentrale Mehrwert agiler Methoden ist das frühe Feedback. Übertragen wir diese Erkenntnis auf Reformen im Kontext von Organisationen, so müssen wir umdenken: Veränderungen dürfen nicht länger einem festen Plan folgen, um einen detailliert vordefinierten und bekannten Sollzustand erreichen. Vielmehr sollten sie in sinnvolle und in sich geschlossene Zwischenschritte zerlegt und ständig auf ihren Mehrwert hin überprüft werden. Denn Veränderung ist kein Selbstzweck. Nur wenn sie auf ein übergeordnetes Ziel einzahlt, ist sie sinnvoll. Je früher und je häufiger der Abgleich mit dem eigentlichen Ziel der Veränderung gelingt, desto erfolgreicher werden auch Experimente und Pilotierungen neuer Arbeitsweisen. So bleiben auch größere Organisationen handlungsfähig, um sich bei Bedarf neu auszurichten und auch jenseits von der Umsetzung in der IT agil zu agieren.

Maximilian Frei, CapgeminiMaximilian Frei, Capgemini

www.de.capgemini.com

 

 

Anzeige

Weitere Artikel

Newsletter
Newsletter Box

Mit Klick auf den Button "Jetzt Anmelden" stimme ich der Datenschutzerklärung zu.