Zusammenarbeit Archives - Digital Innovation Blog

ZEISS verstärkt sein Engagement innerhalb der globalen FOSS-Community weiter

Seit vielen Jahren ist Free and Open Source Software (FOSS) eine zentrale Methode für innovative Softwareentwicklung und hat entscheidend dazu beigetragen, dass ganze Software-Ökosysteme umfangreicher und leistungsfähiger geworden sind. Bei ZEISS ist FOSS ebenfalls allgegenwärtig. Egal ob als Unterstützung in unseren täglichen Arbeitsabläufen oder als essenzieller Bestandteil unseres hochtechnologischen, softwarebasierten Produktportfolios.

Freiwilligentätigkeit und öffentliches Teilen

Der zugrunde liegende Ansatz von FOSS, die Software-Entwicklung gemeinschaftlich und in der Öffentlichkeit durchzuführen, ermöglicht es, selbst die komplexesten Probleme zu lösen und hat erstaunliche Basistechnologien hervorgebracht, ganze Ökosysteme verändert und sogar den Mars erforscht. Bei der typischen Charakterisierung von FOSS wird viel Wert auf den Schwarm-basierten Ansatz gelegt, bei dem eine große Anzahl von Personen in einem kollaborativen Ansatz zusammenarbeiten, um Software zu entwickeln. Dennoch werden viele FOSS-Projekte, die elementare Bestandteile der heutigen Infrastruktur sind, von wenigen Einzelpersonen gepflegt. Neben ihrem Tagesjob schreiben viele von ihnen in ihrer Freizeit Code, d.h. freiwillig, zur eigenen Ermunterung. Ihre Hauptmotivation ist es dabei, ein spezifisches Problem zu lösen, das sie haben. Nachdem sie von den Prinzipien von Open Source und Free Software überzeugt sind, teilen sie das Ergebnis öffentlich unter einer FOSS-Lizenz. Dabei hoffen die ursprünglichen Autor:innen, dass auch andere von ihrer Arbeit profitieren können.

Abhängigkeit von der freiwilligen Softwareentwicklung als Herausforderung

Die Kehrseite solcher „Hobby“-Softwareentwickler:innen ist, dass sie trotz möglicherweise guter Qualifikation dem Projekt nicht immer kontinuierlich und ausreichend Zeit und Priorität widmen können.

Im schlimmsten Fall könnten sie aufgrund geänderter Prioritäten und/oder vermindertem Interesses ihre Beteiligung am Projekt reduzieren oder sogar ganz einstellen. Für das Projekt und die umgebende Community wäre dies ein bedauerlicher Verlust. Für Unternehmen wie ZEISS, die sich auf das Projekt verlassen, ist dies ein Risiko mit potenziellen Auswirkungen auf unsere täglichen Arbeitsabläufe und/oder Produktlinien.

ZEISS unterstützt aktiv die Teilnahme der Mitarbeiter in der Community

Mit dem Ziel, ein aktives und nachhaltiges Mitglied innerhalb der globalen FOSS-Community zu sein, haben wir eine unternehmensweite Richtlinie zur Beteiligung an FOSS definiert. Mit Fokus auf Umsetzbarkeit ermöglicht es jeder:em Softwareentwickler:in bei ZEISS zu FOSS beizutragen und würdigt ein solches Engagement. Der Hauptzweck besteht darin, die gemeinschaftliche Entwicklung von Software durch unsere aktive Beteiligung zu fördern. Dabei können wir unsere vielfältige Engineering-Expertise einbringen und selbst Anwendungen von besonderer Bedeutung veröffentlichen, die nicht nur für uns von Relevanz sein könnten.

Dies trägt auch zur Bewältigung der bereits erwähnten Herausforderung bei. Sollten die eigentlichen Projektbetreuer:innen nur (noch) beschränkt verfügbar sein, könnte auch ein:e ZEISS Entwickler:in einspringen, während die entsprechende FOSS-Komponente für den bestimmungsgemäßen Gebrauch in einem unserer Produkte optimiert wird. Alle von ZEISS veröffentlichten FOSS-Projekte sind auf folgendem GitHub Repository zu finden: https://github.com/zeiss

Durch unsere Mitarbeiter ausgewählte FOSS-Projekte erhalten Unterstützung

Als Ergänzung startete ZEISS 2022 eine Initiative zur unterstützenden Finanzierung von Projekten, die für uns von besonderer Bedeutung sind. Mit den zur Verfügung gestellten Mitteln sollen Maintainer:innen dabei unterstützt werden, ihre wertvolle Arbeit fortzusetzen und mehr Zeit ihren so wichtigen Projekte widmen zu können. ZEISS Mitarbeitende aller Geschäftsbereiche haben in drei Kategorien ihre Lieblingsprojekte gewählt: Produktivitätswerkzeug, Softwarebibliothek und FOSS Foundation. In der zweiten Finanzierungsrunde, die in diesem Sommer abgeschlossen wurde, konnten sechs Gewinnerprojekte mit Zuschüssen in Summe von insgesamt 15.000 EUR ausgezeichnet werden:

Keepass, ein leichtgewichtiger und benutzerfreundlicher Passwortmanager;
VLC, ein plattformübergreifender Multimedia-Player, der unzählige Dateiformate unterstützt;
pytest, ein Framework zum vereinfachten Schreiben von Funktionstests für Softwareanwendungen;
Inkscape, ein leistungsstarker Vektorgrafikeditor;
FFmpeg, ein Framework zur Decodierung, Codierung, Streaming und weiteren Bearbeitung von Multimediadaten; und
Python Software Foundation, eine Organisation, die sich der Weiterentwicklung der Programmiersprache Python als Open Source-Technologie widmet.

Herzlichen Glückwunsch an alle Gewinner:innen zu Ihren großartigen Projekten, die bei ZEISS hoch geschätzt sind! Vielen Dank für die wertvolle Arbeit und das öffentliche Teilen derselben.

Beitritt zur Linux Foundation und zum Zephyr-Projekt

Außerdem freuen wir uns mitteilen zu können, dass die ZEISS Gruppe seit kurzem stolzes Mitglied der Linux Foundation und des Zephyr Projekts ist und wir damit unsere Tätigkeit im Bereich gemeinschaftlicher Softwareentwicklung weiter vertiefen können.

Die Linux Foundation beherbergt nicht nur Linux und das dazugehörige Ökosystem, sondern unterhält auch eine Vielzahl an anderen Initiativen, die weit über die reine Codeentwicklung hinausgehen. Um ein paar Beispiele zu nennen: SPDX als gemeinsamer Standard für die Darstellung der Softwarekomposition in Form von Software Bill of Materials (SBOM) oder die TODO Group als Erfahrungsaustausch für eine erfolgreiche Open-Source-Governance im Unternehmen.

Das Zepyhr-Projekt pflegt ein modernes und innovatives Echtzeitbetriebssystem, das in zukünftigen ZEISS Produktlinien vermutlich mehr als nur einen Auftritt haben wird.

Spannende Zeiten liegen vor uns. Also halten Sie gerne Ausschau nach den Gewinnern unserer kommenden Finanzierungsrunde von FOSS – oder noch besser: schließen Sie sich unserem Team ZEISS an, um unser innovatives Produktportfolio unter Verwendung von FOSS auf die nächste Stufe zu heben!

Verteiltes Arbeiten – Ein Erfahrungsbericht zur praktischen Anwendung von Remote Mob Testing

Qualitätssicherung

Innerhalb von ZEISS Digital Innovation (ZDI) gibt es in regelmäßigen Abständen eine interne Weiterbildungsveranstaltung – den sogenannten ZDI Campus. Dabei präsentieren wir als Mitarbeiterinnen und Mitarbeiter Softwareentwicklungsthemen mittels Vorträgen, Workshops oder Diskussionsrunden.

Katharina hatte beim vergangenen ZDI Campus schon einmal über kollaborative Testmethoden berichtet und auch Blogartikel bezüglich Remote Pair Testing sowie Remote Mob Testing veröffentlicht. Daher wollten wir das Thema gern auf dem nächsten ZDI Campus weiterführen und einen Workshop aus der Themenwelt kollaborativer Testmethoden anbieten. Aufgrund der Covid-19-Pandemie musste der nächste Campus jedoch online stattfinden. Dennoch wollten wir mehreren Teilnehmerinnen und Teilnehmern die Möglichkeit bieten, eine Testmethode am praktischen Beispiel anzuwenden und haben uns daher für einen remote Mob Testing Workshop entschieden.

Doch es gab eine Herausforderung: Wir hatten noch nie mit so vielen Personen im Mob remote gearbeitet!

Aufbau des Workshops

Wie in dem Blogbeitrag über Remote Mob Testing beschrieben ist es sinnvoller, kleine Gruppen aus vier bis sechs Personen zu betreuen. Durch das verteilte Arbeiten kann es sonst häufiger zu Verzögerungen durch technische Probleme (z. B. schlechte Verbindung, schlechte Tonqualität) kommen, was die Einsatzzeit des jeweils aktuellen Navigators verkürzen könnte. Auch kann man als Facilitator bei kleineren Gruppen besser den Überblick behalten und die Teilnehmenden können die Rolle des Navigators oder Drivers häufiger einnehmen.
(Zur Erläuterung der verschiedenen Rollen siehe ebenfalls Blogbeitrag Remote Mob Testing)

Unser Setting sah wie folgt aus:

Microsoft Teams als Kommunikationsplattform
Leicht verständliches Testobjekt (Website)
3 Facilitators
39 Teilnehmerinnen und Teilnehmer aus den Bereichen QA, Entwicklung und Business Analyse
Zeitlicher Rahmen: 1,5 h

Weil wir allen die Möglichkeit geben wollten, das Mob Testing selbst an einem praktischen Beispiel kennenzulernen, haben wir im Vorfeld des Workshops keine Teilnehmerbegrenzung festgelegt. Schlussendlich hatten alle drei Facilitators über 12 Teilnehmerinnen und Teilnehmer.

