Interaction Room

Wie IT- und Fachabteilung kontrolliert agil entwickeln

Prof. Dr. Volker Gruhn gründete 1997 die adesso AG mit und ist heute Vorsitzender des Aufsichtsrats. Er ist Inhaber des Lehrstuhls für Software Engineering an der Universität Duisburg-Essen. Sein Forschungsschwerpunkt in diesem Bereich bezieht sich auf mobile Anwendungen. Gruhn ist Autor und Co-Autor von rund 200 nationalen und internationalen Veröffentlichungen und Konferenzbeiträgen.
Agile Software-Entwicklung und planorientiertes Vorgehen müssen sich nicht ausschließen. Wenn es gelingt, die Agilität zu "zähmen", können Unternehmen in den Genuss der vollen Wirkung kommen. Interaction Rooms leisten dazu einen Beitrag.

Plangetriebenes Vorgehen oder agile Softwareentwicklung - eine Diskussion, die unter Fachleuten schnell missionarischen Charakter bekommen kann. Auf der einen Seite planorientierte Modelle, die auf der Annahme basieren, dass Spezifikationen weitgehend vollständig sind und späte Anforderungen zu vermeiden sind. Auf der anderen Seite agile Modelle, denen häufig der Ruf vorauseilt, auf Projektstandards wie eine saubere Dokumentation gleich ganz zu verzichten.

In IT-Abteilungen geht es aber nicht um Ideologien, sondern um Realitäten und Resultate. Die Verantwortlichen müssen Anforderungen, die erst im Projektablauf zu erkennen sind, berücksichtigen. Andererseits müssen sie manche Idee aus der Anfangsphase später streichen. Und bei aller notwendigen Flexibilität haben Unternehmen grundlegende Anforderungen an die Planbarkeit: Sie benötigen definierte Liefertermine, Minimalfunktionalitäten und verbindliche Budgets - sonst findet ein Projekt kaum Rückhalt im Management.

Wie fast immer im Leben ist weder Schwarz noch Weiß die Lösung. Für Unternehmen stellt sich die Frage, welchen Grad an Unvollständigkeit sie in Kauf nehmen und wie korrigierbar Zielsetzungen sein sollen. Es gilt, die Vorteile der agilen Softwareentwicklung mit planerischer Sicherheit zu kombinieren. Agilität muss gezähmt werden, dann entfaltet sie ihre volle Wirkung. Ein Instrument, um diese Ziele zu erreichen, ist der sogenannte Interaction Room.

Dabei handelt es sich um einen echten, begehbaren Raum mit vier Wänden. Diese Wände haben im wahrsten Sinne des Wortes tragende Funktionen. Sie dienen zur Visualisierung von Prozessen und zur Darstellung von Projektdetails. Sie helfen dabei, Probleme zu 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 des Projekts. Das Team visualisiert dies durch die Zuordnung von Symbolen zu einzelnen Aspekten des Projekts.

Im Interaction Room ordnet das Team einzelnen Aspekten des Projekts Symbole zu.
Im Interaction Room ordnet das Team einzelnen Aspekten des Projekts Symbole zu.
Foto: adesso AG

Der Interaction Room kann grundsätzlich unabhängig von einem konkreten Vorgehensmodell eingesetzt werden. Er passt allerdings gut zu agilen Modellen aus dem Scrum-Umfeld. Das Fortschreiben von Aufwandsprognosen und die kontinuierliche Verfolgung des Budgets (auf Basis von "Earned Value Analysen") machen die Agilität berechenbar. So schafft dieses Werkzeug einen verlässlichen kommerziellen Rahmen, innerhalb dessen die Verantwortlichen Softwareprojekte in einem Unternehmen organisieren.

Dass der Interaction Room sich im Unternehmensumfeld bewährt hat, zeigen beispielsweise Projekte bei der Barmenia Versicherung, wo auf diesem Weg ein umfangreiches SEPA-Projekt umgesetzt wurde.

Kreative Strukturen statt kreativem Chaos

In welchem Verhältnis Planung und Flexibilität zueinander stehen, hängt von mehreren Faktoren ab. Unternehmen aus der gleichen Branche mit ähnlichen Anwendungslandschaften, Vertriebswegen und Produkten können sich in durchaus unterschiedlichem Ausmaß der Agilität verschreiben, das gilt selbst für Projekte in der gleichen Organisation.

Aber es gibt Indikatoren, die Hinweise geben. Dazu gehören die Größe des Projekts, seine Bedeutung, die Dynamik des Umfelds, die Unternehmenskultur und das Branchen-Know-how der Entwicklungsmannschaft. Zwei weitere Kriterien, die selten genannt werden, haben sich in der Projektpraxis ebenfalls als wichtig herausgestellt: der Zustand der Anwendungslandschaft und - fast noch bedeutender - die Frage, ob ein anstehendes Projekt mit großer Wahrscheinlichkeit zu strukturellen Veränderungen der Anwendungslandschaft führen wird.

