Agilität ist in Großunternehmen angekommen

Der Widerspenstigen Zähmung: Agilität in Großunternehmen
Keine Kommentare

Die Vorgehensweise, Software zu entwickeln, zu betreiben und zu nutzen, verändert sich in den Betrieben grundlegend. Ideen, die noch vor wenigen Jahren Start-ups vorbehalten waren, halten mittlerweile Einzug in etablierte Großunternehmen. Um Software immer schneller produzieren zu können, müssen nicht nur die Organisation eines Betriebs, sondern auch die Systeme verändert werden.

Ist Schnelligkeit inzwischen das oberste Gebot für IT-Abteilungen? Oder ist Planungssicherheit weiterhin unverzichtbar, wenn Unternehmen neue Software entwickeln wollen? Sollen Entwickler den Funktionsumfang Schritt für Schritt während des Projekts erarbeiten, damit sie exakt passende Lösungen programmieren? Oder sollen sie genauen Spezifikationen folgen, damit alle Beteiligten von Anfang an wissen, was am Ende herauskommt? Der Blick auf agile und klassische Methoden der Softwareentwicklung offenbart viel Schwarz-Weiß-Denken in Unternehmen. Dabei liegt die Wahrheit auch in diesem Fall in der Mitte. Denn mit planorientierten Modellen, die auf der Annahme basieren, dass Spezifikationen weitgehend vollständig sind und die Projektverantwortlichen späte Anforderungen vermeiden sollten, werden Unternehmen kaum den schnellen Innovationstakt mitgehen können, den Start-ups mit ihren Angeboten inzwischen vorgeben. Auf der anderen Seite steht die agile Lehre in Reinkultur, der zumindest der Ruf vorauseilt, auf viele Projektstandards, wie eine saubere Dokumentation, gleich ganz verzichten zu wollen. Sie wird die Anforderungen des Managements an Liefertermin, Minimalfunktionalitäten oder Budgetplanungen nicht hundertprozentig erfüllen können.

Es gilt, die Vorteile der agilen Softwareentwicklung mit planerischer Sicherheit zu kombinieren. Unternehmen müssen Agilität zähmen, dann entfaltet sie ihre volle Wirkung. Den Entscheidern in Unternehmen steht dafür eine ganze Reihe von Instrumenten und Konzepten zur Verfügung. Die wichtigsten davon werden hier vorgestellt. Will das Management Agilität in den eigenen Reihen etablieren, kann es daraus die passenden Maßnahmen auswählen.

Das rechte Maß der Agilität

Wie das richtige Verhältnis von Planung und Flexibilität aussieht, ist von mehreren Faktoren abhängig. Selbst bei vergleichbaren Unternehmen – ähnliche Branche, ähnliche Anwendungslandschaften, ähnliche Vertriebswege, ähnliche Produkte – kann dieser Punkt auf unterschiedlichen Stellen der Skala liegen. Entscheidend ist die persönliche Einstellung wichtiger Projektbeteiligter zu dem Thema: Je agil-affiner sie sind, desto größer der agile Anteil in der Projektarbeit. Indikatoren sind auch die Größe des Projekts, seine Bedeutung, die Dynamik des Umfelds, die Unternehmenskultur und das Branchen-Know-how der Entwicklungsmannschaft.

Zunehmende Größe (von Projekt und Organisation), hoher Bedeutungsgrad der Anwendung und Klarheit der Anforderungen verschieben das optimale Verhältnis tendenziell in Richtung plangetriebener Verfahren. Darüber hinaus dürfen die Entscheider zwei weitere Faktoren nicht außer Acht lassen: Das sind der Zustand der Anwendungslandschaft und die Frage, ob ein anstehendes Projekt mit großer Wahrscheinlichkeit zu strukturellen Veränderungen der Anwendungslandschaft führt.

Die Suche nach dem optimalen Verhältnis von Planung zu Agilität kann zeitaufwändig und nervenaufreibend sein. Geeignete Werkzeuge und Konzepte können diese Suche abkürzen. Neben DevOps und Continuous Integration beziehungsweise Continuous Delivery bietet sich hier der Interaction Room als Konzept an.

