Category

Allgemein

Online-Meetings – warum sind die so anstrengend?

By | Allgemein, Inhaltliches | No Comments

…und was können wir tun, um es besser auszuhalten?

Der Tag beginnt mit einem kurzen Kundentermin. Der Auftrag an mich: 1,5 Stunden Retrospektive mit 5 Teilnehmenden online moderieren. Danach noch ein kurzes Weekly mit meinen Kollegen. Super, dann habe ich danach ja noch einen ¾ Tag, um mich auf die nächsten Themen zu stürzen. Aber um ehrlich mit mir selbst zu sein, es fühlt sich danach eher so an, als wenn ich ein Nickerchen machen oder einen Spaziergang einschieben sollte.

Warum sind Webmeetings eigentlich so viel anstrengender als ein Treffen face-to-face? Um diesem Phänomen auf die Schliche zu kommen, habe ich ein wenig recherchiert.

Videokonferenz-Erschöpfung

Das Erlebte nennt sich neu-deutsch: „Zoom Fatigue“ (1) und lässt sich relativ leicht erklären, wenn man sich die Funktionsweise unseres Gehirns näher anschaut:

Schon Watzlawick beschrieb es folgendermaßen: „Man kann nicht nicht kommunizieren“ (2). Dies lässt sich in einer Websession hervorragend nachfühlen. Das menschliche Hirn ist innerhalb einer Unterhaltung auf einem Parallel-Thread konstant damit beschäftigt, die non-verbalen Signale seiner Gegenüber zu deuten, um angemessen darauf zu reagieren. Schließlich machen non-verbale und paraverbale Anteile einen größeren Anteil der Kommunikation aus, als der Inhalt, wenn man Mehrabians 7-38-55-Regel(3) Glauben schenken möchte (nur 7% sprachlicher Inhalt). Unabhängig davon, ob diese Werte nun exakt stimmen, ist es aber genau dieser Umstand, der uns so schlaucht.

Der Videostream, der die anderen Teilnehmenden häufig nur teilweise zeigt, in vielen Fällen sogar eine ganze Reihe weiterer Teilnehmer gleichzeitig in der Galerieansicht präsentiert, regelmäßig in eher schlechter Bild- und schlimmstenfalls sogar grausiger Tonqualität, strengt unser Hirn an, da es eine kontinuierlich geteilte Aufmerksamkeit (continuous partial attention) (1) erzwingt.

„Leistung ergibt sich aus unserem Potenzial minus unserer Störungen.“ (4)

Die konstante Belastung durch Webkonferenzen zwingt unsere Selbstregulationsfähigkeit in die Knie. Präfrontalkortex, (u.a. zuständig für Planung, Organisation und vor allem schlussfolgerndem Denken) und Amygdala (verknüpft Ereignisse mit Emotionen) laufen auf Hochtouren – unabhängig davon, ob wir uns gerade darüber austauschen, wer ein Echo produziert oder wie wir mit einer Herausforderung im Projekt umgehen wollen.

Fehlende Erfahrung in verteilter Arbeit

Das führt uns zu einem weiteren Problemkomplex: auf Grund der Corona-Krise sind viele Unternehmen gezwungen, kurzfristig auf Remote-Arbeit umzustellen. Da in vielen Fällen keine Zeit und nur wenig Erfahrung mit verteiltem Arbeiten vorhanden war, machen viele weiter wie bisher nur eben vom Home-Office aus. Das Ergebnis sind Arbeitstage mit einer langen Aneinanderreihung von Remote-Meetings, was neben mir vielleicht auch andere anstrengend finden. Außerdem erleben wir Mitarbeitende, die berichten, dass sie auf Grund der vielen Meetings gar nicht zum Arbeiten kommen. Gleichzeitig haben manche Führungskräfte Sorge, dass sie ohne Remote-Meetings nicht sicherstellen könnten, dass jeder weiß, was zu tun ist.

Ein Teufelskreis? Anbei ein paar Ideen, um den Herausforderungen der aktuellen Situation zu begegnen:

Lösungsansätze kurz-, mittel- und langfristig

Kurzfristige Lösungsansätze:
  • jedem Teilnehmenden eines Webmeetings anbieten, die Kamera auszumachen, um Energie für die Zeitpunkte zu sammeln, wo es dem/der Einzelnen wichtig ist, gesehen zu werden
  • beim Präsentieren/längeren Sprechen eines Teilnehmenden auf „Sprecheransicht“ fokussieren
  • zur Abwechslung mal zum Telefon statt zum Videotool greifen und beim Sprechen bewegen, das regt das Denken an
  • viele kurze Pausen zwischen den Meetings, um Tool-frei (!) durchzuatmen, das gelingt z.B., indem Meetings anstelle von 60 Minuten mit nur 50 Minuten eingestellt werden, aber lediglich zur vollen Stunden gemeetet wird
Mittelfristige Lösungsansätze:
  • Webmeetings auf Randzeiten des Arbeitstages legen, um den Arbeitsfluss nicht konstant zu unterbrechen
  • Webmeetings ausschließlich nutzen, um:
    • eine persönliche Verbindung zwischen den Mitarbeitenden herzustellen (informeller Austausch, Krisenintervention)
    • um komplexe fachliche Probleme, die ich nicht allein lösen kann, gemeinsam mit anderen anzugehen
    • um Arbeit zu verteilen & zusammenführen, wenn dies nicht sogar schriftlich (mittels Wiki o.ä. möglich ist)
  • statt Dailies oder Check-ins per Videokonferenz: Chat, in dem Teammitglieder kurz berichten, was sie heute vorhaben und wobei sie Unterstützung benötigen
  • einen Videostream für das Team einrichten, in dem jede(r) sich den ganzen Tag einwählen kann, wenn sie/er mal mit anderen Austausch sucht
  • Statusfunktion in Tools nutzen, um zu signalisieren, wann jemand ansprechbar oder eben nicht verfügbar ist (geht z.B. bei Teams oder Slack)
  • statt langwierigen Status-Meetings, die nur wenige im Team interessieren: ein Weekly/Monthly im Lean Coffee-Format (5) mit Whiteboardtool (z.B. Mural)