Person am Schreibtisch, in einer Videokonferenz mit vielen weiteren Personen — *Beim Remote Mob Testing nehmen alle Teilnehmenden einmal die aktive Rolle des Navigators ein.*

Als Testobjekt haben wir eine einfache Website gewählt, damit sich alle auf das Vermitteln bzw. Kennenlernen der Testmethode konzentrieren konnten und sich nicht noch zusätzlich Wissen über die Anwendung aneignen mussten.

Feedback

Schon während der Durchführung des Workshops fiel uns auf, dass die Wartezeiten, bis eine aktive Rolle (Driver oder Navigator) eingenommen wird, als unangenehm empfunden werden könnte.

Dies wurde auch in der Feedbackrunde angesprochen. Daher empfehlen wir, dass der Mob bei Testideen mit unterstützt. Es bedeutet nämlich nicht, dass man sich als Mob-Mitglied zurücklehnen und mit den Gedanken abschweifen kann. Das vermeidet auch doppeltes Testen oder sich die Blöße geben zu müssen, nicht aufgepasst zu haben.

Teilweise fiel es einigen Teilnehmenden am Anfang schwer, sich bei der Rolle des Drivers darauf zu konzentrieren, nur die Anweisungen des Navigators auszuführen und eigene Testideen zurückzuhalten. Durch entsprechende Hinweise des Facilitators gewöhnten sich die Teilnehmerinnen und Teilnehmer jedoch nach einiger Zeit daran. Dieser Aspekt des Mob Testings wurde als sehr positiv empfunden, weil alle in der Rolle des Navigators zu Wort kommen und eigene Testideen einbringen können.

Dennoch kam die Frage auf, warum die Rollen Navigator und Driver nicht zusammengefasst werden können. Dazu lässt sich Folgendes sagen: Es fördert den Lernprozess, wenn ein Mitglied Schritt für Schritt artikuliert, was es vorhat. So bindet man mehr Teilnehmerinnen und Teilnehmer in diese aktive Rolle ein. Durch das Mitteilen des Ziels wird es den Teilnehmenden erleichtert, den Ideen des Navigators zu folgen. Andernfalls kann es passieren, dass einige Schritte zu schnell und mit zu wenig Erklärung durchgeführt werden. Dadurch ginge die Nachvollziehbarkeit verloren und dem Mob würde es erschwert, sich aktiv einzubringen.

Weiteres positives Feedback gab es zur Rolleneinteilung und dem gesamten Vorgehen. Den Aussagen der Befragten nach erhalte man die Testansätze zum Teil durch den Weg, den der vorherige Navigator eingeschlagen hat und betrachtet daher das Testobjekt aus den unterschiedlichsten Blickwinkeln. Aus diesem Grund ist es immer sinnvoll – je nach Zweck der Mob Testing Session – Teilnehmerinnen und Teilnehmer mit unterschiedlichen Kenntnissen einzuladen. Das erhöht den Lernprozess und die Anzahl der Testfälle. Das einfache Beispiel-Testobjekt habe zudem geholfen, sich auf die Methode zu konzentrieren und sie zu verinnerlichen.

Sehr positiv hervorgehoben wurde das kollaborative Arbeiten beim Mob Testing. Dadurch wird der agile Gedanke gelebt.

Lösungsansatz für eine große Teilnehmerzahl

Das Problem einer zu hohen Teilnehmeranzahl könnte man lösen, indem man im Vorfeld die Gruppengröße begrenzt oder aber eine neue Rolle einführt: die Rolle des Zuschauers. Dabei würde dann eine Trennung zwischen aktiven Teilnehmern und Teilnehmerinnen einerseits sowie Zuschauerinnen und Zuschauern andererseits vollzogen. Die Teilnehmenden würden das oben beschriebene Vorgehen durchführen und sich an die Rollenverteilung (Navigator, Driver, Mob) sowie den Rollenwechsel halten. Die Zuschauerinnen und Zuschauer würden nur beobachten und nicht teilnehmen. Auch Kommentare von ihnen wären nicht erlaubt, weil das bei einer hohen Zuschauerzahl die aktiven Teilnehmenden stören könnte.

Fazit

Alles in Allem ist der Workshop auf der Campus-Veranstaltung sehr gut angekommen und hat gezeigt, dass es sehr gut möglich ist, Mob Testing auch remote und somit für das verteilte Arbeiten anzuwenden. Durch diese Möglichkeit kann das Zusammenarbeiten beibehalten werden, auch wenn es nicht immer möglich ist, sich vor Ort zu treffen.

Dieser Beitrag wurde verfasst von:

Maria Petzold

Maria Petzold arbeitet seit 2010 bei der ZEISS Digital Innovation. Als Testmanagerin liegt ihr Fokus auf der Qualitätssicherung von Software. Vor allem in medizinischen Softwareprojekten konnte sie ihre Test-Erfahrungen sammeln.

Alle Beiträge des Autors anzeigen

UI-Dev-Session (Teil 1) – UI-Fehler im Team effizient lösen

Das zentrale Ziel eines jeden Styleguides ist es, ein einheitliches Erscheinungsbild und eine konsistente User Experience (UX) über mehrere Anwendungen hinweg zu gewährleisten. Für Anwendungen der ZEISS Gruppe gibt es aus diesem Grund detaillierte Vorgaben, wie ein User Interface (UI) auszusehen und sich zu verhalten hat. Jede Anwendung, die veröffentlicht und kommerziell genutzt werden soll, muss diese Vorgaben erfüllen.

Abbildung 1 verdeutlicht die Komplexität und die vielfältigen Zustände, die sich selbst hinter sehr einfachen UI-Elementen verbergen. Die Aufwände für die korrekte Umsetzung solcher Zustände sind meist versteckt und werden bei der Anwendungsentwicklung gerne übersehen bzw. gegenüber der Implementierung von Funktionen niedriger priorisiert.

Grafik, die die verschiedenen Zustände eines Buttons im ZEISS Styleguide zeigt — *Abbildung 1: Verschiedene Zustände eines Buttons im ZEISS Styleguide*

Mit fortgeschrittener Projektlaufzeit sammeln sich kleine Abweichungen vom Styleguide, die das Gesamtbild schnell trügen. Weitere klassische Beispiele für solche UI-Fehler sind:

Fehlende Zustände von UI-Elementen (Hover, Focused, …)
Falsche Verwendung von Schriftgrößen, Schriftschnitten und Schriftfarben
Falsche Verwendung von Graustufen für Flächen, Umrandungen oder Trennlinien
Falsche Abstände und Positionierungen von UI-Elementen

Zwar können solche Abweichungen meist schnell behoben werden, aber häufig sorgen umfangreiche Erstellungs- und Abnahmeprozesse für einen unverhältnismäßig großen Aufwand bei solchen vergleichsweise kleinen Anpassungen. Kommt es zusätzlich zu Missverständnissen oder Missinterpretationen der Designvorgaben und werden dabei mehrere Feedback-Schleifen benötigt, ist das für alle Beteiligten eine negative Erfahrung.

Um solche kleinen UI-Fehler effektiver und effizienter zu beheben und das Produkt damit stückweise zu verbessern und dem Styleguide anzupassen, haben wir im Team eine unkomplizierte Form der Kollaboration geschaffen und etabliert.

Pair Programming mit Spezialistinnen und Spezialisten für UI/UX

Das Pair Programming wird innerhalb des Entwicklungsteams unseres Projektes schon längst erfolgreich genutzt. Es fördert die Zusammenarbeit und die Qualität des Codes durch das Vier-Augen-Prinzip. Dabei arbeiten zwei Personen aus dem Entwicklungsteam gleichzeitig und direkt am Programmcode. Durch Diskussion, Kritik und das Einbringen neuer Ideen sollen hochwertiger Code erzeugt und Entwicklungszeit eingespart werden.

Dieses Prinzip haben wir uns im Projekt zunutze gemacht und den Kreis der Teilnehmenden um Spezialistinnen und Spezialisten für UI/UX erweitert, um den Entwicklerinnen und Entwicklern direktes Feedback auf ihre Anpassungen am User Interface geben zu können. Die Anforderungen und Änderungswünsche an das User Interface werden durch die Expertinnen und Experten für UI/UX so direkt im Termin kommuniziert und die Änderungen geprüft, statt sie im Backlog zu dokumentieren und darauf zu warten, dass sie irgendwann korrekt umgesetzt werden. Zu den in UI/UX spezialisierten Personen gehören die Verantwortlichen für die Vorgaben an das User Interface, welche maßgeblich an der Entwicklung des Figma-UI-Designs beteiligt sind.

Dem regelmäßigen Austausch in diesem Kreis haben wir den Namen UI-Dev-Session oder kurz einfach nur Dev-Session gegeben. Das Ganze funktioniert sehr gut auch dezentral im mobilen Arbeiten, denn dank Microsoft Teams und seiner Screen-Sharing-Funktion sehen alle teilnehmenden Personen gleichzeitig die Änderungen am Code und dem User Interface.

Um einen Rahmen für das Pair Programming zu schaffen, haben wir dafür folgende „Spielregeln“ aufgestellt:

Es nehmen sowohl Personen aus dem Bereich Entwicklung als auch aus dem Bereich UI/UX teil. Insgesamt besteht die Gruppe aus zwei bis maximal vier Personen. Gemeinsam wird fokussiert nach der Lösung für konkrete UI-Fehler gesucht und live am Code programmiert.

Eine UI-Dev-Session hat von vornherein keinen vordefinierten Umfang. Vielmehr werden die erreichten Ziele durch die zur Verfügung stehende Zeit beschränkt.

Je nach Erfordernis des Projektes soll eine UI-Dev-Session in regelmäßigen Abständen stattfinden und einen klaren zeitlichen Rahmen umfassen. Zum Beispiel können 2-3 Stunden je Sprint, Woche oder Monat für eine UI-Dev-Session vorgehalten werden. Damit soll der zeitliche Aufwand zur Lösung von UI-Fehlern verhältnismäßig und gleichbleibend sein.

Mögliche Themen werden in einer Liste von den Spezialistinnen und Spezialisten für UI/UX gepflegt und iterativ in mehreren UI-Dev-Sessions abgearbeitet. Die Grundlage dafür sind z. B. Abweichungen zwischen Implementierung und Styleguide oder das Feedback aus Usability-Tests.

Das Entwicklungsteam kann Themen aus der Liste frei wählen und ggf. vorab aufbereiten. Dies soll dazu beitragen, dass möglichst viele Themen in kurzer Zeit gelöst werden. Sofern erforderlich, kann dennoch eine Priorisierung der Themen nach größtmöglichem Nutzen erfolgen, damit insbesondere bei engen Zeitrahmen die wichtigsten Themen zuerst gelöst werden.

Die Aktivitäten an unerwartet aufwändigen Themen, deren Live-Implementierung den zeitlichen Rahmen einer UI-Dev-Session sprengen, werden nach Einvernehmen der teilnehmenden Personen gestoppt und in anderweitige Backlog Items (z. B. User Stories oder Spikes) ausgelagert und später bearbeitet.

Die bearbeiteten und gelösten UI-Fehler sollten im Nachgang der UI-Dev-Session dokumentiert und dem Projektteam zugänglich gemacht werden. So kann im Nachhinein jedes Projektmitglied nachvollziehen, was für Änderungen in welcher UI-Dev-Session vorgenommen wurden. Außerdem bietet es sich im Sprint-Review an, dem gesamten Projektteam die bearbeiteten Themen kurz vorzustellen.

Beispiel für Abweichungen von der Implementierung (links) und für Styleguide-konformes Figma-Design (rechts) — *Abbildung 2: Beispiel für Abweichungen von der Implementierung (links)*
*und für Styleguide-konformes Figma-Design (rechts)*

Fazit

Ob klare Abweichungen vom Styleguide, Optimierungen nach Usability-Tests oder anderweitige kleinere Anpassungen am User Interface: Das in diesem Artikel beschriebene Vorgehen zur Durchführung einer gemeinsamen UI-Dev-Session mit Entwicklerinnen und Entwicklern sowie Spezialistinnen und Spezialisten für UI/UX fördert die Zusammenarbeit im Team und kann UI-Fehler schnell und effizient lösen. Der Dokumentationsaufwand soll damit auf ein Minimum reduziert werden und der zeitliche Aufwand für die Durchführung klar definiert sein. Durch iterative Durchführungen der UI-Dev-Sessions wird stückweise die Liste von UI-Fehlern abgearbeitet, wobei im Projektteam ein gegenseitiges Bewusstsein für solche Themen geschärft wird.

Die UI-Dev-Session ist mittlerweile ein bewährtes Mittel in unserem Projekt und fester Bestandteil eines jeden Sprints. Einen ausführlichen Erfahrungsbericht aus unserem Projekt wird meine Kollegin Franziska Kubitz im zweiten Teil dieser Blogartikelreihe beschreiben.

Weihnachtsfeier in Zeiten von Corona: Der 2. ZEISS Digital Innovation Online-Campus

Zusammenarbeit

Bereits im Frühjahr beginnen wir als ZEISS Digital Innovation (ZDI) mit der Planung unserer Weihnachtsfeier, die in der Regel am Freitag vor dem ersten Adventswochenende stattfindet. 2020 stand für uns schnell fest, dass eine Weihnachtsfeier, zu der sonst alle Beschäftigten in Dresden zusammenkommen und gemeinsam feiern, dieses Mal leider nicht möglich sein würde. Die Weihnachtsfeier ausfallen zu lassen, kam für uns jedoch ebenfalls nicht in Frage, sodass wir uns auf die Suche nach einem neuen Format begaben.

Hierbei knüpften wir an unseren 1. ZDI Online-Campus an, zu welchem wir bereits viele positive Rückmeldungen erhalten hatten. Besonders wichtig war uns dieses Mal neben der internen Wissensvermittlung, dass die weihnachtliche Stimmung und das „Wir-Gefühl“ nicht zu kurz kommen sollten. Aber wie bringen wir diese zu unseren Kolleginnen und Kollegen nach Hause?

Eine Karte mit allen Standorten, von denen aus unsere Kolleginnen und Kollegen dem Online-Campus zugeschaltet waren. — *Abbildung 1: Unsere Kolleginnen und Kollegen nahmen von den unterschiedlichsten Standorten am Online-Campus teil.*

Eine kleine Weihnachtsüberraschung für alle Mitarbeitenden

Um verteilt weihnachtliche Stimmung aufkommen zu lassen, haben alle Beschäftigten jeweils ein kleines Weihnachtspäckchen per Post erhalten, mit der Bitte, dieses erst am Tag unseres gemeinsamen Online-Campus zu öffnen.

Die 345 Päckchen wurden von dem Organisationsteam bei stimmungsvoller Weihnachtsmusik eigenhändig gemeinschaftlich verpackt. Wir waren glücklich, dass die Weihnachtsüberraschung bei all unseren Kolleginnen und Kollegen aus Deutschland und Ungarn rechtzeitig zu Hause ankam.

Somit waren alle pünktlich zu unserem 2. ZDI Online-Campus mit weihnachtlichen Leckereien, Glühweingewürz für einen leckeren Punsch, Adventskalender, Weihnachtsmütze und anderen kleinen Aufmerksamkeiten ausgestattet und es konnte losgehen.

2. Online-Campus mit Online-Teamspiel und weihnachtlicher Feierstunde

Mit den positiven Erfahrungen aus unserem 1. ZDI Online-Campus wurden auch dieses Mal verschiedene Vortragsslots von und für unsere Kolleginnen und Kollegen über den gesamten Tag hinweg angeboten. Die technische Umsetzung erfolgte erneut mit Microsoft Teams. Es wurden insgesamt 29 Vorträge zu unterschiedlichen Themen, wie bspw. Java, .NET, Cloud, Usability, Agile und Web, gehalten. Als Lessons Learned passten wir die Dauer der Vortragsslots (45 Minuten statt 30 Minuten) und Wechselpausen (15 Minuten statt 10 Minuten) an. So hatten alle Teilnehmenden zwischen den Slots Zeit durchzuatmen und sich gedanklich auf den nächsten Slot vorzubereiten.

Zeitplan aller Vorträge des 2. ZEISS Digital Innovation Online Campus. — *Abbildung 2: Insgesamt 29 Vorträge in 6 parallel laufenden Slots wurden zu fachverwandten Themen gehalten.*

Nach einer längeren Mittagspause fand unser Online-Teamspiel mit insgesamt 28 Teams bestehend aus jeweils neun bis zehn Teammitgliedern statt. Bei der Teamzusammenstellung wurde auch dieses Mal auf eine möglichst heterogene Gruppenaufteilung hinsichtlich der Reifegrade, Standorte und Geschäftsbereiche geachtet. Zum gegenseitigen Kennenlernen und der anschließenden Lösung der Aufgaben hatte jedes Team einen eigenen virtuellen Teamraum zur Verfügung. Die Aufgaben beinhalteten unter anderem Wissensfragen, Scharade- und Rätselaufgaben sowie die Abstimmung eines weihnachtlichen Teambeitrags, welcher zum Abschluss unseres Online-Campus im Rahmen der gemeinsamen weihnachtlichen Feierstunde von den Teams live aufgeführt werden sollte.

Zum Auftakt der weihnachtlichen Feierstunde wurde zunächst mit leckerem Glühwein und Punsch gemeinsam angestoßen. Im Anschluss waren die jeweiligen Teams mit ihren weihnachtlichen Live-Beiträgen an der Reihe. Von musikalischen und poetischen Darbietungen bis hin zu Weihnachtsgrüßen in verschiedenen Sprachen und weihnachtlichen Filmtipps waren alle Teams kreativ dabei und auch der verfügbare Teams-Chat wurde rege genutzt. Somit kam trotz der Verteilung und damit einhergehenden physischen Distanz eine besinnliche und weihnachtliche Stimmung unter uns auf.

Fazit

Uns allen war bewusst, dass ein Online-Format mit einer virtuellen weihnachtlichen Feierstunde nicht das Gefühl einer real stattfindenden Weihnachtsfeier vor Ort mit Schlittschuhfahren, leckerem Essen, Tanzen und dem lockeren Austausch untereinander ersetzen kann. Dennoch waren wir überrascht, wie viel weihnachtliche Stimmung und Gemeinschaftsgefühl verteilt online entstehen kann. Es hat uns erneut gezeigt, dass wir als starkes Team an einem Strang ziehen und trotz Corona dazu bereit sind, das Beste aus der aktuellen Situation zu machen und gemeinsam neue Wege zu gehen.

Ob wir in diesem Jahr vielleicht wieder mit allen Kolleginnen und Kollegen gemeinsam in Dresden vor Ort ein Sommerfest oder auch eine Weihnachtsfeier veranstalten können, ist ungewiss. Was wir jedoch bereits jetzt prognostizieren können: Unser neues Format des Online-Campus mit dem Online-Teamspiel wird Corona sicherlich überdauern.

Ein Projekt wird agil – Herausforderungen und ihre Lösungen

Qualitätssicherung

Heutzutage kommt keiner in der Software-Branche an dem Begriff „agil“ vorbei. Das war sicher auch der Grund, weshalb in meinem aktuellen Kundenprojekt beschlossen wurde, dass der komplette Prozess neu strukturiert werden soll. Wichtig war vor allem eins: Er sollte agil werden. Das Ziel war eine Verbesserung auf allen Ebenen.

Tatsächlich war und ist die Umstellung eines jahrelangen – und auch irgendwie funktionierenden – Projekts auf ein neues Vorgehen nicht gerade das Einfachste, was sich ein Team vornehmen kann. Das mussten nicht nur der Product Owner (PO) und die Entscheidungsträger erfahren, sondern insbesondere die Entwickler und Tester. Während der noch andauernden Umstellung sind u. a. uns Testern Punkte aufgefallen, die verändert werden mussten. Diese möchte ich hier gern reflektieren, da sie anderen Teams in ähnlichen Situationen hilfreich sein könnten.

Für unser Team waren diese Herausforderungen zwar viel Arbeit, aber diese zu bewältigen, war schlussendlich ein wichtiges Erfolgserlebnis.

Neuer Refinement-Prozess und fehlende Akzeptanzkriterien

Etwas, das grundlegend neu definiert wurde, war der komplette Workflow – von Anforderungsdefinition über die Entwicklung bis hin zum Testen der Anwendung. Hier wurde ein neuer Refinement-Prozess eingeführt, der durch eine feste Struktur der JIRA-Tickets eine bessere Bearbeitung der Aufgaben gewährleisten sollte.

Um diese standardisierten Inhalte festzulegen, wurde das Team von Entwicklern und Testern leider nicht mit einbezogen. Das führte dazu, dass bei den ersten Durchläufen nach dem neuen Vorgehen die Akzeptanzkriterien fehlten. In den Tickets stand keine Definition, gegen die getestet werden konnte.

Verbesserungsvorschlag

In unserem wöchentlichen Tester-Standup brachten wir zur Sprache, dass ein Arbeiten nach diesem Vorgehen für die Tester nicht adäquat möglich sei. Wir wiesen außerdem darauf hin, dass es sinnvoll wäre, die Mitarbeiter im Projekt einzubeziehen, um die Inhalte für das Refinement zu definieren. Wir schlugen vor, dass sowohl die Fachabteilung als auch die Entwickler und Tester ihre Anforderungen an ein gutes Ticket formulieren sollten, um daraus eine Definition of Ready (DOR) Richtlinie ableiten zu können.
Dieser Vorschlag wurde zeitnah umgesetzt und angewandt. Die Akzeptanzkriterien für den Test sind nun fester Bestandteil der Tickets und es kann ohne Nachfragen dazu getestet werden.

Einbindung des Teams und Leben der agilen Vorgehensweise

Ein weiteres Problem, das mit dem ersten Thema einherging, war der fehlende Dialog mit den Teammitgliedern. Am Anfang wurde die Umstellung auf das agile Vorgehen lediglich „von oben“ delegiert. Schon allein dieser Fakt spricht gegen ein agiles Vorgehen, bei dem der Mensch im Fokus stehen soll. Zusätzlich wurde eine beliebige Methodik über das existierende Projekt und seine Mitarbeiter gestülpt. Das traf verständlicherweise auf Widerstand. Die Kollegen fühlten sich nicht nur übergangen, sondern wurden in eine Prozess-Schablone gepresst, die weder auf das Projekt zugeschnitten war, noch zu den Mitarbeitern passte. Die allgemeine Stimmung im Projekt war angespannt und das Arbeiten ineffektiver.

Ein Tester ist die letzte Station im Entwicklungsprozess der Software, bevor diese letztlich den Kunden erreicht. Dazu müssen wir uns in die Fachabteilung und ihre Belange hineinversetzen, mit den Entwicklern, dem PO sowie anderen Abteilungen abstimmen und dabei immer die Qualität an die erste Stelle setzen. Zudem kommt jeder vorab im Prozess enthaltene Fehler potenziert beim Tester an. Das bringt uns den entscheidenden Vorteil, dass wir den Überblick über den ganzen Prozess gewinnen, weil wir aus jedem Bereich ein kleines Stück erfahren. Somit fällt uns auch die Reflektion eventueller Schwachstellen leichter.

*Abbildung 1: Bereichsübergreifende Gespräche zur erfolgreichen Einführung eines agilen Prozesses*

Verbesserungsvorschlag

Diesen Vorteil haben wir genutzt und den PO informiert, dass während der Einführung eines agilen Prozesses unbedingt die Mitarbeiter einbezogen werden müssen. Schließlich sind es die Mitarbeiter, die den neuen Prozess tragen und leben sollen. Weiterhin ist es wichtig, nicht eine Methode X zu betrachten und sie Eins zu Eins auf das Projekt zu übertragen. Aus unserer jahrelangen Projekterfahrung konnten wir berichten, dass die Methodik zum Projekt und den Mitarbeitern passen muss, um effektiv zu sein. Und dazu ist es wichtig, dass nicht nur eine einzige Methode ins Auge gefasst wird, sondern mehrere Vorgehen kombiniert und kleine Stücke schrittweise angepasst und ausprobiert werden.

Auch dieser Vorschlag wurde ernst genommen und mehrere Meetings anberaumt, um Unstimmigkeiten zu klären und Schwachstellen zu eliminieren. Es wurden To-dos definiert und der Dialog gesucht. Die Stimmung im Projekt hat sich dadurch maßgeblich entspannt und das Arbeiten funktioniert wieder flüssiger.

Das Stiefkind Automatisierung

Während der Prozess-Umstellung sollte auch der wichtige Punkt der Automatisierung ernster angegangen werden. Vom Tester bis hin zu den Entscheidungsträgern waren sich alle einig über die Wichtigkeit und Dringlichkeit dieses Themas. Allerdings verschwand das Thema aufgrund der vielen Schwierigkeiten während der Einführung des neuen Prozesses von der Agenda.

Verbesserungsvorschlag

Zunächst wurde seitens des Tests immer wieder nachgehakt, aber auch Informationen gesammelt sowie Tools empfohlen und diese auf Tauglichkeit geprüft. Der Kontakt zu Schlüsselpersonen, die mit diesem Thema verknüpft sind, wurde aktiv gesucht. Hier war besonderes Fingerspitzengefühl gefragt, um zuweilen den richtigen Moment abzupassen. Alle Informationen wurden regelmäßig an den PO gemeldet und in regelmäßigen Abständen nach dem Fortschritt dieser Maßnahme gefragt.

Diese Hinweise wurden ebenfalls aufgenommen und das Thema weiter oben auf der Agenda platziert. Der PO beraumte Treffen mit den Entscheidungsträgern an und wird sich weiterhin für eine Vorankommen im Bereich der Automatisierung einsetzen. Die Festlegung auf ein Tool, die Eingliederung in den Prozess sowie die Frage der personellen Aufstockung stehen noch aus.

Fazit

Zusammenfassend hat sich meine Erfahrung bestätigt, dass die Umstellung bestehender Prozesse auf ein anderes Vorgehen nur mit psychologischem Geschick, dem Fokus auf das Wesentliche und im Dialog mit den Teammitgliedern gelingen kann. Eines braucht eine solche Umstellung jedoch immer: Genügend Zeit. Darum ist es zwar wichtig, einen Prozess voranzutreiben – mindestens genauso wichtig ist es jedoch, den richtigen Momenten abzuwarten, um zum richtigen Zeitpunkt das volle Potenzial zu nutzen und Chancen zu ergreifen.

Als Tester in diesem Kundenprojekt konnte ich beobachten, dass es für eine Umstrukturierung empfehlenswert ist, einige Beteiligte auf allen Ebenen eines Projekts zu haben, die bereits agil gearbeitet haben. So können deren Erfahrungen mit einbezogen werden und einen wichtigen Beitrag zur erfolgreichen Umsetzung leisten. Gegebenenfalls kann dazu auch externe Unterstützung eingeholt werden. Rückblickend war es in diesem Kundenprojekt von Vorteil, dass sowohl die ZEISS Digital Innovation GmbH als auch ich selbst auf unsere Erfahrungen mit agilen Vorgehensweisen zurückgreifen konnten.

Vertrieb ohne Kaffee – unmöglich!?

Zusammenarbeit

Wenn man in den Vertrieb wechselt, wird eine Sache schnell klar: Der Kaffeekonsum wird steigen. Denn wenn der Kunde fragt, ob man einen Kaffee möchte – wer beginnt dann schon gern ein Kennenlernen mit einem „Nein“?

Der Kaffee ist in der Regel der Teil des Small Talks, der zu Beginn der meisten Vertriebstermine eine positive Basis für das erste Treffen schafft. Beim Gespräch über den Kaffee, die Sorte, die Zubereitungsart etc. sowie auf dem gemeinsamen Weg zur Kaffeeecke lernt man sich kennen und baut eine erste Beziehung zueinander auf. Eine Basis, die man schätzen lernt.

Tasse Kaffee und Brille im Büro-Arbeitsumfeld

Zumindest war das bisher so – doch dann kam Corona! Nicht nur, dass durch den Wegfall von Flügen der Weg zu den Kunden erschwert wurde, so machte sich im ersten Moment auch Ratlosigkeit breit. Wie können wir neue Themen bei bestehenden oder neuen Kunden identifizieren? Wie können wir Themen bei sinkenden Budgets und Umpriorisierungen für uns entscheiden, ohne vor Ort zu sein? Wie bauen wir das notwendige Vertrauen zueinander auf, ohne gemeinsam an einem Tisch gesessen zu haben?

Vor allem auch für den Dienstleistungssektor schienen diese Hürden zunächst unüberwindbar zu sein – zum Glück jedoch nur im ersten Schritt. Denn wie auch in anderen Unternehmensbereichen der ZEISS Digital Innovation haben wir uns im Vertrieb und im Bereich der Positionierung angeschaut, welche Werkzeuge unsere Entwicklungsteams nutzen, die schon seit vielen Jahren standortverteilte Softwareentwicklung betreiben. Und davon haben wir uns inspirieren lassen.

Der 14-tägige Abgleich aller Vertriebskollegen wurde ohnehin schon immer verteilt gelebt und durch unser CRM (SalesForce) unterstützt. Doch darüber hinaus sind wir auch in unserem Neukundenvertrieb inkl. Marketing-Team zu einem Daily-Modus gewechselt. So haben wir unseren Vertriebssprint von vier Monaten auf vier Wochen reduziert. D. h. morgens 9:30 Uhr synchronisiert sich das Marketing-Team entlang der Kampagnen mit dem Neukundenvertrieb und spricht über Ergebnisse, To-dos und Herausforderungen. Alle vier Wochen finden dann eine Retro, ein Review und ein Planning statt, in denen wir die vergangenen vier Wochen abschließen und reflektieren sowie die folgenden Wochen planen. Der neue Vier-Wochen-Rhythmus war notwendig, da Ende März 2020 noch niemand sagen konnte, welche Themen wir im Juni prioritär bearbeiten müssten – dies wäre jedoch eine nötige Voraussetzung gewesen, um den bis dahin genutzten Vier-Monatszyklus aus der Zeit vor Corona weiterführen zu können.

Damit wir die neuen verteilten Dailys auch aus dem Homeoffice leben konnten, kamen zu Beginn Skype for Business und der Microsoft Planner zum Einsatz. Später sind wir dann auf MS Teams umgeschwenkt und haben punktuell das zugehörige MS Whiteboard für die inhaltliche Arbeit herangezogen.

Dadurch haben wir nun ein Tool-Set, welches sich auch im Zusammenspiel mit Kunden in den letzten Wochen als sehr positiv erwiesen hat. MS Teams ist gefühlt in allen Organisationen angekommen und die Bereitschaft aller in der Nutzung von Conferencing-Tools ist um ein Vielfaches höher, sodass man schnell und unkompliziert diesen Weg beschreiten kann. Was wir als besonders positiv empfinden, ist die Bereitschaft, sich bei einem Meeting nicht nur über Audio auszutauschen, sondern auch den Videostream anzuschalten. Denn den Videostream zwischen den Beteiligten könnte man auch als das „Ersatzkaffeetrinken“ beschreiben – es gibt beiden Seiten ein besseres Gefühl füreinander und reduziert Interpretationsprobleme, die man in Telefonkonferenzen sonst oft hat. Gerade mit neuen Kunden oder neuen Ansprechpartnern ist dieses Vorgehen ein echter Segen für die folgende Zusammenarbeit.

Doch auch in den Projektvorphasen mussten wir unsere Rituale etwas anpassen. So konnten wir u. a. keinen zweitägigen Projektvisionsworkshop mit dem Kunden an einem Ort durchführen. Alternativ sind es nun 4 x 0,5 Tage mit jeweils 2x 2 h Sessions in MS Teams, die mit Hilfe eines Microsoft Whiteboards direkt und für alle sichtbar und editierbar dokumentiert werden. So war es uns möglich, mehrere Projekte auch in der Corona-Zeit anzugehen – sogar mit neuen Kunden, die vorher noch nie mit uns zusammengearbeitet hatten.

Das Ganze ist ein neues Szenario, welches für uns im Vertrieb immer noch etwas unwirklich und seltsam wirkt und den Vertrieb sicher nachhaltig verändern wird. Am Ende trinken wir wieder zusammen Kaffee – jedoch jeder an seinem Arbeitsplatz und verbunden durch MS Teams, Skype und Co.

Agile Unternehmensführung bei der ZEISS Digital Innovation

Zusammenarbeit

Mit Zusammenarbeit, Transparenz und Mitarbeiterbeteiligung zum Unternehmenserfolg! Unser Weg zu einem agileren und wieder nachhaltig erfolgreichen Unternehmen begann mit der Veränderung der Unternehmensführung.

Warum mussten wir uns verändern und neue Wege gehen?

Nach der Gründung der Saxonia Systems AG, seit März 2020 ZEISS Digital Innovation, wuchs das Unternehmen kontinuierlich. Doch in den Jahren 2008 und 2009 verursachten die Krise in der Halbleiterindustrie und die nahezu zeitgleich ausgebrochene Finanzkrise starke Umsatzeinbußen. Die Saxonia Systems erwirtschaftete damals einen sehr großen Umsatzanteil in der Halbleiterindustrie, wodurch sie schließlich Mitte 2010 den Höhepunkt ihrer Unternehmenskrise erreichte. Die Hauptgründe für die bedrohliche Lage waren die unzureichende Zusammenarbeit im Management aufgrund der in der Vergangenheit entstandenen „Fürstentümer“, die fehlende Strategie und Zielrichtung sowie eine mangelnde Fokussierung im Produktportfolio.

*Abbildung 1: Herausforderungen unseres Unternehmens*

Wo haben wir den Hebel für unsere Veränderung angesetzt?

Die Unternehmensleitung war fest davon überzeugt, dass es einer neuen Form der Zusammenarbeit und Führung bedarf – und das prinzipiell auf allen Ebenen, jedoch im ersten Schritt im Management. Das Management sollte von nun an als Team agieren, getreu dem Motto „Gemeinsam sind wir stark und können alles schaffen“. Dem damals gegründeten Strategieteam war bewusst, dass die skizzierten Herausforderungen operativ nicht lösbar sind. In der Vergangenheit befand sich jede einzelne Führungskraft im operativen Hamsterrad. Um dieses verlassen zu können, musste der Hebel eine Ebene höher angesetzt werden – bei der strategischen Unternehmensführung. Wenn dort etwas bewirkt wird, hat das positive Auswirkungen auf alle anderen Führungsdisziplinen wie die Selbstführung, die Mitarbeiterführung und die operative Unternehmensführung. Eine Strategiearbeit, die auf die Mitwirkung der Mitarbeiter setzt, verändert alle Führungsbereiche. Nur so lassen sich eine Vision und die Unternehmensziele gemeinsam entwickeln und vereinbaren. Diese Erkenntnis hat das Management in die Praxis umgesetzt und bis heute trifft sich das Strategieteam dreimal im Jahr zu einem 2-tägigen Strategiemeeting. Hier werden gemeinsam die für das Unternehmen aktuell wichtigsten Themen bearbeitet.

Schaubild Strategische Unternehmensführung, Operative Unternehmensführung, Mitarbeiterführung, Selbstführung — *Abbildung 2: Hebel der Veränderung bei der strategischen Unternehmensführung*

Nur mit einem Strategieteam war es aber nicht getan, auch an der Form der Zusammenarbeit musste gefeilt werden. Das Strategieteam musste sich überlegen, wie in Zukunft alle gemeinsam disziplinierter und konsequenter werden können, damit eben Strategie nicht für die Schublade gemacht wird. Agilität kannte und erlebte die ZEISS Digital Innovation bereits in ihren operativen Einheiten in agilen Softwareentwicklungsprojekten. Sollte agil auch im Management gehen? Die Antwort ist ganz klar: Ja!

Dem Strategieteam blieb schließlich auch nichts anderes übrig. Um die anstehenden Herausforderungen zu meistern, musste das Management viel enger zusammenarbeiten, flexibler, schneller und somit eben auch agiler werden. Folglich wurde Scrum als das Vorgehen in agilen Softwareentwicklungsprojekten auch für das Management im Unternehmen adaptiert. Entstanden ist dabei der agile Strategieprozess.

Was ist durch kontinuierliche Zusammenarbeit und Verbesserung entstanden?

Im Laufe der letzten 10 Jahre hat sich durch kontinuierliche Verbesserung in der Strategiearbeit ein Best Practice Framework entwickelt. Darin enthalten sind innovative und praktikable Ansätze, Methode, Prinzipien und Werkzeuge, mit denen das Unternehmen alle bisherigen Herausforderungen gemeistert hat. Auch in Zukunft soll das Framework die Strategiearbeit der ZEISS Digital Innovation unterstützen. Der agile Strategieprozess ist das Fundament für die permanente Transformation in unserem Unternehmen und wichtigstes Element für die neue Form der hierarchie-, bereichs- und standortübergreifenden Zusammenarbeit.

Das evolutionär entstandene Framework beinhaltet alle Erfolgsfaktoren, die es erlauben, langfristige Unternehmensziele flexibel zu erreichen:

Ein zu erreichendes Unternehmensziel und eine Strategie zum Erreichen
Eine am Unternehmensziel ausgerichtete Führung und Zusammenarbeit
Ein iteratives, konsequentes und diszipliniertes Vorgehen, zur Umsetzung der priorisierten strategischen Initiativen
Gemeinsame Werte und Prinzipien

*Abbildung 3: Unser Best Practice Framework – evolutionär seit 2010 entstanden*

Wichtig ist, Transparenz zu diesen vier Punkten im gesamten Unternehmen zu schaffen sowie permanent an ihnen zu arbeiten – das baut Vertrauen bei den Mitarbeitern auf. Erst wenn allen klar ist, wohin die Reise geht und wie der Zielrahmen aussieht, ist es möglich, alle Kräfte, Energien und eigenverantwortliches unternehmerisches Handeln aller im Unternehmen zu bündeln. Insbesondere die Transparenz zum Ziel bildet die Grundlage für alle Mitarbeiter, mitzudenken und den Weg dahin mitgestalten zu können. Durch diese Transparenz werden Doppelarbeiten vermieden, Wissen geteilt und der Kreativität der Mitarbeiter Input gegeben. Sehr oft entstehen dadurch neue wertvolle Ideen für die Weiterentwicklung des Unternehmens.

Mit dem iterativen, schrittweisen Vorgehen und der Möglichkeit der aktiven Beteiligung an der Unternehmensentwicklung, werden die Mitarbeiter kontinuierlich auf die Reise der Veränderung hin zu unserem Unternehmensziel mitgenommen. Der permanente Wandel im Unternehmen wird so für Sie zur Normalität. Somit werden Commitment, Bindung und eigenverantwortliches Handeln ermöglicht. Intrinsisch motivierte Mitarbeiter sind zu Großem fähig.

Wie haben wir uns seit 2010 verändert?

Dass unsere hochgesteckten Ziele so schnell realisiert werden konnten, hat jedoch niemand aus dem Strategieteam sowie dem mittleren Management der heutigen ZEISS Digital Innovation erwartet. Die ausgesprochen erfolgreiche Entwicklung kann mit einigen Ergebnissen, Fakten und Zahlen noch untermauert werden.

2010

Heute

IT-Dienstleister für alles
mit Geschäftsmodell Consulting

Spezialist für
Individualsoftwareentwicklung
agile Softwareentwicklungs-projekte mit eingespielten Teams an firmeneigenen Standorten

160 Mitarbeiter

Piktogramm: Hände halten sich aneinander fest

300 Mitarbeiter

Abgerutscht von 17,3 auf 12,9 Mio. € Umsatz

-500 T€ EBIT

35 Mio. € Umsatz

3,5 Mio. € EBIT (Ergebnisse 2019)

Kaum bereichs-
übergreifende Zusammenarbeit

Intensive, bereichs-
übergreifende strategische und operative Zusammenarbeit

Keine gemeinsame Vision und Strategie, fehlende Transparenz

Zielbild, Strategie, Strategieprozess

365 Tage Transparenz zum Wohin, Warum, Wie und Was

Gemischtwarenladen, fehlende Fokussierung und Nachhaltigkeit

Piktogramm: Pfeil steckt in der Mitte einer Zielscheibe

Seit 2010 in Summe 70 Initiativen abgeschlossen, aktuell laufen 5, ausgezeichnet für Portfolioattraktivität

Wenig Veränderungs-
fähigkeit

Piktogramm: Ziffernblatt mit Pfeilen, die im Kreis darum herumführen

Wandel ist Normalität

Information und Kommunikation an die Mitarbeiter zweimal pro Jahr auf interner Konferenz und Weihnachtsfeier

Piktogramm: zwei Sprechblasen mit einem Fragezeichen in der einen und einem Ausrufezeichen in der anderen

Intensive 14-tägige unternehmensweite Information und Kommunikation über Strategie-/ZDI-Standups für alle Mitarbeiter

Keine Beteiligung von Mitarbeitern an der Unternehmens-
weiterentwicklung

Piktogramm: 2 Personen, von denen eine die Hand hebt, sprechen vor Publikum

Jeder Mitarbeiter, der möchte, kann sich in Strategischen Initiativen engagieren – Mitarbeiter gestalten den Weg zur Vision mit

Kultur von Fingerpointing, Monopolen, Macht ausbauen, Inkonsequenz, Lästern, Tuscheln, jeder macht seins, Misstrauen …

Piktogramm: eine Person steht mit verschränkten Armen im Vordergrund, hinter ihr stehen vier weitere Personen

Miteinander, Offenheit, Respekt, Wertschätzung, Spaß, Emotionen, Eigenverantwortung, Commitment, Vertrauen, Dialog, …

Saxonia Systems AG

Piktogramm: 2 Personen geben sich High Five, zwei weitere Personen stehen im Hintergrund

ZEISS Digital Innovation

Ein Teil der ZEISS Gruppe

Warum hilft uns dieses Vorgehen so sehr?

Das aus unseren positiven wie negativen Erfahrungen entwickelte Vorgehen hilft uns, in der sich permanent verändernden Welt Schritt zu halten oder sogar ein Schritt voraus zu sein. Wir können uns schnell und flexibel anpassen und ausrichten, ohne dabei unsere Ziele aus den Augen zu verlieren. Wir bündeln unsere Kräfte und fokussieren diese jeweils auf die hoch priorisierten und nutzenstiftenden Themen für unsere kontinuierliche Weiterentwicklung.

Mit Zusammenarbeit, Transparenz und Mitarbeiterbeteiligung zum Unternehmenserfolg!

Schaubild VUCA Welt - Volatility, Uncertainty, Complexity, Ambiguity — *Abbildung 4: Nutzen des Frameworks*

Das Unternehmen hat im Rahmen der Ende 2010 eingeleiteten permanenten Transformation viel erreicht, kann und wird sich darauf aber nicht ausruhen. Wichtige Basiselemente für den Erfolg, die auch weiterhin unser stetiger Begleiter sind, werden in weiteren Beiträgen dieser Reihe eine Rolle spielen.

Zusammenarbeit in Zeiten von Corona – was wir alle von der agilen Softwareentwicklung lernen können

Zusammenarbeit

Die aktuelle Krise, ausgelöst durch COVID-19, beschäftigt nun schon seit vielen Wochen die Welt und stellt viele Unternehmen vor neue Herausforderungen. Von jetzt auf gleich zogen auch bei uns fast 95 % der Mitarbeiter für mehrere Wochen komplett ins Homeoffice um und arbeiten größtenteils immer noch viel von zu Hause aus. Wie hat sich das insbesondere auf meine Arbeit im Sales und Marketing Team ausgewirkt?

Während die verteilte und ortsunabhängige Arbeit in den Projektteams schon in großen Teilen zum Alltag gehört (siehe auch der Blogbeitrag „Softwareentwicklung in Zeiten von Corona – Business as usual?“), war dies allerdings in den zentralen Diensten (Buchhaltung, IT, Personal, Marketing, …) eine Neuerung. Als interner zentraler Dienstleister für die Mitarbeiter der ZEISS Digital Innovation lag der Fokus hier immer darauf, vor Ort zu sein, um direkt auf die Anliegen der internen „Kunden“ reagieren zu können. Zeitgleich mit unserer Angliederung ans Team ZEISS und dem damit verbundenen sehr hohen Workload durch den Brand Change, stellte uns der Wechsel ins heimische Office somit vor zusätzliche Herausforderungen.

*Abbildung 1: Mein Arbeitsplatz im Homeoffice*

Wie haben wir es dennoch geschafft, diesen Übergang nahezu reibungslos zu meistern und die Performance hoch zu halten? Indem wir uns auch hier an Vorgehensweisen aus der agilen Welt orientiert haben!

Bereits seit vielen Jahren setzen wir sowohl beim Vorgehen in den Projekten als auch im Management auf agile Methoden und haben dort nicht nur ein eigenes Vorgehensmodell entwickelt, sondern auch für die Zusammenarbeit in den zentralen Diensten verschiedenste Werte, Artefakte und Arbeitsweisen adaptiert. Diese helfen uns in dieser schwierigen Phase sowohl im Allgemeinen bei der internen Kommunikation der ZEISS Digital Innovation als auch im Speziellen bei der Zusammenarbeit in meinem Team, welches momentan aus fünf Personen besteht. Hierbei ist wichtig zu erwähnen, dass wir uns nur an diesen Arbeitsweisen ORIENTIEREN und diese nicht 1:1 nach Lehrbuch umsetzen, sondern für unser Unternehmen angepasst haben.

Durch ein iteratives Vorgehen inkl. Planning, Review und Retrospektiven stellen wir sicher, dass unsere Kampagnen innovativ bleiben, wir uns auch bei sehr vielen parallelen Kampagnen auf die richtigen Dinge fokussieren und uns vor allem auch regelmäßig hinterfragen. Reflexionstermine nach unseren Kampagnen (ähnlich Projekt-Retros), aus denen wir Lessons Learned ableiten, gehören dabei für uns ebenso dazu wie eine offene Kommunikation, ehrliches Feedback sowie Kreativtermine und Brainstorming-Runden zu neuen Themen. Kreatives Arbeiten und ein agiles Mindset setzen daher ohnehin schon eine gewisse Bereitschaft zur Anpassung voraus, so dass wir es geschafft haben, unsere Zusammenarbeit schnell neu zu organisieren und uns an die neuen Gegebenheiten anzupassen.

*Abbildung 2: Team-Retro mit improvisiertem Whiteboard*

Doch was heißt das nun konkret? Welche „Hilfsmittel“ haben uns geholfen, uns trotz Homeoffice und Verteilung zu organisieren?

Dailys

Da wir uns nicht mehr jeden Tag direkt im Büro gegenübersitzen und man natürlich so nicht mitbekommt, an welchen Themen der jeweils andere arbeitet, haben wir schnell festgestellt, dass aufgrund der Verteilung ein erhöhter Abstimmungsbedarf entsteht. Um dem entgegenzuwirken, haben wir nach sehr kurzer Zeit Dailys eingeführt. Jeden Morgen synchronisiert sich das Team kurz (wir haben für uns 20 min definiert) über die anstehenden Tagesaufgaben und die erledigten Arbeitspakete des vorherigen Tages. Wichtig ist hier insbesondere, dass JEDER zu Wort kommt und auch kurz erzählt, ob es bei ihm ggf. Herausforderungen gibt, die die Arbeit behindern könnten (Meeting-Marathon, Kinderbetreuung, …). Unter anderem um sicherzustellen, dass die Timebox eingehalten wird, moderiert der im Team ernannte Scrum Master das Daily. Dieser hat insbesondere auch darauf zu achten, dass eventuell aufkommende Diskussionen im Anschluss in separaten AdHoc Meetings weitergeführt werden und nicht das Daily blockieren.

Iterative Planung in kurzen Zyklen

Aufgrund von Corona und damit einhergehenden, sich ständig ändernden Rahmenbedingungen (ausgefallene Veranstaltungen, sich ändernde Kommunikationswege, …) sind wir bei der Planung unserer Kampagnen von einem dreimonatigen Planungszyklus in einen vierwöchigen Turnus gewechselt. Damit können wir unsere Arbeit stetig an die sich ändernden Prioritäten (Bewertung immer nach Dringlichkeit und Wichtigkeit) anpassen. Um sicherzustellen, dass wir dennoch keine langfristigen Aufgaben vergessen, haben wir einen Backlog, in dem alle Aktivitäten landen, die wir langfristig bearbeiten wollen, die aber nicht dringend oder wichtig sind.

Dieser Backlog ist auch eng verknüpft mit dem nächsten Thema.

Visualisierung mit geeigneten Tools und eine gute Infrastruktur

Die technischen Voraussetzungen sind essenziell, um gemeinsam an Themen arbeiten zu können. Ein Sharepoint bzw. OneDrive zum Teilen von Dateien, Videotelefonie über Skype und MS Teams, ein Wiki mit einer transparenten Kampagnendokumentation und natürlich ein gemeinsames Aufgabenboard sind hier Gold wert und nur ein kleiner Auszug der Tools, mit denen wir arbeiten. Um unsere Aufgaben stets im Blick zu haben, setzen wir im Team vor allem auf Microsoft Teams und den darin integrierten Microsoft Planner. Hier haben wir, ähnlich einem Kanban Board, alle Aufgaben übersichtlich gesammelt und können bei Planning und Review auswerten, was wir erreicht haben und was wir uns für die nächsten Iterationen vornehmen wollen. Als internes Service Center werden ständig Anforderungen an uns herangetragen, welche wir unter anderem dort dokumentieren, um so sicherzustellen, dass Aufgaben (auch insbesondere bei unvorhergesehenen Ausfällen oder in Vertretungssituationen) nicht vergessen werden. Generell ist Transparenz oberstes Gebot, wobei wir uns aber auch an dem (abgewandelten) Satz aus dem agilen Manifest orientieren: Funktionierende ~~Software~~ Kampagnen mehr als umfassende Dokumentation (https://agilemanifesto.org/iso/de/manifesto.html).

Schön und gut, wenn Prozesse und Werkzeuge funktionieren. Doch was ist mit der zwischenmenschlichen Kommunikation? Wir streben in der Zusammenarbeit eine Atmosphäre an, die neben offener Kommunikation auf Werten wie Vertrauen, Commitment, Offenheit und gegenseitigem Respekt basiert. Und im Mittelpunkt dieser Zusammenarbeit stehen immer Menschen und ein funktionierendes Team, in dem man sich aufeinander verlassen kann. Dieses Teamgefühl entsteht sicher auch durch die kleinen Gespräche zwischendurch über den Schreibtisch hinweg, ein gemeinsames Mittagessen oder eben einen kurzen Plausch an der Kaffeemaschine außerhalb des Meetings. All dies ist bei der verteilten Arbeit und beim „Social Distancing“ nur schwer umsetzbar und entfällt zu großen Teilen. Um uns als Team dennoch nicht „auseinander zu leben“ haben wir einmal in der Woche eine virtuelle Kaffeepause eingeführt. Diesen Termin nutzen wir bewusst, um auch einmal bei einer Tasse Kaffee (oder einem anderen Getränk) über Off-Topic-Themen zu sprechen und darüber, was uns zur Zeit so beschäftigt. Eben über die Dinge, die man sonst in den Pausen und auf dem Gang mal besprechen würde – bewusst nicht über Themen, die mit dem eigentlichen Aufgabenfeld zu tun haben. Und natürlich mit Video, um sich gegenseitig auch mal wieder zu sehen!

*Abbildung 3: Wöchentlich stattfindende virtuelle Kaffeepause im Team*

Doch auch über die Teamebene hinaus helfen uns bereits etablierte Formate, die aus unserem agilen Managementprozess resultieren – so z. B. unser ZEISS Stand-Up (Betriebsvollversammlung). Normalerweise in sechswöchigem Turnus stattfindend und im Anschluss an ein gemeinsames Pizzaessen an allen Standorten, informiert hier unser Management zu allen wichtigen aktuellen Themen, Zahlen, Daten und Fakten. Jeder Mitarbeiter, der Interesse hat, daran teilzunehmen, bekommt hier die Möglichkeit, während seiner Arbeitszeit vor Ort oder über Skype zuzuhören und im Anschluss auch Fragen zu stellen. Als wichtiger Eckpfeiler unserer Unternehmensinformation und -kommunikation sorgt dies für Transparenz auf allen Ebenen und findet seit dem 20.03.2020 sogar wöchentlich statt, um alle über die aktuellen Entwicklungen des Unternehmens in der Krise und ggf. getroffene Maßnahmen zu informieren. Neben den wirtschaftlichen Auswirkungen werden hier unter anderem auch spezielle Fragen besprochen, wie z. B. unser Hygienekonzept, das „Corona-Elterngeld“ bei Minusstunden und noch vieles mehr. Ein weiteres kleines Puzzlestück, das einem Sicherheit und Vertrauen gibt und die unternehmensweite Zusammenarbeit in dieser Krise erleichtert.

Softwareentwicklung in Zeiten von Corona – „Business as usual?“

Zusammenarbeit

In Zeiten des Social Distancing treten gelegentliche Videokonferenzrunden im Freundeskreis an die Stelle des gemeinsamen Kneipenbesuchs. Hier kam schnell die Diskussion auf, wie stark Corona den Arbeitsalltag beeinflusst.

Die allgemeine Meinung war, dass die Arbeitsfähigkeit stark beeinträchtigt und bei einigen sogar fast gar nicht mehr vorhanden sei. Die Arbeitgeber waren schlicht nicht bzw. nur stark eingeschränkt in der Lage, die notwendige Infrastruktur für die Arbeitsfähigkeit bereitzustellen. Und wenn dann die Infrastruktur endlich stand, wurde allen klar, was jeder weiß, der schon einmal verteilt gearbeitet hat: Es ist kompliziert! Wer darf sprechen? Kamera an oder aus? Da schreit ein Kind im Hintergrund, bitte das Mikrophon muten! Du möchtest etwas sagen? Bitte dein Mikrophon un-muten! Die Verbindung ist schlecht, ich verstehe nur jedes zweite Wort… die Liste lässt sich endlos weiterführen.

Viele sind es einfach nicht gewohnt, so zu arbeiten. Nicht zuletzt, da Kommunikation mehr ist als der bloße Austausch von Worten. Die Deutung bspw. von Körperhaltung, Mimik und Gestik der Gesprächspartner ist bei Telefon- und auch Videokonferenzen ungleich schwieriger. Das ist eine neue Situation, die viel Disziplin und Anpassungen aller Beteiligten erfordert!

Die Diskussionen mit meinen Freunden ziehen dann so vor sich hin und Erfahrungsberichte über Video-Tool-Anbieter wechseln sich mit Klagen über die eigentliche „Unmöglichkeit“ des Arbeitens in dieser Situation ab. Währenddessen suche ich in meinem Kopf verzweifelt nach eigenen Wortbeiträgen für diese Diskussion. Und ich finde auf die Frage „Was hat sich für dich seit Corona in deiner Arbeit geändert?“ nur die Antwort: „Eigentlich nichts!“

Das ist – zugegeben – eine leichte Übertreibung! Die Fahrt ins Büro, das gemeinsame Mittagessen mit Kollegen, der Schwatz an der Kaffeemaschine – all das fällt nun erst einmal weg und bedeutet einen herben Einschnitt und Verlust. Wenn, wie in meiner Situation, das Home-Office nicht nur Büro sondern auch noch Kita ist und beide Elternteile Vollzeit arbeiten, wird verteiltes Arbeiten auch für Menschen, die damit eigentlich Erfahrung haben, zu einer Herausforderung.

Aber auch hier gilt: Die Ausgangssituation ist für die meisten Menschen gleich. Insofern hilft es nur, sie entsprechend anzunehmen und das Beste daraus zu machen. Und genau da zeigt sich einmal mehr, wie wichtig es ist, bereits Erfahrungen im verteilten Arbeiten gesammelt zu haben.

Die ZEISS Digital Innovation (vormals Saxonia Systems AG) verfolgt seit vielen Jahren das Grundprinzip des Arbeitens in verteilten Teams. Nicht zuletzt, um die Work-Life-Balance der Mitarbeiterinnen und Mitarbeiter zu erhalten, ist es dem Unternehmen wichtig, dass die Leistungen für einen Kunden theoretisch überall erbracht werden können. Dadurch werden zum einen Reisekosten gespart und zum anderen wird sichergestellt, dass die notwendige Infrastruktur für die Arbeit vorhanden ist und nicht ggf. noch extra vom Kunden beschafft werden muss.

Person sitzt vor Laptop und mehreren Monitoren während einer Videokonferenz und nutzt das Tool ETEOboard für verteilte Zusammenarbeit — *Abbildung 1: Verteilte Projektarbeit im Home-Office*

Ich persönlich habe in meiner fünfjährigen Betriebszugehörigkeit erst ein Projekt erlebt, bei dem das Entwicklungsteam ständig an einem Standort versammelt war. In meinem aktuellen Projekt, gestartet im September 2019, liegt eine extreme Verteilung vor: Die sechs Projektmitglieder der ZEISS Digital Innovation sitzen an fünf unterschiedlichen Standorten, die Projekt-Stakeholder des Kunden an zwei Standorten. Insofern haben wir nicht erst seit Corona die Herausforderung des verteilten Arbeitens zu meistern, sondern diese Verteilung bereits zu Projektstart als Risiko identifiziert, dem wir uns stellen mussten.

Gelungen ist uns das meiner Meinung nach mit einem simpel anmutenden Mittel: Direkte Kommunikation!

Das Entwicklungsteam hat oft die Technik des PairProgramming eingesetzt, um einerseits den Know-how-Transfer innerhalb des Teams zu fördern, aber auch, um den individuellen Stil des jeweils anderen kennenzulernen. Daneben gehören bei uns Code Reviews zum Standardvorgehen. Diese dienen einerseits der Qualitätssicherung, andererseits fördern Code Reviews auch den Wissensaustausch innerhalb des Teams. Neben dem Daily-Meeting für alle Teammitglieder haben wir ein eigenes „DEV-Daily“ etabliert, in dem sich das Entwicklungsteam in kleinerer Runde über insbesondere technische Fragestellungen austauschen kann.

In regelmäßigen Refinement-Meetings werden fachliche Anforderungen mit technischen Lösungsansätzen gemappt. Ideen werden gesammelt, geprüft, angepasst, verworfen und neu entwickelt und das ohne Denkverbote und -schranken. Dadurch ist ein Raum der Kreativität und freien Entfaltung entstanden, in dem jedes Teammitglied seine Ideen einbringen kann und sich dadurch wertgeschätzt und mitgenommen fühlt: Trotz der Verteilung ist ein echter Teamspirit entstanden!

Die Etablierung dieser offenen Kommunikationskultur führt dazu, dass wir innerhalb des Teams intensiver und häufiger kommunizieren, sei es im Vier-Augen-Gespräch oder in der Gruppe. Dabei ist immer zu beachten, dass den individuellen Präferenzen der Teammitglieder hinsichtlich der Kommunikation Rechnung getragen wird: Manche Menschen sind Frühaufsteher. Sie sind um 8 Uhr morgens bereits voll in ihrem Flow und platzen fast, ihre neuen Ideen den Kolleginnen und Kollegen mitzuteilen, während andere um diese Uhrzeit noch kaum die Augen aufkriegen. Einige möchten gerne im Vorfeld einen Termin bekommen, um Dinge zu besprechen, damit sie planen und sich vorbereiten können. Andere springen ganz leicht zwischen Themen hin und her und man kann sie einfach ad hoc mit einem Anruf überfallen.

Um effizientes Arbeiten auch in einem verteilten Team zu ermöglichen, ist es zugegebenermaßen vermutlich nicht ausreichend, einfach „mehr zu kommunizieren“. Vielmehr ist ein durchdachtes Konzept, das alle Aspekte und Herausforderungen von verteiltem Arbeiten berücksichtigt, unabdingbar. Das gilt insbesondere für Teams mit wenig Erfahrung im verteilten Arbeiten.

Die ZEISS Digital Innovation hat bereits vor einigen Jahren mit dem ETEO-Konzept Aufmerksamkeit erregt. ETEO („Ein Team Ein Office“) ist ein Framework zur verteilten Arbeit von Projektteams. Es gibt Projektteams einen Leitfaden an die Hand, wie verteilte Arbeit erfolgreich gestaltet werden kann. Eine permanente Videoverbindung zwischen den Standorten und die Nutzung eines digitalen Workboards für die Organisation von Aufgaben ermöglichen es den Teams, standortübergreifend zusammenzuarbeiten, quasi als wären sie an einem Standort versammelt. Die Videoverbindung ist dabei kein Muss, sondern lediglich ein Element aus dem Baukasten des bei ZEISS Digital Innovation gebräuchlichen Tool-Kits für verteiltes Arbeiten. Im Unternehmen gibt es speziell geschulte Mitarbeiter (ETEO-Coaches), welche die Teams in der Ramp-up-Phase eines Projektes und während des weiteren Projektverlaufs dediziert in Techniken für verteilte Zusammenarbeit schulen und hinsichtlich einzusetzender Tools beraten. Bei unseren Kunden führt dies oft zu „Aha-Effekten“, dass verteilte Zusammenarbeit durchaus möglich ist – und zwar ohne Performance-Einbußen befürchten zu müssen.

Grafik eines Hauses "Ein Team Ein Office" auf vier Säulen und auf der Basis von Werten für verteilte Scrum-Teams — *Abbildung 2: ETEO – unser Zusammenarbeitsmodell*

Generell gilt aber auch für das verteilte Arbeiten: Das Werkzeug ist nichts, wenn man es nicht einzusetzen weiß! Damit meine ich, dass verteiltes Arbeiten ohne die entsprechende Disziplin und das passende Mindset der Beteiligten nicht gelingen kann. An dieser Stelle bleibt zu sagen: Man muss sich darauf ohne Vorbehalte einlassen sowie Tools und Techniken einfach mal ausprobieren. Und natürlich: Übung macht den Meister! Je länger ein Team verteilt zusammenarbeitet, desto stärker bilden sich die Best Practices für die verteilte Arbeit in der individuellen Teamkonstellation heraus. Man darf nicht außer Acht lassen, dass es das ultimative Konzept für verteiltes Arbeiten nicht gibt. Denn in Projekten kommunizieren keine Rollen oder Verantwortlichkeiten miteinander, sondern immer Menschen und die sind bekanntlich unterschiedlich.

Jedes Projekt ist anders und damit auch die Anforderungen an die verteilte Arbeit. Aber die Grundprinzipien sind überwiegend gleich. Das ist vergleichbar mit dem Bau eines Hauses: Ein Haus kann 1, 2, 3 oder 20 Stockwerke haben, ein Spitz- oder ein Flachdach, Doppelfenster oder einfache Fenster, aber jedes Haus hat ein Fundament, auf dem es steht.

Und die Fundamente der verteilten Arbeit sind bei ZEISS Digital Innovation sehr stabil!

Früher: Einzelkämpfer … Heute: Ein Team! – Die neue Zusammenarbeit bei uns im Unternehmen

Zusammenarbeit

IT-Consulting war schon immer ein interessantes Geschäftsfeld. Die Kunden profitieren davon, Arbeitskräfte sehr flexibel nach Fachlichkeit und Kapazität einplanen zu können. Für Consultants bietet sich die einzigartige Möglichkeit, innerhalb kürzester Zeit viel Berufserfahrung zu erlangen, da wir durch die Projektarbeit verschiedenste Kundenszenarien und Arbeitsumfelder kennenlernen und aktiv mitgestalten. Dabei verfolgen wir neue Technologien und helfen unseren Kunden, diese in ihre Prozesse einzubinden. Aktuelle Themen in unseren Software- und Qualitätssicherungsprojekten sind bspw. Java, .NET/C#, Cloud, Web, Mobile, Usability sowie agile Vorgehensweisen.

Vor 2010 bedeutete bei der Saxonia Systems (seit 03/2020 ZEISS Digital Innovation) zu arbeiten nahezu ausschließlich, den Großteil der Woche beim Kunden vor Ort irgendwo in Deutschland unterwegs zu sein, allein oder mit Kollegen. Wenn man nicht gerade das Glück hatte, in einem Projekt in Wohnortnähe zu arbeiten, ging dies in aller Regel zu Lasten des Privatlebens. Spätestens mit der Familiengründung musste man sich fragen, wie es nun beruflich weitergehen kann.

Dies veränderte sich Ende 2010. Das erste verteilt arbeitende Projekt bei der Saxonia ging an den Start. Mit großen Bildschirmen und Kameras starteten wir das Experiment, in zwei standortverteilten Räumen den Eindruck zu schaffen, wir säßen in einem Büro und arbeiten gemeinsam in einem agilen Projektteam. Zu Beginn war dies mit einem analogen Aufgabenboard und vielen Verbindungsabbrüchen noch eine sehr holprige Angelegenheit. Auch ein echtes agiles Verständnis begann damals erst langsam zu wachsen.

Mehrere Personen sitzen vor zwei großen Monitoren, auf denen einerseits ein weiteres Team von Personen per Videokonferenz zugeschaltet ist sowie andererseits eine Aufgabenliste zu sehen ist. — *Abbildung 1: Verteiltes Meeting mit zwei Standorten*

Doch stetig verbesserten wir unsere verteilte agile Zusammenarbeit nach Scrum – mit immer besseren technischen Set-ups, mit unserem digitalen Aufgabenboard und nicht zuletzt unserem ganzheitlichen Konzept für verteilte Zusammenarbeit ETEO (kurz für „Ein Team Ein Office“). Das IT-Consulting bei Saxonia entwickelte sich weg von Einzeleinsätzen hin zu echter Projekt- und Teamarbeit mit den Kollegen.

Der Projektalltag und die Reisetätigkeit sehen heute in der Realität vielfach anders aus. Nach aktuellem Stand arbeiten bei uns 84 % der Saxonianer von den Büros ihrer Heimatstandorte aus.

Deutschlandkarte mit Kundenstandort und Standorten der ZEISS Digital Innovation — *Abbildung 2: Verteilte Zusammenarbeit mit Kunden an verschiedenen Standorten*

Heute sind die meisten von uns in agilen Scrum Teams organisiert und arbeiten von den Standorten der Saxonia aus verteilt mit dem Kunden und den Kollegen zusammen.

Ein Team Ein Office - Zusammenarbeit an Standort A und B — Abbildung 3: *Ein Team Ein Office* – *Verteilte Zusammenarbeit an zwei Standorten*

Im Alltag bedeutet dies, wir arbeiten in Büros, die mittels zeitgemäßer Technik mit einem anderen Standort verbunden sind, sodass wir uns immer sehen können, als ob wir in einem Raum wären. So gestalten wir auch unsere Meetings, indem wir uns in der Gruppe vor die Kamera stellen oder setzen. Einzelgespräche, bspw. beim Pair Programming, können wir vom Rechner aus mit Headset und geteiltem Bildschirm führen und so bequem an einer Aufgabe gemeinsam arbeiten, als säßen wir real nebeneinander. Für kreative Arbeiten während des Sprints oder während der Retrospektiven nutzen wir digitale Whiteboards oder Zettelwände, die es uns ermöglichen, gemeinsam auf derselben Oberfläche zu arbeiten.

Ein Team arbeitet verteilt über zwei Standorte zusammen und ist per Videokonferenz zusammengeschaltet. — *Abbildung 4: Ad-hoc-Diskussion über eine Aufgabe während der Arbeit – über Videokonferenz kein Problem.*

Zum Kunden oder an einen der anderen Standorte reisen wir im laufenden Projekt z. B. noch zu Sprintwechseln alle 2-3 Wochen oder mitunter noch seltener. Früher war ein IT-Consultant oft als „Einzelkämpfer“ beim Kunden unterwegs. Heute reist er mit seinen netten Teamkollegen gemeinsam.

Nicht nur die Verteilung war im Fokus unseres kontinuierlichen Verbesserungsprozesses. Neben der Projektarbeit in Teams gingen wir ab 2010 noch einen Schritt weiter: Zusammenarbeit und Führung wurde auch im Management neu gedacht. Kontinuierlich hat sich daraus unser agiler Strategieprozess entwickelt, den wir konsequent anwenden. Dadurch wurde unser gesamtes Unternehmen schrittweise agiler. Durch die Mitarbeit in sogenannten „Strategischen Initiativen“ können wir alle aktiv an diesem Prozess teilhaben. Heute findet alle 14 Tage nach unserem gemeinsamen „Pizzafreitag“ das Strategie-Standup (analog zum Daily-Standup im Scrum) verteilt mittels ETEO-Board und Videokonferenz über alle Standorte statt, bei dem sich jeder über den aktuellen Stand der Strategischen Initiativen informieren kann.