Ein Raum mit grenzenlosen Möglichkeiten

Der Interaction Room ist ein Medium, über das Fach- und IT-Experten besser miteinander kommunizieren können. Das gelingt durch die offene, nicht IT-fixierte Darstellung von Prozessen. Sie erlaubt es auch den Vertretern aus den Fachabteilungen, sich in die Diskussionen einzubringen. Abbildung 1 zeigt ein Beispiel für so eine Art der Prozessbeschreibung. Im Interaction Room können Teams auch komplexe Prozesse mit einfachen Mitteln beschreiben und bewerten. Unternehmen können den Interaction Room grundsätzlich unabhängig von einem konkreten Vorgehensmodell einsetzen.

Abb. 1: Prozessbeschreibung (Quelle: adesso AG)

Abb. 1: Prozessbeschreibung (Quelle: adesso AG)

Agilität geht über Abteilungsgrenzen hinaus

Agilität fängt nicht erst hinter der Tür zur IT-Abteilung an, ganz im Gegenteil: Wenn Unternehmen neue Software für wettbewerbskritische Geschäftsprozesse entwickeln wollen, gleichgültig ob mit der unternehmensinternen IT oder mit externen Lieferanten, treffen Expertengruppen aus IT und Business aufeinander. Dies bedeutet nicht nur, dass sich hier unterschiedliches Fachwissen gegenübersteht; unterschiedliche Ziele, Arbeitsweisen und Vorstellungswelten erschweren häufig die Zusammenarbeit.

Der Interaction Room ist ein echter begehbarer Raum mit vier Wänden. Diese Wände haben tragende Funktionen: Auf ihnen visualisieren die Projektmitarbeiter Prozesse und stellen Projektdetails dar, hier können sie Probleme auf einen Blick erkennen. Im Interaction Room arbeitet ein interdisziplinäres Team aus Fach- und IT-Experten unter der Anleitung eines Moderators zusammen. Gemeinsam ermitteln sie in Abstimmungsrunden Lösungen für die zentralen Themen und Fragestellungen eines Projekts. Visualisiert wird dies durch die Zuordnung von Symbolen zu einzelnen Aspekten des Projekts. Mithilfe der Wertannotationen ergänzen die Beteiligten die erarbeiteten Modelle um weitere Informationen (Abb. 2).

Der Interaction Room ist eine Methode, die das Interesse auf den Projektfortschritt lenkt und dazu beiträgt, dass die Vision von der zu entwickelnden Software kontinuierlich und durch alle Beteiligten gemeinsam weiterentwickelt wird.

Abb. 2: Wertannotationen (Quelle: adesso AG)

Abb. 2: Wertannotationen (Quelle: adesso AG)

Damit das Team im Interaction Room die gewünschten Ergebnisse erzielt, sind einige Voraussetzungen zu beachten: Die vier Wände repräsentieren jeweils einen zentralen Aspekt des Projekts. Eine Wand wird mit den Modellen der Geschäftsprozesse beschriftet, die das zu erstellende Softwaresystem unterstützen soll (die so genannte Prozesswand). Die zweite Wand dient zum Notieren fachlicher Objektmodelle (Objektwand). Die dritte nutzt das Team, um den Backlog zu notieren und den Projektfortschritt zu protokollieren (Statuswand). Auf der vierten Wand bilden sie die Integrationslandkarte ab (Integrationswand). Diese Landkarte gibt Auskunft darüber, welche existierenden Softwaresysteme mit dem zu erstellenden System integriert werden müssen. Damit die Projektmitglieder im Interaction Room problemlos zusammenarbeiten können, müssen sich alle Beteiligten im Vorfeld über einige Grundsätze im Klaren sein.

Abstraktion: Wände sind, im Gegensatz zu elektronischen Dokumenten, endlich. Dies zwingt die Beteiligten dazu, sich auf das Wesentliche zu konzentrieren – ein gewollter Effekt der Arbeit im Interaction Room. So hat es sich in der Praxis bewährt, auf der Prozesswand nicht mehr als fünfzehn Prozessmodelle mit jeweils maximal fünfzehn Aktivitäten zu notieren. Details, die unnötig Ressourcen binden, werden ausgeblendet.