Langfristige Lösungsansätze:
  • „Maker´s Schedule“ statt „Manager´s Schedule“(6): um fokussiert arbeiten zu können, hilft es, sich im Team darauf zu verständigen, spezifische kurze Zeitfenster für Kommunikation zu blocken und dadurch große freie Blöcke für kreatives und vor allem unterbrechungsfreies Arbeiten zu erhalten, in diesen dann Mails, Social Media, etc. auf Stumm schalten und Status entsprechend einstellen
  • verteiltes Arbeiten so etablieren, dass aus der Notlösung eine Tugend wird. Dies gelingt zum Beispiel und stark verkürzt über selbstorganisierte, cross-funktionale Teams, klare Rollen und gestärkte Eigenverantwortung, weitere Informationen findest Du hier(7)

Wenn es dann doch mal ein Remote-Meeting sein muss: Um sich fokussiert, effektiv und möglichst schmerzfrei abzustimmen, bieten sich bestimmte Tools, aber vor allem auch besonders geeignete Formate und Moderations-Handwerkszeug wie insbesondere Fragetechniken in Remote-Setups an.
Dazu findet ihr hier noch mehr…

Makro eLearning - 90min Wissensbausteine

 

Quellen:

(1) –  „Zoom Fatigue“ is taxing the brain (Link)
(2) –  Paul Watzlawik (Link)
(3) – Albert Mehrabian (Link)
(4) – „Wie das Gehirn Spitzenleistung bringt“ K. Notebaert & P. Creutzfeldt
(5) – Lean Coffee (Link)
(6) – „Maker´s Schedule“ Paul Graham (Link)
(7) – Vortrag „Die Selbstorganisationsformel (Minute 5-13 auf Youtube) & Masterclass Geschäftsmodelle der Zukunft

AGILA in den Zeiten der Corona

By | Allgemein, Inhaltliches | No Comments

Noch heute erinnern sich meine Schulfreunde an ein Buch-Referat, das ich mit meinem Freund und Sitznachbarn Rudi abgeliefert habe. „El amor en los tiempos del cólera“ (Die Liebe in den Zeiten der Cholera) – der weltberühmte Roman von Gabriel García Márquez wurde von uns atemberaubend schlecht und wirr zusammengefasst. Warum? Mal sehen …

Neben der hohen Lesezeit scheuten wir den Koordinationsaufwand der Buch-Übergabe und den schwierigen gemeinsamen Entwurf einer Präsentation – Das Buch wurde also (genau!) in der Mitte zerschnitten, die Hälften wurden per Münzwurf zugeteilt, es wurde gelesen und jeweils ein Referatsteil vorbereitet. Der erste Kontakt dieser Teile fand vor Publikum statt. Es war auch unsere erste Abstimmung untereinander …

Ich weiß bis heute nicht wie der letzte Satz meiner Buchhälfte endet. Ohne roten Faden ordneten sich (oft schlüpfrige Neben-)Aspekte der Geschichte aneinander. Ich wusste nicht was später wichtig wird, mein Referats-Partner nicht wo all die handelnden Personen herkommen.

Das herrliche Fiasko endete in frivoler Stimmung und einer Diskussion mit der Lehrkraft. Unser Standpunkt: Wir haben so getan, als wäre ein Referat zu zweit tatsächlich einfacher als ein Referat alleine. Wir dachten auch, das wäre die Idee der Lehrerin, die ein besonders dickes Buch zwei Schülern gemeinsam in die Hände legt… Diese Meinung wurde nur ansatzweise geteilt.

Virtuelle Kollaboration als Hürde für online-Seminare

Ist diese Geschichte aus meiner weit entfernten Jugend tatsächlich relevant? Nun ja, wir haben immerhin wieder eine Krankheit mit „C“ am Start und wir können über Kollaboration sprechen. Zusammen etwas zu erarbeiten war immer schon aufwendig und schwierig, wenn die Arbeitenden wenig interagieren, wird es noch schwieriger. Und zumeist schlecht. Das gilt für Buch-Referate, aber auch für Coachings und Seminare.
Im Seminar-Kontext finden wir mittlerweile viele online-Angebote. Alle sagen sie können das. Das stimmt nur leider selten. Das Überführen von Meetings in 12 verschiedene Home-Offices ist technisch einfach, aber oft auch zäh. Das einfache Abfilmen üblicher Seminar-Tätigkeit macht noch keine sinnstiftende Interaktion. Tatsächlich muss man online-Inhalte sowohl im Coaching- als auch Seminar-Bereich komplett neu denken. Das kostet Geld und Zeit, aber es muss eben sein.

embarc ist eine virtuelle Firma. Wir arbeiten seit unserer Gründung in virtuellen Büros, bald verteilt über 4 Städte. Wir wissen wie man online macht. Und trotzdem hat es uns mehrere Wochen harter Arbeit gekostet ein hoch-interaktives Erlebnis-Seminar wie das „iSAQB AGILA – Agile Softwarearchitektur“ in ein online-Seminar zu überführen. Zentrale Fragen waren dabei: Können wir auch online eine echte Gruppe formen? Können wir intensiv diskutieren? Können wir in Zusammenarbeit Erkenntnis schaffen? Wird das Seminar ein Erlebnis, statt nur abgesessene Zeit zwischen Rückfragen zum Einkauf und dem Gassi führen des Hündchens darzustellen?

Online zusammenarbeiten

Die ersten vollständig remote durchgeführten online-Seminare liegen nun hinter uns und ich kann über unser Konzept und das Feedback dazu berichten. Zunächst haben wir uns um eine Kollaborationsplattform bemüht die wirkliche Zusammenarbeit erlaubt. Die Übungen sind ein zentrales Element zum Verständnis eines Themas und müssen funktionieren. Hier sind wir bei Mural gelandet. Als reines Browser-Tool ermöglicht es live-Zusammenarbeit von vielen Nutzern. Ohne unangenehme Latenz und auch anonym. Miro wäre ein ähnliches Tool.

Die Übungen vorzubereiten ist etwas intensiver als bei Präsenzseminaren, da wir die Teilnehmer etwas stärker führen müssen. Rückfragen müssen möglich sein, idealer Weise findet sich aber alle Information zur Übung inkl. oft benötigter Theorie direkt im Übungsbereich wieder. Time-Boxes müssen klar kommuniziert sein und die Überleitung von der Theorie sauber sein. Wir haben zu diesem Zweck recht detaillierte Übungs-Murals erstellt. Hier ein Beispiel für 4 Gruppen, inkl. jeweiligem kleinen Hilfebereich:

Die Interaktion auf diesen Übungssheets klappt hervorragend. Weil die Gruppen auf Ausschnitten desselben Sheets arbeiten, ist die Besprechung sehr dynamisch und ohne störende Seitenwechsel möglich. Als Trainer hat man immer den Überblick wo die Teams gerade stehen. Um etwas Eindruck zu gewinnen wie die Zusammenarbeit aus der Vogelperspektive aussieht, hier ein kurzes Video:

Wenige Toolbrüche

Um den Fluss des Seminars weiter zu glätten, haben wir uns entschlossen das gesamte Seminar rund um diese Kollaborationsidee aufzubauen. Statt zwischen Powerpoint, Mural, Video-Screensharing und Tool XY hin und her zu springen, haben wir auch die Theorieteile in Mural aufgebaut. Mit entsprechendem Locking und der Verwendung von Outlines kann man „Prezi-artig“ über Theorieinhalte wandern. Als Unterlage ergeben die fertigen Theorie-Sheets auch einen guten Überblick. Ohne Medienwechsel können die Teilnehmer per Doppelklick auf die Übungssheets wechseln. Hier ein Beispiel für einen Theoriebaustein zum ADES-Framework:

Neben diesen inhaltlichen Blöcken haben wir auch ein Dashboard gebastelt, das als zentraler Anlaufpunkt fungiert, einen Themenparkplatz für später zu klärende Fragen, Feedback-Sheets um feingranularer Rückmeldungen einzufordern usw. Gemeinsam mit dem Video-Call inkl. Breakout-Rooms und einem stabilen Chat-Kanal entsteht eine nicht zu diverse, stabile Umgebung die leicht zu erfassen ist und sich mit der Zeit angenehm im Hintergrund hält.

Und das Feedback?

Nun ist es nicht entscheidend was ich über die Intention unseres Seminar-Designs fasle, sondern eher was das Publikum sagt. Bei meinem Referat vor 22 Jahren war das Feedback eher durchwachsen. Diesmal haben wir hingegen einen stark positiven Überhang. Von den Teilnehmern aus drei AGILA-Remote-Seminaren würde das Seminar jeder einzelne weiterempfehlen. Detailliertere Stimmen aus den drei Veranstaltungen:

  • Die Zusammenarbeit im Team und das Gruppenerlebnis sind tatsächlich auf Platz 2 der meistgenannten positiven Aspekte: „Hervorragende Zusammenarbeit im Team“, „Teamübungen waren Klasse!“, „Gutes interaktives Arbeiten und Gruppenarbeiten“
  • Was ist auf Platz 1? Die Toolkette und die Tatsache, dass remote-Arbeit gut funktioniert: „Remote funktioniert super & hat Vorteile“, „Ich werde ein Fan von Remote-Seminaren!“, „Das Arbeiten am Board hat super funktioniert!“, „Technik war stabil und sehr intuitiv“, „Alles super, Remote besser als erwartet!“

Ich feiere hier vor Allem, dass gelobt wird, was online so schwierig ist und worauf wir bei der Erarbeitung des Seminars so stark geachtet haben: Kollaboration und Gruppenbindung, echtes Seminar-Feeling trotz remote-Arbeit. Auch Platz 4 fällt noch in diese Kategorie (Rhythmus des Seminars und Zeiteinteilung), während auf Platz 3 die Praxisrelevanz und Erfahrung des Trainers landeten (was weniger mit online-Seminaren zu tun hat): „Trainer strahlt richtig viel Erfahrung aus“, „Viele praktische Dinge gelernt“.

Die genannten negativ-Punkte auf die Fragen „Was hat euch gestört?“ und „Was würdet ihr ändern?“ sind stark in der Unterzahl. Die einzigen beiden Cluster bemängeln, dass das verteilte eBook nicht so toll ist wie das Hard-Cover Buch „Vorgehensmuster für Softwarearchitektur – Kombinierbare Praktiken in Zeiten von Agile und Lean“ und danach, dass die spannenden Themen von Tag 3 (wo es um das ADES Framework und agile Skalierung geht) mehr Raum einnehmen könnten. Während an Tag 1 noch etwas an der sozialen Komponente (fehlende physische Pausengespräche) gemäkelt wurde, tauchte dieses Thema nach 3 Tagen gar nicht mehr auf. Mit einem formlosen Get-Together und Pausen-offenen Video-Sessions kann über die Tage zumindest etwas Ausgleich geschaffen werden.

Ich freue mich schon auf das nächste online-AGILA im Mai!
Weil dort nur mehr wenige Plätze frei sind, könnt ihr euch für den Sommer-AGILA Termin im August anmelden: AGILA 5. – 7. August 2020.

Meta-learning: Was ich beim eLearning „Remote Moderation“ übers Lehren gelernt habe

By | Allgemein, Inhaltliches | No Comments

Die Krise erfordert neues Denken! Am letzten Mittwoch fand das erste Makrolearning (90-minütige online-Wissenshäppchen) zum Thema „Remote Moderation“ statt. In Remote versteht sich.  Hier ein Erfahrungsbericht:

Wir bei embarc sind als verteiltes Team zwischen Hamburg und Wien aufgestellt. Ich arbeite im Homeoffice, wenn ich nicht beim Kunden bin. Regelmäßig finden sowohl intern als auch mit Kunden Remote-Termine statt. Trotzdem war es eine Umstellung online Wissen zu vermitteln, nachdem ich es sonst eher gewohnt bin, softskillige Themen face-to-face zu schulen.

Check-ListVorbereitung

-auf Wiederverwendung achten: ich habe mich bewusst entschieden, Wissensbausteine auf Remote umzustellen, die jetzt – aber auch nach der Krise – für Kunden nützlich sind, um die Rüstzeiten kurz zu halten und nachhaltig zu arbeiten.

-Testen, Testen, Testen: ich habe in den letzten Tagen immer wieder verschiedene kleine Szenarien mit Kollegen und der Familien getestet. Jeder Testlauf ergab Erkenntnisse über mein eigenes technisches Set-up, den Umgang der Teilnehmenden mit der Technik und den Tools und hat vermeidbare Fehlerquellen aufgedeckt.

