Foto: Berk Ozel - shutterstock.com
Je intensiver Unternehmen die Digitalisierung vorantreiben wollen, desto mehr geraten ihre IT-Organisationen unter Druck, flexibler und schneller zu werden sowie Services in standardisierter und automatisierter Form zur Verfügung zu stellen. Dabei ist es unerheblich, ob diese Dienste für interne oder externe Kunden erbracht werden. Die Verwendung von State-of-the-Art-Technologien wie Cloud Computing verkürzt die Innovationszyklen und erhöht die Veränderungsgeschwindigkeit. Daneben wird versucht so innovativ wie möglich zu sein.
Durch agiles Arbeiten werden eine hohe Flexibilität und kurze Time-to-Market-Zyklen erreicht. Dabei lässt sich durchaus ein stabiler Betrieb aufrechterhalten. IT-Organisationen stellen also im großen Stil auf agile Arbeitsweisen um, haben dabei aber - so zeigen diverse Studien - oft noch keinen besonders hohen Reifegrad erreicht. Vor allem in Bezug auf Organisation, Prozesse und Mindsets bleiben noch viele Potenziale ungenutzt.
Es stellt sich also die Frage, warum Unternehmen sich schwer tun, die geeigneten Rahmenbedingungen zu schaffen. Tatsächlich fehlt es vielen agilen Transformationsprojekten an klaren Konzepten, nicht immer ziehen alle an einem Strang. Agilität ist keine Methodik, die eingeführt werden kann, und ein agiles Framework allein wird einem Unternehmen nur begrenzt zu mehr Agilität verhelfen.
Illustriert werden kann das am Beispiel der Scrum-Methode. Die Annahme ist falsch, dass sich eine agile IT-Organisation bereits dadurch schaffen lässt, indem eine neue Meeting-Struktur eingeführt und das Abarbeiten sämtlicher Aufgaben in diesem Modus verordnet wird. Scrum löst viele Probleme, schafft aber auch neue. Der Ansatz ist relativ vage und unspezifisch, das heißt es besteht viel Interpretationsspielraum, der dann in der Umsetzung zu neuen Problemen führt. Eine Eins-zu-Eins-Adaption des Frameworks ist weder ratsam noch besonders erfolgsversprechend.
Es sei jedoch darauf hingewiesen, dass nicht Scrum selbst das Problem ist. Im Gegenteil: Es handelt sich um ein effizientes Framework, das sehr wertvoll sein kann. Problematisch sind die unterschiedlichen Auffassungen darüber, wie Scrum in der Praxis angewendet werden soll. Gibt es hier keinen Konsens, können sich Mitarbeiter gegenseitig blockieren.
Ferner werden bei der Einführung von Ansätzen wie Scrum oft Prozesse der aktuellen Arbeitswelt, die mitunter einen großen Einfluss auf den Unternehmenserfolg haben, nicht berücksichtigt. Insofern fehlt den "Agile-Experten" teilweise das Gesamtbild, oft auch das notwendige Fachwissen.
In vielen Unternehmen führt das dazu, dass sich die agilen Arbeitsweisen in den einzelnen Abteilungen und Teams voneinander unterscheiden, obwohl dasselbe Framework genutzt wird. Oft arbeiten dann die IT-Organisationen gar nicht agil, und die Entwicklung in diese Richtung wird zudem massiv behindert.
Der agile Kulturwandel und die einhergehenden Probleme
Tiefgreifende Veränderungen wie eine völlig neue Arbeitsweise lösen bei vielen Menschen Unsicherheit aus. Die Folge sind Diskussionen und Hahnenkämpfe, ausgelöst durch neue Regeln und Vorgehensmodelle. Schon bald fehlen den Mitarbeitern allgemeingültige Rahmenbedingungen, manchmal auch das gegenseitige Verständnis.
Wichtig ist daher eine agile Governance, die ergänzend zu den eingesetzten Frameworks den Weg des Wandels vorgibt und Transparenz schafft. Sie hilft, das individuelle Mindset der beteiligten Personen positiv zu beeinflussen. Es geht dabei keineswegs um Manipulation, sondern darum, Mitarbeitern Orientierung und eine stabile Grundlage zu geben.
Das IT-Service-Management (ITSM) beziehungsweise das Service-Ökosystem insgesamt ist die zweite große Baustelle. Meistens gibt es hier zu wenig fachliches Know-how im Kontext von Prozessen, dafür aber einen überproportional hohen Anteil an "Framework-Wissen". Letzteres wird in den IT-Abteilungen meist intensiv gecoacht. Dadurch geraten dann oft die Frameworks selbst in den Mittelpunkt, weniger die Themen, für deren Bearbeitung diese Frameworks benötigt werden.
Für die agile Entwicklung innovativer Services müssten Rahmenbedingungen geschaffen werden, beispielsweise im Sinne einer Software-Produktionsstraße. Entsprechende Service-Management-Prozesse müssten implementiert sein und der Informationsfluss sollte weitestgehend automatisiert werden, um die Arbeitsabläufe so effizient wie möglich zu gestalten. Ein agiles Release-Management kann dabei helfen, Services schnell liefern zu können.
Insofern muss auch definiert sein, wie die Anforderungen von Kunden ins Projekt-Portfolio-Management gelangen und im weiteren Verlauf entwickelt und schließlich geliefert werden. Eine Überwachung des (Projekt-)Portfolios als solches, sprich: der Kundenanforderungen genauso wie der Nutzung von Services sowie deren Verrechnung und Kostenstruktur, sollten ebenfalls erfolgen. So können Trends abgeleitet werden, und es lässt sich flexibel und schnell auf Veränderungen eingehen.
Agile IT-Organisation orientiert sich an den Kundenanforderungen
Kommen wir nun dazu, wann eine IT-Organisation als agil angesehen werden kann und wie eine agile IT-Organisation aussehen könnte. Die digitale Transformation macht Veränderungen auf personeller, kultureller, organisatorischer, prozessualer und technologischer Ebene erforderlich, um die künftigen Aufgabenstellungen bewerkstelligen zu können. Das betrifft auch die Agilität.
Eine agile IT-Organisation wird sich an den Anforderungen der Kunden (extern und intern) orientieren und setzt die Zusammenarbeit mit ihnen voraus. Sie ist in der Lage, in einer Eigendynamik auf Veränderungen einzugehen und sich zu wandeln. Ebenso ist sie Teil eines innovativen Ökosystems und treibt die Modernisierung eines Unternehmens aktiv voran.
Sämtliche Teams agieren im Rahmen definierter Value-Streams. Sie verfügen über digitales Know-how, sind motiviert, flexibel und schnell. Trends wie Cloud Computing, Big Data, Internet of Things (IoT) etc. werden ausprobiert, verstanden und eingesetzt. Agile IT-Organisationen entwickeln digitale Innovationen und neue Geschäftsmodelle in kurzen Zyklen beziehungsweise Iterationen und stellen sie in automatisierter und standardisierter Form zur Verfügung.
Das Paradigma der Stunde ist "Innovate - Design - Transform", wobei der Fokus auf neuen Aufgabenstellungen liegt. Organisatorische Strukturen, die dies unterstützen, sind etabliert. Motivierende und kooperative Führungsstile spielen eine zentrale Rolle. Mitarbeiter erhalten viele Freiheiten und viel Verantwortung. Dieser Stil ist leistungsfördernd, außerdem können so komplexe Themen besser bearbeitet werden.
Typische Leitbilder lauten "Wir tun das jetzt einfach" oder "Alles was wir heute falsch gemacht haben, machen wir morgen besser". Sämtliche Prozesse wurden neu durchdacht und angepasst. Diverse Methoden, Modelle und Tools, zum Beispiel Design Thinking, Prototyping, Scrum und Collaboration-Lösungen sind dazu da, die tägliche Arbeit zu unterstützen. So entstehen eine neue Arbeitswelt und Kultur.
Der Umbau der IT-Organisation benötigt eine Strategie
Diese Aspekte verdeutlichen, warum sich IT-Organisationen agil aufstellen müssen. Mehr als zwei Drittel der IT-Abteilungen sind aber empirischen Studien zufolge noch nicht entsprechend positioniert, und oft liegt auch keine Strategie für einen solchen Umbau vor. Hier sollten Führungskräfte als Initiatoren vorangehen, da sich die Mitarbeitenden in der Regel am organisationalen Mindset orientieren.
CIOs, CDOs, IT-Organisationen und das mittlere Management generell sollten aufhören, über die Notwendigkeit von Agilität zu diskutieren und sich stattdessen auf hoher Führungsebene klar positionieren. Um den Wechsel von der klassischen zur agilen IT-Organisation zu gestalten, muss das Thema ganzheitlich betrachtet werden, einschließlich möglicher Konsequenzen. Das schließt das Erarbeiten einer Strategie, eines Target-Operations-Model (kurz: TOM), einer agilen Governance und der Schaffung eines übergreifenden Agile- und Transformation-Teams mit ein.
Allein mit Agile-Evangelisten auszukommen, ist indes unmöglich. Also gilt es, weitere Mitarbeiter mit Leadership-Qualitäten und einem umfassenden Verständnis bezüglich des Service-Ökosystems zu integrieren. Das gesamte Team muss so zusammengestellt sein, dass es in der Lage ist, sich in die nahezu täglich veränderten Aufgabenstellungen einzuarbeiten und Lösungsansätze zu liefern. Das bedeutet zugleich, dass sich die verantwortlichen Kolleginnen und Kollegen ganz im Sinne der Agilität selbst führen und steuern können sollten.
Daneben muss das Betriebsmodell, das gegebenenfalls einen bimodalen Ansatz für die Übergangszeit umfasst, von den Teams verstanden werden. Ein agiles Framework kann als Unterstützung dienen. Relativ zügig sollten alle Prozesse und Abläufe, die der Agilität im Wege stehen - zum Beispiel der Release-Management-Prozess oder auch viele klassischen Arbeitsabläufe - überprüft, angepasst oder neu designt werden.
Mögliche Effekte, die sich daraus ergeben, werden, basierend auf einem typischen Ablauf der Service-Entwicklung, in der nachfolgenden Abbildung verdeutlicht. Aus Gründen der Übersicht wurde eine vereinfachte Darstellung gewählt, es werden also nicht alle möglichen Workflows, Schnittstellen, DevOps-Ansätze oder ähnliches aufgezeigt sowie beschrieben.
Foto: Daniel Taradzic
Aus der Abbildung lassen sich weitreichende Veränderungen in der IT-Organisation ableiten. Die agile Governance gibt die Rahmenbedingen vor. Das ITSM-Tool ist die zentrale Plattform und dient als Basis für sämtliche Aktivitäten. Dort werden die Aktionen aus dem Requirements-, Release-, IT-(Projekt-), Portfolio-Management sowie die Bereitstellung der Services für die Kunden und den Betrieb gebündelt. Es ist möglich und notwendig auf andere Tools zuzugreifen, zum Beispiel auf Entwicklungsumgebungen oder Collaboration-Tools.
Mitarbeiter brauchen Möglichkeit, Ideen zu formulieren
Der Markt und der Kunde stehen im Mittelpunkt. Demnach müssen Marktentwicklungen, also Innovationen und Trends, betrachtet werden. Die Requirements sämtlicher Kunden werden erfasst und auf einer High-Level- oder einer technischen Ebene beschrieben. Ergänzend dazu muss sichergestellt sein, dass alle Mitarbeiter einer Organisation die Möglichkeit bekommen, Ideen zu formulieren. Im Idealfall erfolgt dies mit Bezug zum Anwender. Auch der innovativste Service kann nicht erfolgreich sein, wenn es keinen Kunden dafür gibt.
Das Anforderungs-Management wird neu konzipiert. Mittels Workflow können beispielsweise die Anforderungen zur Vorabprüfung direkt den zuständigen Teams zugewiesen werden. Im Anschluss werden Requirements, die nicht abgelehnt wurden, im Innovation-Board gemeinsam bewertet und gegebenenfalls für die Entwicklung freigegeben. Dafür sollten Kriterien definiert werden, da auch die Agilität spätestens bei Budgets, sicherheitsrelevanten Aspekten und manchmal auch subjektiven Einschätzungen an ihre Grenzen stößt.
Die Treffen der Innovation-Boards sind an die jeweilige Sprintdauer anzupassen beziehungsweise es muss sichergestellt werden, dass immer ausreichend Themen für die Sprints aller Teams vorhanden sind. Sofern dies erfolgt ist, sind sämtliche Requirements im Backlog des Teams wiederzufinden. Im Rahmen der Sprint-Planung wird dann priorisiert und die Aufwände werden beispielsweise mithilfe des Planungspokers geschätzt.
Es sei noch erwähnt, dass im Kontext der agilen Zusammenarbeit verschiedene Ansätze der Aufwandsschätzung zur Verfügung stehen. Je erfahrener die Teams sind, desto besser werden die Ergebnisse ihrer Schätzungen. Im Anschluss an die Aufwandsschätzung erfolgt die Entwicklung der Services, bis diese fertig und releasefähig sind. Damit die agilen Teams nicht blockiert werden, sollten so viele Prozesse und Workflows etc. wie möglich automatisiert werden.
Das betrifft auch die Bereitstellung von Entwicklungsumgebung, Testsystemen und Testdaten. So kommt es in der Software-Entwicklung nicht zu Verzögerungen und der Service gelangt schnell in den agilen Release-Management-Prozess. Dessen Laufzeiten betragen für den Release-Typen 'Minor' ein bis zwei Tage, für 'Major' ein bis vier Tage, für 'Hotfix' sechs bis 24 Stunden und für 'Emergency' ein bis sechs Stunden. Eine genaue Definition aller Change-Aktivitäten muss erfolgen, kann an dieser Stelle allerdings nicht explizit beschrieben werden. Nach Release-Freigabe kann der Service in der Produktion deployed werden. Im Anschluss befindet sich das digitale Produkt in der Verantwortung des Betriebs und wurde dem Kunden bestenfalls bereits automatisiert bereitgestellt.
Wann eine IT-Organisation agil ist
Auf Basis der Ausführungen in diesem Artikel sollten folgende Kriterien erfüllt sein, damit eine Organisation als agil betrachtet werden kann:
Es existiert ein TOM und eine agile Governance, die organisationsweit gültig ist und regelmäßig überprüft und gegebenenfalls angepasst wird.
Alle Mitarbeiter verfügen über ausreichende agile Kompetenzen und sind für die Arbeitsweise mitverantwortlich.
Alle sind gemeinsam für die definierten Ziele verantwortlich, das heißt für alle Aufgaben und Ergebnisse sämtlicher Iterationen.
Die Mitarbeiter dürfen Risiken eingehen und im Team schnelle Entscheidungen herbeiführen.
Sie sind dafür verantwortlich, dass Anforderungen von Kunden erfasst, verstanden und berücksichtigt werden.
Experimente sind erwünscht, mögliches Scheitern wird akzeptiert und in Kauf genommen.
Alle Mitarbeiter dürfen Fehler machen, doch sie sind dafür verantwortlich, daraus zu lernen.
Transparenz und demokratische Entscheidungen im Team werden eingefordert und gefördert.
Die Zusammenarbeit im Team wird unterstützt, die Kompetenzen diesbezüglich werden kontinuierlich weiterentwickelt.
Es wird zu jeder Zeit offen und ehrlich über Problemstellungen diskutiert.
Ergänzend dazu ist es ein guter Ansatz, ITSM-Prozesse und Wertströme mittels TOM zu überprüfen und zu bewerten, was die Agilität bremst. Nachfolgend die vereinfachte Darstellung eines TOM und ein Beispiel, wie es zur Prüfung der Agilität eingesetzt werden kann.
Foto: Daniel Taradzic
Für einen Kunden soll ein innovatives digitales Produkt entwickelt werden. Die Requirements und das Solution Design liegen bereits vor. Es können unter Zuhilfenahme des Modells alle erforderlichen Services, Prozesse und beteiligte Personen identifiziert werden. Im Rahmen der Betrachtung dieses Gesamtbilds lassen sich Schwachstellen identifizieren.
Beispielweise könnten das Release-Management oder der derzeitige Security-Prozess Probleme im Kontext der agilen Arbeitsweise verursachen. Zum einen könnte das derzeitige Release-Management die schnelle Verfügbarkeit eines Service blockieren. Zum anderen könnten manuelle Prozesse im Kontext Security die Entwicklung massiv behindern.
Insofern müssten diese Prozesse überprüft und angepasst werden. Andernfalls kann ein Großteil der eingesetzten Frameworks die erhofften Wirkungen nicht erzielen. Diese Aufgabenstellung eignet sich hervorragend dazu, um sie mit agilen Teams durchzuführen. Die Ergebnisse schaffen Transparenz und es wird ersichtlich, was die Abläufe stört und wieso Verbesserungen erfolgen müssen.
Fazit
Die beschriebenen Ansätze lassen sich in der Praxis gut implementieren. Die größten Herausforderungen einer IT-Organisation im Kontext der Agilität sind die verschiedenen Interpretationen von Agilität, die Anpassung unternehmensspezifischer Prozesse und Abläufe sowie die Schärfung des organisationalen und individuellen Mindsets. Das Aufsetzen einer Governance sowie eines übergreifenden Agile- und Transformation- Teams ist unabdingbar. So schaffen Unternehmen agile Rahmenbedingen und treiben den Wandel insgesamt voran.
Fakt ist, dass Agilität die Voraussetzung ist, um den neuen Anforderungen im Kontext der Digitalisierung gerecht zu werden. Die zunehmende Veränderungsgeschwindigkeit, kürzere Innovationszyklen etc. verlangen eine agile Arbeitsweise. Eine bimodale IT kann maximal ein Zwischenschritt auf dem Weg der vollständigen Transformation sein. Spätestens im Anschluss daran werden die klassische Arbeitsweise und veraltete Technologien ausgedient haben sowie verschwunden sein.
Alles in allem bleibt CIOs, CDOs, dem mittleren Management, Projektleitern und Mitarbeitern nichts anderes übrig, als sich auf eine agile Arbeitsweise einzulassen. Dieser Kulturwandel muss vorangetrieben werden - andernfalls fällt es schwer daran zu glauben, dass eine IT-Organisation zukünftig noch wettbewerbsfähig sein kann.