Wertorientierung: Eine entscheidende Frage für den Projekterfolg ist, wie die Projektmitarbeiter die wesentlichen und kritischen Teile eines zu erstellenden Softwaresystems identifizieren. In der Praxis gibt es eine Tendenz dazu, einfachen Zusammenhängen, die alle schnell verstehen, zu viel Zeit und Ressourcen zu widmen. Während alle gemeinsam die Personenstammdaten detailliert modellieren, schenken sie zentralen Geschäftsprozessen zu wenig Aufmerksamkeit. Die Antwort des Interaction Rooms auf dieses Thema ist die so genannte „Wertannotation“ von Prozess- und Objektmodellen. Abbildung 3 zeigt eine Auswahl der Symbole, die in verschiedenen Durchgängen von den Beteiligten an die Aktivitäten der Prozessmodelle geklebt werden. Development und Operations folgen zwar unterschiedlichen Leitlinien, müssen aber eng zusammenarbeiten.

Abb. 3: Das Spannungsverhältnis zwischen Entwicklung und Betrieb (Quelle: adesso AG)

Abb. 3: Das Spannungsverhältnis zwischen Entwicklung und Betrieb (Quelle: adesso AG)

Inkonsistenz: Ein unternehmensweit bedeutsames Projekt darf nicht zu einer IT-dominierten Veranstaltung geraten, in der der Beitrag aus den Fachbereichen unterrepräsentiert wird. Damit sich alle Beteiligten auf fachliche Inhalte konzentrieren, gibt der Interaction Room bei der Beschreibung der Prozessmodelle – ein Thema, bei dem IT-Experten häufig einen Know-how-Vorsprung haben – keine Syntax vor. Was immer den Beteiligten sinnvoll erscheint, wird in Abstimmung mit dem Interaction-Room-Moderator genutzt. Mögliche syntaktische Ungereimtheiten werden dabei in Kauf genommen.

Ungewissheit: In den frühen Phasen der Softwareentwicklung sind nicht alle fachlichen Zusammenhänge gleichermaßen klar, über einige Themen diskutiert das Team womöglich kontrovers. Damit die Beteiligten erkennen, welche Zusammenhänge sie noch nicht tief genug durchdrungen haben, müssen alle Teilnehmer des Interaction Rooms nach der einleitenden Diskussion die für sie kritischen Themen mit einem „Ungewissheitssymbol“ kennzeichnen. Auf diese Weise ermitteln sie, in welchen Bereichen zusätzliches Wissen nötig ist.

Der Interaction Room passt gut zu agilen Modellen aus dem Scrum-Umfeld. Das Fortschreiben von Aufwandsprognosen und das kontinuierliche Kontrollieren des Budgets (auf Basis von „Earned-Value-Analysen“) zähmen die Agilität. Er bildet einen verlässlichen kommerziellen Rahmen, innerhalb dessen die Verantwortlichen agile Softwareprojekte organisieren. Während der Interaction Room „vorne“ bei der Softwareentwicklung, im Zusammenspiel zwischen Anwender und Entwickler, sein Potenzial entfaltet, stehen jetzt Möglichkeiten im Fokus, die auch „hinten“, beim IT-Betrieb, für mehr Agilität sorgen.

Agil bis in den IT-Betrieb

Agil entwickeln bedeutet, in regelmäßigen kurzen Abständen Software zu produzieren: Software, die Unternehmen in den Betrieb – oder zumindest in produktionsnahe Umgebungen – überführen müssen. Dafür müssen sie die passenden Prozesse und Rahmenbedingungen schaffen. Im Folgenden wird der praktische Einsatz verschiedener Ansätze beschrieben, mit denen die in der Anwendungsentwicklung begonnene Agilität im Betrieb fortgesetzt wird. Dazu gehören die aus der Start-up-Welt stammenden DevOps – das Zusammenlegen von Entwicklung, Inbetriebnahme und Betrieb zu einer Organisationseinheit, aber auch der Einsatz weitestgehend automatisierter, kontinuierlicher Integrations- und Deployment-Prozesse wie Continuous Integration (CI) beziehungsweise Continuous Delivery (CD).