-Back-up Plan: da mir im Vorwege unklar war, mit welchen technischen Set-ups die Kunden teilnehmen und ob technisch alles reibungslos funktionieren wird, habe ich die Inhalte für eine Zoomkonferenz mit der Anbindung an Mural für kollaboratives Arbeiten entwickelt, hatte die Inhalte aber außerdem als Powerpoint-Präsentation vorbereitet und ein physisches Whiteboard im Raum, damit ich im Notfall hätte ausweichen können.

-Technische Störungen: da ich mich nicht um die Wissensvermittlung und gleichzeitig um während der Session auftretende technische Probleme hätte kümmern können, hatte ein Kollege „Telefondienst“ für den Notfall. Außerdem haben wir uns bereits 15 Minuten vor der eigentlichen Session im virtuellen Raum getroffen, um bei Bedarf Ton, Bild, etc. bei den Kunden einzurichten. Unsere FAQs, die einen Tag vorab geschickt wurden, enthielten außerdem Anforderungen an die Technik auf Kundenseite und haben Tipps gegeben, wie bei Störungen Abhilfe geschaffen werden kann.

Kurz vor der Session

-Zuhause Bescheid geben: Um unbeabsichtigte Cameo-Auftritte des Ehemanns zu verhindern, habe ich Zuhause abgestimmt, wann mein Büro wieder betreten werden darf.

-Tisch-Set-up: Am Schreibtisch habe ich Folgendes vorbereitet: Wasser auf Papiertuch, damit es geräuschlos abgestellt werden kann, den Laptop erhöht aufgestellt, damit die Kameraperspektive schmeichelnder ist und ich unterhalb der Kamera meine Notizen für die Teilnehmenden unsichtbar bleiben, auf einem Whiteboard neben meinem Schreibtisch hatte ich das Drehbuch (u.a. Agenda, Toolwechsel) des Trainings notiert, um dort immer wieder Orientierung und Zeitplan im Blick behalten zu können. Außerdem hatte ich vorab eine Checkliste erstellt, was kurz vor der Session bedacht werden muss (Anwendungen, außer die benötigten, schließen, Licht beachten, Hintergrund aufräumen, Handy auf Flugmodus)

Während der Session

-Zeitmanagement: remote dauert alles etwas länger, als face-to-face. Daher fand ich es hilfreich, den Techniktest mit den Teilnehmenden zeitlich mit einzuplanen und für Übungen/Diskussionen mehr Zeit als üblich zu geben, da das Sprechen und Agieren in Tools noch etwas ungewohnt ist.

-strikte Moderation: in Remote-Settings fehlt häufig die Möglichkeit, sich non-verbal abzustimmen, selbst wenn man sich per Kamera sieht. Eine Abstimmung über Gesprächsregeln, klare Reihenfolge von Redebeiträgen, etc. ist nötig. Eine offene Frage in die große Runde führt entweder zu gar keiner Reaktion oder parallelen Redesträngen. Als Trainer schule ich somit nicht nur Inhalte, sondern muss auch die Toolnutzung erklären und in Interaktionen moderieren.

Nachbereitung

-Lessons learned: direkt im Anschluss an das Event zu notieren, was ich gelernt habe und das Feedback der Teilnehmenden einzuarbeiten, war hilfreich, um nichts zu vergessen und es auch Kollegen zur Verfügung stellen zu können. Dies funktionierte hervorragend parallel zum Feierabendbier.

Abschließend

Es hat mir so gut gefallen, dass ich gleich weiter mache. Verdaubare Wissenshäppchen online zu vermitteln, sind aktuell eine tolle Möglichkeit, um Teilnehmende in der Krisensituation niedrigschwellig zu unterstützen. Auch das Preismodell „pay what you think is right“ hat hervorragend funktioniert und wird weitergeführt. Folgetermine gibt es hier.

Außerdem bin ich gespannt auf Eure Erkenntnisse in Remote-Set-Ups! Was habt Ihr gelernt?

Remote bei embarc

Wie sehen iSAQB CPSA-Advanced Prüfungsaufgaben eigentlich aus?

By | Allgemein, Inhaltliches | One Comment

diploma-3Der iSAQB-Einstiegslevel Foundation der Certified Professional for Software Architecture-Zertifierung (kurz: CPSA-F) sieht einen Multiple Choice Test als Prüfung vor. Bei der zweiten Stufe, dem Advanced Level (kurz: CPSA-A), bearbeitet der Prüfling hingegen eine Hausarbeit. Seine Lösung verteidigt er (bzw. sie) dann im Rahmen eines Interviews vor zwei Prüfern, die diese vorher durchgesehen und gegen Kriterien gehalten haben.

Bei einem Multiple Choice Test (also bei CPSA-F) ist relativ klar, was auf den Prüfling zukommt. Auch wenn einzelne Lernziele mit Ankreuzfragen nur schwer überprüfbar sind, und man sich konkrete Fragen dazu vielleicht nicht direkt vorstellen kann, gilt das zumindest für die Form der Prüfung. Zum Advanced-Level höre ich in Workshops oder per Mail dagegen immer wieder die Frage: Wie sieht eine solche Prüfungsaufgabe inhaltlich aus? Das ist nicht unmittelbar offensichtlich.

Nun sind die Prüfungsaufgaben selbst natürlich vertraulich (genau wie der Prüfungsfragen im Foundation Level). Vorlagen und Checklisten zur Erstellung von Aufgaben sind jedoch frei zugänglich (auf der Webseite des iSAQB). Sie sind nicht unbedingt leicht verdaulich — falsche Zielgruppe: sie sind für Leute gedacht, die sich neue Aufgaben ausdenken. Ich beschreibe daher im Folgenden mal, wie Aufgaben aufgebaut sind – für Leute, die demnächst ein solche Aufgabe lösen müssen. Was Sie als Advanced-Prüfling also grob erwartet…

Wie sieht eine Aufgabe grundsätzlich aus?
Das Fallbeispiel
Ihre Augabe
Ein Beispiel
Häufige Fragen zu Prüfungsaufgaben
Weitere Informationen
Überblick Prüfungsaufgabe

Wie sieht eine Aufgabe grundsätzlich aus?

Die Aufgabenstellung einer Prüfungsaufgabe für CPSA-Advanced umfasst mindestens 10 Seiten und höchstens 25 (siehe Abbildung rechte, die Seitenzahlen sind Beispielwerte).

Jede Aufgabe ist einer Systemart zugeordnet. Aktuell sind das

  • Informationssystem
  • Embedded System
  • Websystem

Ein Kandidat gibt bei der Anmeldung zur Prüfung die gewünschte Systemart an und erhält dann eine Aufgabe aus diesem Bereich. Damit soll verhindert werden, dass ein Prüfling mit einer Umfeld konfrontiert wird. das ihm völlig fremd ist. Auf Wunsch erhält der Prüfling kurze Abstracts (2-3 Sätze) von zwei verschiedenen Aufgabenstellungen, und entscheidet sich dann für eine davon.

Jede Aufgabe selbst zerfällt dann in zwei grobe Blöcke: Ein Fallbeispiel in Form inhaltlicher Inputs, und die Aufgabenstellung selbst. Letztere ist in Teilaufgaben gegliedert. Die konkreten Prüfungsaufgaben variieren dabei in der Zusammenstellung der inhaltlichen Inputs und den Teilaufgaben erheblich.

Das Fallbeispiel

Prüfungsaufgaben: FallbeispielBeim Fallbeispiel handelt es sich um ein fiktives Projekt, eine Produktentwicklung, eine Migration oder ähnliches. Nach einem kurzen Überblick liegen konkrete Informationen dazu in Form inhaltlicher Inputs vor. Im Wesentlichen sind das Anforderungen, die der Prüfling in den späteren Teilaufgaben berücksichtigen muss. Denkbar sind etwa folgende Inhalte:

  • Funktionale Anforderungen (z.B. wichtige Use Cases, User Stories, …)
  • Qualitätsziele, ggf. verfeinert in Szenerien
  • Stakeholder (z.B. Liste, Personas)
  • Interviews mit Stakeholdern
  • Technische und/oder organisatorische Rahmenbedingungen
  • Fachlicher Kontext, Benutzer und Fremdsysteme
  • Normen und Konventionen
  • Risiken

Nicht jede Aufgabenstellung enthält dabei alle diese Inhalte. Weiterhin kann es sein, dass bestimmte Anforderungen explizit genannt sind, andere jedoch im Rahmen der Aufgabe erarbeitet werden müssen. Beispielsweise liegen mitunter Interviews mit Stakeholdern vor, und die Rahmenbedingungen oder Qualitätsziele muss der Prüfling dann im Rahmen einer Teilaufgabe herausarbeiten und ggf. priorisieren.

Ihre Aufgabe

Prüfungsaufgaben: TeilaufgabenGanz ähnlich wie das Fallbeispiel mit seinen inhaltlichen Inputs ist auch die Aufgabe unterteilt — in mindestens 5 und maximal 10 Teilaufgaben, die unterschiedliche Aspekte der Architekturarbeit abdecken. In Summe soll die Bearbeitung zeigen, dass der Prüfling in der Lage ist, aus Anforderungen methodisch eine Architektur zu entwerfen und festzuhalten, sie zu reflektieren und zu kommunizieren. Analog zu den denkbaren Inputs oben beim Fallbeispiel hier mögliche Teilaufgaben:

  • Kontext abgrenzen
  • Qualitätsziele identifizieren, Qualitätsbaum und -szenarien erarbeiten
  • Offene Fragen an Stakeholder formulieren
  • Lösungsstrategie/Architekturvision anfertigen
  • Architekturentscheidungen treffen
  • Technische Fragestellung inkl. Alternativen und Begründung bearbeiten
  • System strukturieren, fachlich zerlegen, Verantwortlichkeiten festlegen
  • Schnittstellen entwerfen
  • technische und/oder übergreifende Aspekte bearbeiten
  • Lösung qualitativ bewerten
  • Risiken identifizieren und adressieren

Es gibt dabei Überschneidungen in inhaltlichen Inputs und Teilaufgaben: Der Systemkontext könnte etwa mit dem Fallbeispiel gegeben sein (als inhaltlicher Input) oder muss alternativ als Teilaufgabe erarbeitet werden.

Ein Beispiel

Der iSAQB stellt eine Beispielaufgabe bereit: „BigSpender“. Es handelt sich um eine echte Aufgabe, die früher gestellt, mittlerweile aber aus dem Pool genommen wurde, nachdem sie einige Prüflingen bearbeiten durften. Sie können die Prüfungsaufgabe hier als PDF herunterladen.

Inhaltlich geht es in der Aufgabe um Spesenabrechnungen. Das Fallbeispiel enthält dabei folgende Inhalte:

  • Input 1 – Überblick (1 Seite, Text)
  • Input 2 – Fachlicher Kontext (Diagramm und kurze Beschreibung der Akteure)
  • Input 3 – Fachklassenmodell (Diagramm) und Glossar (als Tabelle)
  • Input 4 – Stakeholder (knapp gehaltene Liste)
  • Input 5 – Interview mit dem Auftraggeber (recht umfangreich, ca. 3 Seiten)
  • Input 6 – Exemplarische User Stories (10 Stück)
  • Input 7 – Verfügbarkeit des Systems (Anforderung, als Szenario)
  • Input 8 – Technische Randbedingungen (als kurzer Text)
  • Input 9 – Mengengerüst (Tabelle, Aussagen zu Benutzern, Standorten, Vorgängen …)

Die eigentliche Aufgabe besteht dann aus 6 Teilen.

  • Teilaufgabe 1 – Qualitätsanforderungen herausarbeiten, in Form von Qualitätszielen und -szenarien
  • Teilaufgabe 2 – Lösungsstrategie entwickeln, Umfang ca. eine Seite
  • Teilaufgabe 3 – Technischen Kontext abgrenzen, Diagramm und Beschreibung zu Akteueren und Kommunikation
  • Teilaufgabe 4 – Fachliche Strukturierung erarbeiten (Bausteinsicht)
  • Teilaufgabe 5 – Technologie-Entscheidungen treffen
  • Teilaufgabe 6 – Bewertung der Lösung vornehmen , anhand der Qualitätsszenarien aus Teilaufgabe 1

Details entnehmen Sie dem PDF. Und beachten Sie, dass sich die Prüfungsaufgaben wie geschildert stark unterscheiden, und es sich bei BigSpender um ein Beispiel handelt — wenn auch um ein echtes.

Prüfungsaufgaben: FAQ

Häufige Fragen zu Prüfungsaufgaben

Wie wird sichergestellt, dass die Aufgabe zu den von mir besuchten Schulungen passt?

Eigentlich gar nicht. Durch die Angabe der Systemart (z.B. Web, Embedded) wird lediglich abgesichert, dass es technologisch grob passt. Ansonsten sind die Aufgaben nicht an bestimmte Module gebunden. Die Teilaufgaben (+ Interview) decken lediglich die drei Kompetenzbereiche („Säulen“) des Advanced-Levels ab (methodisch, technisch und kommunikativ).

Welchen Umfang hat meine Lösung?

Sie halten Ihre Lösung auf maximal 40 DIN A4-Seiten (inklusive Abbildungen) fest. Dazu haben Sie maximal 3 Monate Zeit (Details siehe Prüfungsordnung). Vom Aufwand sind die Teilaufgaben so bemessen, dass ein Prüfling sie in 40 Stunden erledigen kann.

Was wenn Technologien oder Methoden gefordert sind, die ich nicht beherrsche?

Die Aufgabenstellungen lassen Ihnen angemessenen Spielraum bezüglich Technologien, Werkzeugen, Notation und Ähnlichem. Wenn etwas explizit gefordert ist, so ist sichergestellt, dass Informationen dazu frei zugänglich sind. Entweder es liegt der Aufgabe bereits in den inhaltlichen Inputs oder in einem Anhang bei, oder es wird darauf verwiesen. Es kann natürlich vorkommen, dass Sie sich zur Lösung der Aufgabe noch Wissen aneignen müssen.

Was wenn mir die gegebenen Anforderungen zur Lösung nicht ausreichen?

Wie im richtigen Leben kann es sein, dass Ihnen zur Lösung der Aufgabe Informationen fehlen. Im Einzelfall scheinen sich Anforderungen sogar zu widersprechen (beispielsweise Aussagen in Interviews von Stakeholdern mit unterschiedlichen Prioritäten). Normalerweise klären sie das im Projekt mit den Beteiligten, finden Kompromisse, etc. Da Ihnen die Leute im Rahmen Ihrer Hausaufgabe nicht zur Verfügung stehen, treffen Sie Annahmen. Diese kennzeichnen Sie in Ihrer Lösung explizit als solche. Achten Sie darauf, dass diese sinnvoll und konsistent untereinander und zur Aufgabenstellung sind.

Soll ich meine Lösung nach arc42 strukturieren?

Die Antwort ist hier ein klares nein. arc42 ist ein verbreiteter Gliederungsvorschlag für Architekturbeschreibungen, daher wäre die Idee naheliegend. Für Ihre Lösung ist aber ganz klar die Vorgabe, dass Sie diese den Teilaufgaben entsprechend strukturieren. Also pro Teilaufgabe ein Abschnitt. Sie ermöglichen den Prüfern auf diese Weise die einfache Durchsicht and den Abgleich mit Kriterien.

Weitere Informationen

Ich hoffe, ich konnte einen Eindruck vermitteln, wie die Prüfungsaufgaben im CPSA-Advanced-Level grundsätzlich aussehen. Wenn Sie Fragen zu dem Thema haben, kommen Sie gerne auf mich zu. Ansonsten: Auf der iSAQB-Seite finden Sie vieles rund um den Advanced-Level. Hier noch ein paar weiterführende Links …

Eine erste Fassung dieses Beitrags erschien im Juni 2016. Sie wurde regelmäßig aktualisiert, zuletzt im April 2020.

Seminare bei embarc

Interview mit Stefan Toth auf der OOP 2020

By | Allgemein, Video | No Comments
Interview mit Stefan Toth – OOP Februar 2020
OOP_Logo_2018
IT-Journalist Christoph Witte im Gespräch mit Stefan Toth
Interviewsprache Englisch, online auf YouTube
veröffentlicht am 11. März 2020,

Mehr zum Thema Architekturbewertung
Architektur-Reviews – warum eigentlich?

Seminare AGILA – Agile Softwareentwicklung, AWERT – Architekturbewertung
iSAQB CPSA-Advanced Seminare

Stefan Toth ist der Experte für agiles Architekturvorgehen im deutschsprachigen Raum und hat viele Unternehmen in entsprechenden Fragestellungen unterstützt. Für den iSAQB hat Stefan Toth den Lehrplan zum Modul „Agile Softwarearchitektur“ (AGILA) verfasst und verantwortet dieses als Kurator. Die Lehrpläne zu Architekturbewertung (AWERT) und „Enterprise Architecture Management (EAM) hat er ebenfalls maßgeblich mitgestaltet, für AWERT hat er ebenfalls die Kurator-Rolle inne. Stefan Toth ist stimmberechtigtes Mitglied im iSAQB und wurde 2019 auch in dessen Strategic Council gewählt.

Der  IT-Journalist Christoph Witte interviewte Stefan Toth im Rahmen der OOP 2020 in München. In dem Interview gibt Stefan Einblicke, wo Architekturbewertungen unterstützen können und welche Schwerpunkte die iSAQB Advanced Module AWERT und AGILA setzen.

 

Vortrag Stefan Toth auf der OOP 2020:
„Warum gute Architektur nichts mit Code-Qualität zu tun hat.“

CONSTRUCT: Aufbauen (5C Design, Teil 6)

By | Allgemein, Inhaltliches | No Comments

Eine Bausteinstruktur kann auf einer Ebene selbst wieder unübersichtlich werden. Baue Systeme höherer Komplexität durch Zusammenfassen von Bausteinen einer Ebene zu einem neuen Baustein einer nächsthöheren Ebene. Dabei sind weiterhin dieselben Handlungsmaximen anzuwenden.

  1. Software-Entwurf: Ein Blick zurück und nach vorn
  2. CUT: Richtig schneiden
  3. CONCEAL: Verbergen
  4. CONTRACT: Schnittstelle festlegen
  5. CONNECT: Verbinden
  6. CONSTRUCT: Aufbauen
  7. Its a Wrap: Zusammenfassung

In den bisherigen Artikeln ging es darum, wie man ein System auf einer Ebene effizient in einzelne Module zerlegt. Bei entsprechend großem Umfang der Lösung kann dabei nach wie vor Folgendes passieren: Die schiere Anzahl der Module wächst Ihnen über den Kopf und das gesamte System ist im Endeffekt wieder unübersichtlich. Was kann man in so einem Fall tun? Eine schlechte Idee wäre, mehr Logik in die einzelnen Module zu geben, sodass die Gesamtzahl an Modulen wieder überschaubar wird. Dadurch würde nur Komplexität in die Module hinein verlagert. Die Alternative ist Strukturen auf der nächst höheren Abstraktionsebene zu bilden. Wir zoomen aus unserer Architektur heraus und bauen dann modulare Strukturen nach denselben Regeln, nach denen wir schon die Module auf der unteren Abstraktionsebene entworfen hatten. Während dies den Vorgang eher bottom-up beschreibt, so ist dasselbe Ergebnis natürlich auch top-down zu erreichen. 

Whole-Part Pattern

Ein fast schon in Vergessenheit geratenes Muster, das dabei hilfreich sein kann, ist das Whole-Part Pattern. Vorgestellt wurde es in einem zeitlosen Klassiker der Software-Architektur namens “Pattern-Oriented Software Architecture” aus dem Jahr 1996. Als Beispiel dient uns der Motor eines Autos. Er besteht aus vielen Einzelteilen, wie dem Kolben, der Kurbelwelle und den Zündkerzen. Der Motor selbst ist aber wiederum nur ein Teil des Autos, das außerdem noch aus Dingen wie dem Lenkrad, der Karosserie, den Rädern und dem Auspuff besteht. Vor dem Fahrer wird diese Komplexität weitestgehend verborgen. Er dreht den Schlüssel um, beschleunigt mit dem Gaspedal und beeinflusst mit dem Lenkrad die Fahrtrichtung. Einmal im Jahr kommt das Auto in die Werkstätte zur Wartung. Dass dort der Filter der Klimaanlage genauso gewechselt wird wie das Motoröl kann dem Fahrer egal sein. Die Abstraktion “Auto” verbirgt all diese Komplexität vor seinem Nutzer so gut es geht.

Das Beispiel mit dem Auto könnte man sogar noch weiterdenken. Ein Robotertaxi-Service könnte eine weitere Abstraktionsebene darstellen. Eine Serversoftware weiß wo sich die einzelnen selbstfahrenden Taxis gerade befinden. Wenn ein Kunde per App eines der Taxis anfordert wird die Software des nächstbesten Robotertaxis dieses zum Kunden bewegen und ihn in weiterer Folge an sein gewünschtes Ziel bringen. Das Auto, die Software darin, die Software am Server und die App am Handy des Kunden bilden dann in Summe eine weitere Abstraktionsebene, die die Mobilität für den Kunden noch weiter vereinfacht.

In einer komplexen Enterprise Architektur können Sie sich dieses Prinzip wie folgt zu Nutze machen: Die Unternehmensarchitekten legen fest, wie sich die Systemlandschaft in einzelne Subsysteme zerlegt. Sie kümmern sich außerdem um Themen, die über die einzelnen Subsysteme hinaus gehen, wie die Wahl der Technologie zur Integration der einzelnen Systeme. Für die Implementierung der einzelnen Subsysteme selbst wird aber nur der grobe Rahmen definiert. Die Verantwortung für die korrekte Umsetzung wird in den einzelnen Teams belassen. Zu klären, wie sich ein konkretes Subsystem selbst dann weiter in Module zerlegt, ist also wiederum Aufgabe eines der Teams. Die Unternehmensarchitekten kümmern sich in einem solchen Modell um die strategischen Themen und überlassen die Taktik den einzelnen Teams.

Self-Contained Systems

Da die Gedanken bisher eher abstrakt waren, möchte ich noch einen konkreten Architekturstil vorstellen, mit dem man das Prinzip der hierarchischen Zerlegung prima umsetzen kann, nämlich Self-Contained Systems (oder kurz: SCS). Diese setzen explizit auf eine sehr lose Kopplung zwischen den einzelnen Teilsystemen. Bevorzugt wird eine Integration über das User-Interface. Ansonsten ist zeitliche Abhängigkeit zwischen den Systemen durch synchrone Kommunikation (wie über SOAP-RPC) eher verpönt und man sollte stattdessen auf asynchrone Integration (wie über Messaging) und Datenreplikation setzen.

Damit das klappt muss anfangs strategisch festgelegt werden, an welchen Grenzen sich das System gut in solch lose gekoppelte Subsysteme zerlegen lässt. Wenn das allerdings klappt, können die einzelnen Teams relativ isoliert voneinander an ihrem jeweiligen Subsystem arbeiten. Die Art der Umsetzung der einzelnen Teilsysteme kann sich dabei auch stark voneinander unterscheiden. So kann es sich bei einem der Subsysteme um einen Legacy-Deployment-Monolithen handeln, während ein anderes auf einer Microservice-Architektur aufbaut.

Im nächsten und bereits letzten Beitrag dieser Artikelserie fass ich das Thema noch einmal kurz zusammen. Außerdem zeige ich Möglichkeiten, wie man eine Architektur nach 5C umsetzt.

Kim Duggen über Organisationsentwicklung und mehr – im Podcast mit Lena Wittneben

By | Allgemein, Publikationen | No Comments

Kim Duggen über ihre persönliche Sicht auf Organisationsentwicklung im Podcast von und mit Lena Wittneben

Kim Nena Duggen im Gespräch mit Lena „There is a crack in everything – Wünsche, Ziele, Wendepunkte!“
Kim Nena Duggen und Lena Wittneben
Podcast über Organisationsentwicklung, Erfahrungswerte und vieles mehr..
September 2019
lena_wittneben

„Für mich ist Kim eine absolut positive „Sprechdenkerin“ (ihre Selbstbezeichnung), die mit maximal Herz, Hirn, Humor und Haltung intelligent-inspierende Ideen in die Welt bringt.“ (Zitat Lena Wittneben)

Was bedeutet Selbstorganisation für Kim und welche Erfahrungen hat sie in ihren beruflichen Umfeldern in den letzten Jahren gemacht? Wie haben die skandinavische und die chinesische Kultur sie beeinflusst und welche Rolle spielt ein wichtiger Sparringspartner schon seit Kindertagen in ihrem Leben? – nicht nur wenn es um Organisationsentwicklung geht.

Und wenn Sie auch noch wissen will, warum Kim beim Karaoke immer das gleiche Lied auswählt? Hören Sie selbst..

embarc echo – September 2019

By | Allgemein, echo | No Comments

Impulse aufgreifen – embarc echo

Lassen Sie sich von unseren aktuellen Konferenzbeiträgen und Publikationen im Web & in gebundener Form inspirieren. Wir haben Tipps für Ihren Einstieg in das Thema Machine Learning und Referenzwissen für ein modernes Web-Frontend direkt zum Download. Außerdem stellen wir Ihnen unsere neue Kollegin vor und werfen einen Blick auf künftige Termine & Veranstaltungen. Finden Sie in gewohnt kurzer Form frische Anregungen für Ihre Projekte!

Download embarc echo September 2019 (PDF, 8 Seiten)

follow us on Twitter – @embarced

CONNECT: Verbinden (5C Design, Teil 5)

By | Allgemein, Inhaltliches | No Comments

Durch Verwendung einer Schnittstelle eines anderen Bausteins kommt es immer zu Abhängigkeiten. Plane explizit zwischen welchen Bausteinen es welche Art von Abhängigkeit geben soll.

  1. Software-Entwurf: Ein Blick zurück und nach vorn
  2. CUT: Richtig schneiden
  3. CONCEAL: Verbergen
  4. CONTRACT: Schnittstelle festlegen
  5. CONNECT: Verbinden
  6. CONSTRUCT: Aufbauen
  7. Its a Wrap: Zusammenfassung

Damit ein System, das in seine Einzelteile zerlegt wurde, in Summe das gewünschte große Ganze ergibt, müssen seine Einzelteile miteinander interagieren. Diese Interaktionen erzeugen Verknüpfungen, die wiederum die einzelnen Teile in Abhängigkeiten zueinander bringen. Vereinfacht gesagt sind bei Änderungen, die nach außen wirksam sind, die angebundenen Module immer zu berücksichtigen. Diesen Aspekt gilt es möglichst klein zu halten. Die Abhängigkeiten können unterschiedliche Bereiche betreffen:

  • Daten und Formate: Ein Consumer muss das Format des Providers einer Schnittstelle verstehen. Bei Änderungen daran ist der Consumer ebenfalls betroffen.
  • Zeit: Wenn der Consumer seine Arbeit nur abschließen kann, wenn der Provider im selben Moment auch gerade verfügbar ist, so ist seine Verfügbarkeit auf Zeiten limitiert, in denen der Provider ebenfalls verfügbar ist. In dem Fall kommt es zu einer zeitlichen Abhängigkeit zwischen den Modulen.
  • Technologie: Ist der Consumer in der technologischen Auswahl seiner Implementierung auf irgendeine Weise eingeschränkt? Ein Netzwerkprotokoll wie Java RMI wirkt beispielsweise einschränkender als eine REST-Integration auf Basis des HTTP-Protokolls.
  • Ausführungsort: Ist es zur Interaktion nötig, dass die Module auf derselben (virtuellen) Maschine laufen, so sind sie was den Ausführungsort angeht eingeschränkt. Bei Kommunikation innerhalb der Grenzen des eigenen Prozesses ist dies beispielsweise so.

Diese technischen Abhängigkeiten ziehen in weiterer Folge Abhängigkeiten auf der organisatorischen Ebene nach sich. Ein Unternehmen, das zur Weiterentwicklung seiner Software überdurchschnittlich viele Meetings benötigt wäre ein Beispiel, wo sich diese Auswirkungen zeigen. Das und ein gezwungenermaßen hohes Maß an Bürokratie sind Indizien dafür, dass man die Abhängigkeiten innerhalb der Software nicht mehr im Griff hat.

Zur Vermeidung von Missverständnissen: Wenn Interaktion nötig ist, ist es nicht möglich, Abhängigkeiten völlig zu vermeiden. Und: Interaktion wird nötig sein. Es gilt die negativen Auswirkungen von Abhängigkeiten durch geschickten Architekturentwurf im Zaum zu halten. Ein bekanntes Entwurfsprinzip, dessen Befolgung dabei hilft, ist das Prinzip der azyklischen Abhängigkeiten. In einem Entwurf wo Module zyklisch voneinander abhängig sind, sind diese Module von jedem anderen in diesem Zyklus direkt oder indirekt abhängig. Diese Situation birgt hohe Risiken von unerwünschten Seiteneffekten bei Änderungen. Daher der Grundsatz Strukturzyklen möglichst zu vermeiden.

Kaskadierende Abhängigkeiten

Ebenfalls problematisch sind sogenannte Kaskadierende Abhängigkeiten. Dabei pflanzt sich ein und dieselbe Abhängigkeit, über die jeweiligen Modulgrenzen hinaus über weitere Abhängigkeiten zu weiteren Modulen fort. Mit anderen Worten: Was auch immer diese Abhängigkeit betrifft, sei es ein Datenformat oder eine Technologie, man wird sie nur ändern oder entfernen können indem man Änderungen am gesamten System vornimmt. Die folgende Grafik illustriert das:

Das Schnittstellenformat, das Baustein A anbietet, wird von den Bausteinen B und C selber wiederum intern benützt. Weiters kommen einzelne Aspekte dieser Schnittstelle in den externen Schnittstellen der Bausteine B und C wieder vor, wodurch sie sich auf deren Consumer (in diesem Fall D, E, F und G) ausbreiten. Eine Änderung der Schnittstelle des Bausteins A zieht dann eine Kaskade an Änderungen nach sich, die schließlich das gesamte System betreffen. Um so etwas zu verhindern bietet sich die Anwendung des Integrationgsmusters Anti-Corruption Layer aus dem Domain-Driven-Design an, das in der folgenden Grafik dargestellt ist. Dabei kommuniziert ein Consumer nur über einen solchen Layer mit seinem Provider, der das Modell des Providers in sein eigenes Format konvertiert.

Wenn Sie den Empfehlungen dieser Blog-Serie beim Entwurf Ihres Systems bis hierhin gefolgt sind kann es sein, dass Ihr Entwurf bereits aus einer sehr großen Zahl an Modulen besteht. Eine hohe Anzahl an Modulen kann, auch wenn diese jeweils wunderbar gekapselt sind, wiederum unübersichtlich werden. Sie tun dann gut daran, wiederum dieselben Regeln anzuwenden, allerdings eine Abstraktionsebene höher. Dies bringt uns zum nächsten Beitrag dieser Reihe: „CONSTRUCT: Aufbauen“.