Verabschiede Dich von der typischen Achterbahnfahrt des Projektgeschäfts

Seiten

Kapitel

%

Interaction Room

LESEPROBE

Kapitel 1 - Einleitung

Der Interaction Room ist ein Werkzeugkoffer für unterschiedliche Anwendungsfälle. Neben der Analyse und Konzeption von (mobilen) Informationssystemen können (skaliert) agile Projekte unterstützt, Prozessanalysen durchgeführt oder fachliche Ausschreibungsunterlagen vorbereitet werden. Mit den Bausteinen des Werkzeugkoffers ist es möglich, die Implementierung von Informationssystemen zu gestalten. Dabei kann die Individualentwicklung selbst geleistet, durch einen Dienstleister erbracht oder ein System gekauft und angepasst werden. Der Werkzeugkoffer kann in plangetriebenen und agilen Vorgehensweisen eingesetzt werden. In plangetriebenen Vorgehensweisen ist das Ergebnisartefakt von Interaction Rooms ein Grobkonzept. In agilen Vorgehensweisen ist das Ergebnisartefakt ein mit Epics und Backlog Items befülltes Product Backlog. Durch den modularen Aufbau des Interaction Rooms ist es möglich, auch während agiler Projekte Methodenbausteine zur Unterstützung zu verwenden. Beispielsweise können Refinement Meetings, Schätzklausuren oder die Release-Planung mit Hilfe von InteractionRoom-Bausteinen durchgeführt werden.

Um den Interaction Room anwenden zu können, wird ein Zugang zur Plattform für die datengetriebene Steuerung agiler Projekte „iris“ benötigt. Die Plattform wird zur Vorbereitung, Durchführung und Nachbereitung von Interaction Rooms sowie im Rahmen (gezähmt) agiler Umsetzungsprojekte verwendet.
Weitere Informationen zu iris finden Sie unter https://www.interaction-room.de/iris.
Einen Account können Sie unter https://digital.interaction-room.de anlegen.

In diesem Dokument werden Vorbereitung, Durchführung und Nachbereitung von IRWorkshops beschrieben. Ein Interaction Room dauert mindestens zwei Workshop-Tage. Ein Workshop wird von einem IR-Methoden- und einem IR-Domänenexperten (synonym IR-Coaches) durchgeführt. Für die Vorbereitung sind ca. 5 Personentage (PT) und für die Nachbereitung ca. 10 – 15 PT notwendig.

Kapitel 2 - Kurzüberblick und Einordnung

Der Interaction Room (IR) ist eine Methode, um Stakeholder in Projekten dazu zu bringen, miteinander zu reden, sowie ihr Verständnis für Aufwands-, Risiko- und Werttreiber zu schärfen. Der Einsatz eines IRs bietet sich überall dort an, wo Stakeholder mit verschiedenen Backgrounds und vielschichtigen Anforderungen aufeinandertreffen, normalerweise aber nicht ausreichend miteinander kommunizieren würden. Dieses Handbuch beschreibt die Methodenbausteine und Visualisierungstechniken des Interaction Rooms, der insbesondere für die Konzeption komplexer Softwaresysteme ausgelegt ist. Das Handbuch dient als Leitfaden für IR-Coaches zur Vorbereitung, Durchführung und Nachbereitung von Interaction-RoomWorkshops.

Motivation
In Projekten ist oft zu beobachten, dass Fach- wie auch Technologieexperten zwar gerne ein gemeinsames Verständnis für das zu entwickelnde System aufbauen würden, ihre Kommunikation jedoch durch organisatorische, methodische oder kognitive Barrieren erschwert wird. Eine bessere Unterstützung für die Kommunikation und Kollaboration aller Teammitarbeiter wäre hier hilfreich, um Missverständnisse und Unsicherheiten frühzeitig im Projekt abzubauen. Agile Prozessmodelle wie z. B. Scrum versprechen zwar aufgrund ihrer laufenden Feedback-Zyklen eine häufigere und engere Abstimmung zwischen Fachlichkeit und IT, aber obwohl sie intensive Kommunikation fördern (bzw. sogar davon abhängen), stellen sie keine Mechanismen bereit, um die Kommunikation weg von Trivialitäten und stattdessen auf solche Aspekte zu fokussieren, die komplex sind, nicht ausreichend verstanden wurden oder den eigentlichen Wert des Systems ausmachen. Tatsächlich sind gerade diese wichtigen Aspekte aus den meisten Systemmodellen nicht ersichtlich, weil sie mit den üblichen Modellierungssprachen nicht ausgedrückt werden können. Den Projektmitarbeitern bleiben solche Wert- und Aufwandstreiber daher während der Verhandlung, Konzeption und Implementierung eines Softwareprojekts oft weitestgehend verborgen – bis sie sich spät im Projekt zeigen, wenn die Ressourcen bereits zu knapp sind, um sie angemessen zu behandeln, und viele Architekturentscheidungen bereits etabliert sind, so dass kaum Freiraum zu ihrer effizienten Umsetzung bleibt.