Der Begriff DevOps – „Development“ und „Operations“ – steht für eine neue Zusammenarbeit dieser beiden IT-Bereiche. DevOps sind im ersten Schritt ein organisatorisches Thema. Um die Vorteile zu realisieren, müssen IT-Verantwortliche vorhandene Strukturen und Verantwortungen anpassen.

Die einen – Softwareentwicklung (Development) – entwickeln unter Zeitdruck kreative Lösungen, deren Spezifikationen häufig noch durch Kunden geändert werden. Die anderen – IT-Betrieb (Operations) – garantieren stabile IT-Prozesse und sorgen dafür, dass zu festen Terminen neue Software nach strikten Vorgaben in Betrieb genommen wird. Häufig herrscht zwischen diesen Abteilungen mangelndes Verständnis für die Arbeitsweise und Zielsetzungen des Gegenübers; ein Mangel, der für langsamere Prozesse und erhöhten Abstimmungsaufwand sorgt. An dieser Stelle setzt die DevOps-Idee an: Anwendungsentwicklung und IT-Betrieb sind eins. Das komplette Team wird daran gemessen, dass der Service, den sie verantworten, verfügbar ist.

BASTA! 2018

Elegante und performante WebAPIs und Webanwendungen (MVC & Razor Pages) mit ASP.NET Core 2.1?

mit Dr. Holger Schwichtenberg (IT-Visions.de / 5Minds IT-Solutions.de)

Machine Learning mit TensorFlow

mit Max Kleiner (kleiner kommunikation)

Angular Kickstart: von 0 auf 100

mit Christian Liebel (Thinktecture AG) und Peter Müller (Freelancer)

JavaScript für Softwareentwickler – für Einsteiger und Umsteiger

mit Yara Mayer (evia) und Sebastian Springer (MaibornWolff)

Insbesondere bei der agilen Softwareentwicklung spielen DevOps ihre Stärken aus: Was nutzen die wöchentlichen Sprints eines Scrum-Projekts, wenn die Organisation darauf ausgerichtet ist, dreimal jährlich ein Release zu veröffentlichen? Geboren wurde DevOps in Start-up-Unternehmen: Unternehmen, die ohne große Rücksichtnahme auf ihre IT-Historie agieren können. Diese Herkunft macht es für die Verantwortlichen schwierig, das Konzept eins zu eins auf etablierte Unternehmen mit tradierten Strukturen zu übertragen. Denn häufig arbeiten Entwicklung und Betrieb seit Jahrzehnten auf Basis derselben Aufgabenteilung mehr oder weniger zusammen.

Welche Organisationsform beziehungsweise welche Mischung von Organisationsformen für ein Unternehmen geeignet sind, können die Verantwortlichen nur durch genaue Betrachtung des Einzelfalls entscheiden. Aber es gibt einige Indikatoren, die anzeigen, ob die Tendenzen eher in Richtung DevOps oder in Richtung klassische CIO-Organisation gehen:

  • Systeme, die sich nur langsam verändern und die kaum strukturellen Anpassungen ausgesetzt sind, sind kein Auslöser für die Einführung von DevOps-Strukturen.
  • Das Gleiche gilt für Anwendungen, die Teil einer hochintegrierten IT-Landschaft sind. Hier ist es in aller Regel schwierig, Änderungsreichweiten vorherzusagen. Denn bei Anpassungen müssen Unternehmen häufig ganze Landschaften oder zumindest erhebliche Teile komplett einführen. Die daraus resultierende Komplexität der Gesamtverantwortung kann für ein einziges DevOps-Team zu groß werden.
  • DevOps eignen sich für Strukturen mit klaren Trennlinien in Form nur lose gekoppelter, asynchroner integrierter Dienste. Diese Voraussetzungen sind häufig in jüngeren Systemen gegeben. Dies trifft insbesondere auf oberflächenintensive und kundensichtbare Systeme am Anfang ihres Lebenszyklus zu. In so einem Umfeld können DevOps bestens funktionieren.
  • Mobile Anwendungen sind von ihrer Natur aus geeignete Kandidaten für eine DevOps-Organisationsform; allein schon, weil sie sich schnell verändern und immer verfügbar sein müssen.