Abhängig von diesen Faktoren nähern sich planorientiertes und agiles Vorgehen einander an. Die Idee des Interaction Room ist es, einen geeigneten Mix aus Plan und Agilität direkt anzusteuern und den häufig zähen Weg von einer Seite des Spektrums in die Mitte zu vermeiden.

Ein weiterer Vorteil liegt im Zusammenführen von IT- und Fachseite. Wenn neue Software für wettbewerbskritische Geschäftsprozesse entwickelt werden soll - gleichgültig, ob durch die unternehmensinterne IT oder durch externe Lieferanten - treffen zwei Expertengruppen aufeinander: Anwender aus den Fachabteilungen und Softwareentwickler. Unterschiedliche Ziele, Arbeitsweisen und Vorstellungswelten erschweren dabei die Zusammenarbeit. Der Interaction Room ist ein Medium, über das Fach- und IT-Experten besser miteinander kommunizieren können. Erreicht wird dies durch die offene, verständliche und nicht IT-fixierte Darstellung von Prozessen. Vertreter aus den Fachabteilungen können sich intensiv in die Diskussionen einbringen.

Beispiel für die offene, nicht IT-fixierte Beschreibung von Prozessen.
Beispiel für die offene, nicht IT-fixierte Beschreibung von Prozessen.
Foto: adesso AG

Raum für Ideen

Der Interaction Room ist eine Methode, die das Interesse auf den Projektfortschritt lenkt und dazu beiträgt, dass alle Beteiligten die Vision der angestrebten Software teilen und weiterentwickeln. Damit die gewünschten Ergebnisse erzielt werden, sind allerdings einige Voraussetzungen zu beachten. Große Bedeutung kommt den Wänden des Raums zu. Die Interaction-Room-Mitglieder modellieren auf ihnen die Prozesse, erfassen Informationen und visualisieren den Projektstatus. Jede der vier Wände repräsentiert einen zentralen Aspekt des Projekts.

Das Team hält die Modelle der Geschäftsprozesse, die das Softwaresystem einmal unterstützen soll, auf der Prozesswand fest. Fachliche Objektmodelle notieren sie auf der Objektwand. Die dritte Wand ist die Statuswand: Hier werden Backlog und Projektfortschritt protokolliert. Auf der vierten Wand wird die Integrationslandkarte abgebildet (Integrationswand). Sie gibt Auskunft darüber, welche existierenden Softwaresysteme die Experten mit dem zu erstellenden System integrieren müssen.

Damit die Zusammenarbeit im Interaction Room reibungslos funktioniert, müssen sich alle Beteiligten im Vorfeld über einige Grundsätze im Klaren sein:

  • Abstraktion: Wände sind, im Gegensatz zu elektronischen Dokumenten, endlich. Das zwingt dazu, sich auf das Wesentliche zu konzentrieren - ein gewollter Effekt! In der Praxis hat es sich bewährt, auf der Prozesswand nicht mehr als 15 Prozessmodelle mit jeweils maximal 15 Aktivitäten zu notieren. Die Beteiligten blenden Details, die unnötig Ressourcen binden, aus.

  • Wertorientierung: Eine entscheidende Frage ist, wie das Team die kritischen Teile eines zu erstellenden Softwaresystems identifiziert. In der Praxis neigen Projektbeteiligte dazu, einfachen Zusammenhängen, die sie schnell verstehen, zu viel Zeit und Ressourcen zu widmen. So werden Personenstammdaten detailliert modelliert, während zentrale Geschäftsprozesse zu wenig Aufmerksamkeit bekommen. Die Antwort des Interaction Room auf dieses Problem ist die sogenannte "Wertannotation" von Prozess- und Objektmodellen.

Hier sind die Symbole zu sehen, die die die Projektbeteiligten in verschiedenen Durchgängen an die Aktivitäten der Prozessmodelle kleben.
Hier sind die Symbole zu sehen, die die die Projektbeteiligten in verschiedenen Durchgängen an die Aktivitäten der Prozessmodelle kleben.
Foto: adesso AG

  • Inkonsistenz: Ein unternehmensweit bedeutsames IT-Projekt darf nicht zu einer IT-dominierten Veranstaltung geraten, in der die Fachabteilung unterrepräsentiert ist. 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. Die Beteiligten nutzen, in Abstimmung mit dem Interaction-Room-Moderator, was immer ihnen sinnvoll erscheint. Syntaktische Ungereimtheiten nehmen sie dabei in Kauf.

  • Ungewissheit: In den frühen Phasen der Softwareentwicklung sind nicht alle fachlichen Zusammenhänge gleichermaßen klar, über einige Themen wird womöglich kontrovers diskutiert. Um festzustellen, welche Zusammenhänge noch nicht durchdrungen wurden, müssen alle Teilnehmer des Interaction Room 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.

Wie sieht nun die Arbeit im Interaction Room aus? Und wie sollte das Projektteam zusammengesetzt sein? Am Beispiel eines SEPA-Projekts bei der Versicherungsgruppe Barmenia lässt sich der praktische Einsatz beschreiben. Der einheitliche Europäische Zahlungsraum (SEPA - Single European Payment Area) hat Einfluss auf zahlreiche Abläufe innerhalb des Unternehmens und in der Kommunikation mit Kunden.

Um sicherzustellen, dass IT-seitig alle SEPA-Vorbereitungen getroffen wurden, hat das Management ein Projektteam eingesetzt, das im Interaction Room zusammenarbeitete. Es bestand aus einem Projektmanager als Moderator, aus technischen Experten unterschiedlicher Abteilungen sowie einem externen Fachmann, der Erfahrung im Umgang mit dem Interaction Room mitbrachte.

Prinzipiell ist bei der Auswahl des Moderators zu beachten, dass er sowohl methodische als auch kommunikative Kompetenzen mitbringt. Wichtig ist auch, dass er mindestens ein grobes Verständnis für die fachlichen Themen hat, die von dem Projekt betroffen sind. Die Fachbereiche entsenden echte Anwender und nicht nur Führungskräfte in das Projektteam; die IT-Vertreter sollten zu einer fachlichen Kommunikation mit ihnen fähig sein.

Bei Barmenia stand das Team vor der Aufgabe, alternative Realisierungsmöglichkeiten für einzelne Aspekte der SEPA-Umstellung zu erarbeiten. Alle zwei Tage setzten sich die Experten zusammen, um ein konkretes Thema zu erarbeiten und Entscheidungsvorlagen zu entwickeln. Diese wurden einem Gremium aus CIO, mehreren Abteilungsleitern und dem Projektmanager vorgelegt. In monatlichen Abstimmungsmeetings bewerteten sie die Vorlagen und wählten die Alternativen aus, die umzusetzen waren.

Am Beispiel der gemeinsamen Modellierung von Geschäftsprozessen lässt sich die Arbeit im Interaction Room beschreiben. Das Projektteam systematisierte und bewertete die erfassten Prozesse. In verschiedenen Durchgängen befestigten sie die Annotationen in Form von Symbolaufklebern an dem Prozessmodell. Jeder Teilnehmer konnte in einem Durchgang beliebig viele Symbole einsetzen. Am Ende eines Durchgangs diskutierte das Team die Ergebnisse. An Stellen, an denen sich größere Kontroversen abzeichneten, wurde die Abstimmung an sogenannte Breakout-Sessions delegiert. Die Teammitglieder konnten hier detaillierte Konzepte erstellen und einzelne Anforderungen diskutieren.

In einem finalen Durchgang bewertete jeder Teilnehmer des Interaction Room, zu welchen Sachverhalten, dargestellt als Aktivitäten von Prozessmodellen, noch zu wenig Detailkenntnis im Interaction-Room-Team verfügbar waren. Sie kennzeichneten die entsprechenden Aktivitäten mit Symbolen. Anschließend erarbeiteten sie, welche Maßnahmen nötig waren, um diese Defizite auszugleichen (beispielsweise das Einbeziehen zusätzlicher Experten oder die Detailbetrachtung von Lösungen in aktuellen Geschäftsprozessen beziehungsweise Anwendungen).

Warum sein Unternehmen auf den Interaction Room setzt, erläutert Kai Völker, Hauptabteilungsleiter Unternehmensarchitektur bei der Barmenia, so: "Sobald wir bei einem Projekt keine glasklaren Anforderungen haben und die Gefahr besteht, dass es widersprüchliche Vorstellungen vom Ergebnis geben könnte, setzen wir den Interaction Room ein." Gerade in dem SEPA-Projekt habe der Interaction Room seine Vorteile ausspielen können: "Fachlich unterschiedliche Vorstellungen wurden frühzeitig transparent gemacht und durch die direkte Interaktion der fachlichen Protagonisten zügig geklärt", blickt Völker zurück.

Wer "agil" sagt, muss auch "Betrieb" sagen

Agil entwickeln bedeutet, in regelmäßigen, kurzen Abständen Software zu produzieren, die in den Betrieb oder zumindest in produktionsnahe Umgebungen überführt werden muss. Dafür gilt es, die passenden Prozesse und Rahmenbedingungen zu schaffen. Wir werden in Kürze einen weiteren Artikel publizieren, der den praktischen Einsatz verschiedener Ansätze beschreibt, mit denen die in der Anwendungsentwicklung begonnene Agilität im Betrieb fortgesetzt wird.

Dazu gehört das aus der Start-up-Welt stammende DevOps - das Zusammenlegen von Entwicklung, Inbetriebnahme und Betrieb zu einer Organisationseinheit. Aber auch der Einsatz weitestgehend automatisierter, kontinuierlicher Integrations- und Deployment-Prozesse: Continuous Integration (CI) beziehungsweise Continuous Delivery (CD). Neben diesen organisatorischen und prozessualen Verbesserungen werden Private-Cloud-Mechanismen beschrieben, die durch das Bereitstellen von Infrastruktur-Software und -Hardware die Reaktionsgeschwindigkeit des IT-Betriebs erhöhen. (hv)