Die Herausforderung für viele IT-Verantwortliche liegt darin, innerhalb ihrer etablierten Strukturen ein neues Konzept der Zusammenarbeit zu implementieren. In der Praxis hat sich ein dreistufiges Vorgehen bewährt, mit dessen Hilfe Unternehmen DevOps schrittweise einführen, ohne die Anpassungsfähigkeit einer Organisation zu überfordern:

Stufe 1 – säen: „Gemeinsame Serviceverantwortung entwickeln“ – das ist das Motto der frühen DevOps-Einführung in Unternehmen. Die Grundlage bilden ein einzelner oder einige wenige geeignete Services. Hierfür bieten sich innovative Anwendungen aus den Bereichen Internet und Mobile Computing an, die mit marktgängigen Technologieplattformen (.NET, JEE) realisiert sind und etablierte Softwarearchitekturmuster verwenden. Komplexe Mainframe- und Legacy-Anwendungen sind eher ungeeignet.

Stufe 2 – pflegen: Auf Basis des in Stufe 1 konzipierten und erprobten DevOps-Blueprints rollen die Teams das Konzept weiter aus und verankern es tiefer in der Organisation. Dazu wählen die Verantwortlichen einen repräsentativen Querschnitt aus dem Portfolio der IT-Services aus. Für diese Auswahl werden Teams aufgebaut. Geeignet sind Prozesse, die von DevOps besonders profitieren. Das Geschäftsmodell und die Untersuchung der IT-Organisation liefern Anhaltspunkte für die Suche: An welchen Stellen müssen Entwickler häufiger Änderungen an der Unternehmenssoftware umsetzen? Wo muss das Unternehmen schnell mit Lösungen auf dem Markt sein? Die Antworten auf solche Fragen liefern Hinweise darauf, wo sich DevOps-Potenzial verbirgt.

Stufe 3 – ernten: Die Umstrukturierung des verbleibenden Teils des Serviceportfolios, der für das DevOps-Konzept geeignet ist, ist ein wichtiges Element der letzten Phase. Ziel ist nicht das hundertprozentige Durchdringen, sondern die am Geschäftsnutzen orientierte Umstellung mit Augenmaß. Auf der technischen Seite wird die Automation der Abläufe flächendeckend ausgebaut. Die IT-Experten führen auf Basis einer standardisierten IT-Infrastruktur Self-Services für das Deployment von Entwicklungs- und Testumgebungen, einschließlich der erforderlichen Testdaten, ein.

Gewohnte Arbeitsweisen in Frage stellen, über Jahre erlernte Konzepte aufgeben, das reflexartige Denken in den Kategorien „wir“ und „die“ über den Haufen werfen: Die Einführung und das Leben von DevOps verlangen Mitarbeitern einiges ab. Mit dem beschriebenen Konzept zur Einführung gelingt Unternehmen der Übergang.

BizDevOps

DevOps-Strukturen sind, so mutig der Schritt weg von herkömmlichen CIO-Organisationen wirkt, erst der Anfang. Denn die zunehmende Bedeutung der IT, die wachsende IT-Kompetenz in den Fachabteilungen und die Kommoditisierung des Betriebs sorgen dafür, dass Umstrukturierungen nicht an den Grenzen der IT-Abteilung aufhören. Im nächsten Schritt wird es notwendig sein, Business, Development und Operations – BizDevOps – bei Softwareentwicklung und -betrieb zusammenarbeiten zu lassen. Schon heute ist diese Organisationsform in Start-ups verbreitet, die auf die Lean-Startup-Methode setzen. Über diese jungen Unternehmen hinaus werden BizDevOps in Zukunft eine wichtige Rolle spielen. Im eingangs erwähnten Interaction Room können auch IT-Entwicklung, -Betrieb und Business zusammenarbeiten; er ist ein Instrument, mit dem BizDevOps schon heute in der Praxis gelebt werden kann.


Dies ist der erste Teil des Artikels zur Agilität in Großunternehmen. Den zweiten Teil finden Sie hier.

Entwickler Magazin

Entwickler Magazin abonnierenDieser Artikel ist im Entwickler Magazin erschienen.

Natürlich können Sie das Entwickler Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -