agile Archives - Digital Innovation Blog

Kann agile Softwareentwicklung in einem regulierten Umfeld wie der Medizintechnikindustrie funktionieren?

Health Solutions

Was sind Vorteile, Herausforderungen und kritische Erfolgsfaktoren bei der Umsetzung?

Business Kontext

Studien haben gezeigt, dass die digitale Transformation in der Gesundheitsbranche in den letzten fünf Jahren enorm beschleunigt wurde. Ein katalysierender Aspekt war die COVID-19-Pandemie, die zu Veränderungen in den Interaktionen zwischen Patient:innen und medizinischem Fachpersonal führte. Im Zuge dieses Prozesses wurden neue Technologien entwickelt, die es ermöglicht haben, viele Aufgaben remote durchzuführen. Medizintechnik- und Life-Science-Unternehmen müssen nun zeitnah reagieren, um auf diese veränderten Bedingungen einzugehen. Aufgrund der zunehmenden digitalen Lösungen wurden die Kundenerwartungen dahingehend erhöht, dass Kund:innen in ihrer täglichen Arbeit in derselben Weise und Qualität von digitalen Lösungen unterstützt werden wie dies in anderen Branchen (z.B. Unterhaltung oder Reiseorganisation) bereits möglich ist.

In diesen Industrien haben R&D-Organisationen agile Entwicklungsmethoden erfolgreich verwendet, um dieses Niveau an Digitalisierung zu erreichen. Medizintechnik- und Life-Science-Unternehmen hingegen haben aufgrund der regulatorischen Anforderungen strenge Vorschriften und interne Prozesse einzuhalten, die agile Bestreben einschränken. Können die agilen Entwicklungsframeworks auf diese speziellen Rahmenbedingungen angepasst werden, um bei der Bewältigung dieser Herausforderungen zu helfen und damit den Softwareentwicklungsprozess zu beschleunigen sowie durch mehrfache Iterationen flexibel und nutzerzentriert zu gestalten?

Die Durchführung von Software-R&D-Projekten mit agiler Methodik kann die Effizienz auf verschiedene Weisen verbessern:

Time-to-Market: Durch die agile Methodik werden einsatzfähige Softwareinkremente in jedem Entwicklungsschritt (Sprints) geliefert, was den Teams dabei helfen kann, sich auf die wesentlichen Anwendungsfälle des Produkts zu konzentrieren und dieses schneller auf den Markt zu bringen.

Ressourcennutzung: Durch die Schätzung der Kosten für jedes Produktinkrement und die enge Überwachung des Fortschritts können Teams die Ressourcennutzung optimieren und Verschwendung reduzieren.

Kontinuierliche Verbesserung: Die agile Methodik inkludiert kontinuierliche Verbesserung und Feedback. Teams werden regelmäßig dazu ermutigt, ihre Prozesse zu verbessern und effizienter zu werden.

Reduzierter Nachbearbeitungsaufwand: Durch die frühzeitige Identifizierung von Problemen oder neuen Anforderungen im Projektverlauf und deren rasche Behebung bzw. Umsetzung können Teams das Risiko teurer Nacharbeiten reduzieren und sicherstellen, dass das Projekt den Kunden- und Nutzerwünschen entspricht.

Welche Herausforderungen bestehen bei Einführung von agilen Methodologien in einer regulierten Umgebung?

Einhaltung von Vorschriften: Medizintechnikunternehmen müssen eine Vielzahl von Vorschriften und Standards einhalten, wie z. B. MDR oder FDA-Vorschriften. Jede neue Methodik muss daher mit den Vorschriften konform sein und sicherstellen, dass alle erforderlichen Prozessschritte zur Zertifizierung sowie die zugehörigen Dokumentationen rechtzeitig abgeschlossen sind, damit eine Softwarelösung erfolgreich zugelassen werden kann.

Risikomanagement: Medizintechnikunternehmen müssen eine Vielzahl von Risiken managen, wie z. B. Patientensicherheit, Datenschutz und Cybersicherheit. Eine angemessene Identifizierung, Bewältigung und Überwachung dieser Risiken ist für den Projekterfolg entscheidend und muss auch bei agiler Softwareentwicklung umgesetzt werden.

Dokumentation: Medizintechnikunternehmen sind verpflichtet, detaillierte Dokumentationen über ihre Softwareentwicklungsprozesse und deren Ergebnisse zu führen. Das Problem ist, dass bei einer Software, die als Medizinprodukt eingestuft ist, für jeden neuen Softwarerelease eine komplette technische Akte für die Zulassung erzeugt werden muss. Damit entsteht ein zusätzlicher Dokumentationsaufwand.

Einbeziehung der Interessengruppen: Im Gesundheitswesen sind viele Interessengruppen an Produkt- und Softwareentwicklungsprojekten beteiligt, darunter Patient:innen, Ärzt:innen, Regulierungsbehörden und IT-Mitarbeitende. Es ist wichtig sicherzustellen, dass die Stimmen aller Interessengruppen gehört und ihre jeweiligen Bedürfnisse berücksichtigt werden.

Wie können die Vorteile beider Ansätze kombiniert werden?

1. Erstellen Sie einen detaillierten Projektplan

Agil zu arbeiten bedeutet nicht, ohne Plan zu arbeiten. Beim Einsatz agiler Methoden in einer regulierten Umgebung sollte ein detaillierter Projektplan den Projektumfang, die Ziele, den Zeitplan, die erforderlichen Ressourcen und die zu bewältigenden Risiken umreißen und dokumentieren.

2. Erstellen Sie Dokumente durch automatisierte Prozesse

In einer regulierten Umgebung ist eine detaillierte Dokumentation erforderlich, um die Einhaltung von Standards und Vorschriften nachzuweisen. Gemäß dem Wasserfallmodell werden Design-Eingabe- und Ausgabedokumente für einen bestimmten Projektsynchronisationspunkt erstellt, in denen die Risiken, Geschäftsanforderungen, Architektur, Tests und betrieblichen Aspekte des zu erstellenden Produkts detailliert beschrieben werden. Die agilen Methodologien können angepasst werden, um die Anforderungen an die Dokumentation in den detaillierten Produkt-Backlog-Elementen zu berücksichtigen.

Die Dokumente können vor Beginn eines Entwicklungssprints oder eines Produktinkrements erstellt werden, um den regulatorischen Anforderungen gerecht zu werden und die Verfügbarkeit der Design-Eingaben sicherzustellen. Sie können einen engen Umfang beschreiben, der für den bevorstehenden Entwicklungszeitraum relevant ist. Durch Automatisierung in diesem Bereich kann der Zeitaufwand für die Erstellung, Aktualisierung und Genehmigungszyklen von Dokumenten erheblich reduziert werden. Anforderungen, Softwareentwürfe und Tests können nahe am Entwicklungsumfeld erstellt werden und mit Hilfe validierter Tools später in umfassende und konsistente Dokumente überführt werden kann, die den Anforderungen des Qualitätsmanagementsystems entsprechen.

3. Ausbau der Testautomatisierung

Es gibt mehrere Gründe, warum Investitionen in Testautomatisierung ein Projekt effizienter machen können. Wenn Änderungen an einer Software in einer regulierten Umgebung vorgenommen werden, besteht stets die Herausforderung, nachzuweisen, dass keine negativen Auswirkungen auf die Patientensicherheit und die allgemeine Wirksamkeit bestehen.

Oder wenn ein Produkt von einer Implementierungsphase zu einer Verifikations- und Validierungsphase übergeht, sind viele notwendige, aber zeitaufwändige Testaktivitäten erforderlich. In funktionsübergreifenden agilen Teams können Verifikationsaufgaben für bestimmte Funktionen der Softwarelösung Teil der Entwicklungssprints sein. Die Zeit, um Feedback zum tatsächlichen Zustand des Produkts zu erhalten, verringert sich erheblich bei hohem Automatisierungsgrad.

So reduziert sich auch das Risiko der Einführung unbeabsichtigter Nebenwirkungen bei Änderungen an einem bestehenden Code. Mit der richtigen Testdokumentation und Codequalität können automatisierte Tests die Geschäftsanforderungen formell abdecken und für Verifikationsaktivitäten verwendet werden, wodurch die benötigte Zeit für einen Testzyklus reduziert wird.

4. Risiken kontinuierlich managen

Gesundheitsorganisationen müssen eine Vielzahl von Risiken managen, wie z. B. Patientensicherheit, Datenschutz und IT-Sicherheit. Agile Methodologien können angepasst werden, um Risikomanagementpraktiken wie Risikoerkennung, Risikobewertung und Risikominderung in wiederholten verkürzten Zyklen einzuschließen, unterstützt durch den automatisierten Dokumentenerstellungsprozess und automatisierte Tests gegen die definierten Risikominderungen.

5. Einbeziehung der Interessengruppen

Durch regelmäßige Sprint- und Produktinkrement-Demonstrationssitzungen können die Teams allen wichtigen Interessengruppen zeigen, in welche Richtung sich die Digitallösung entwickelt. Da die Entwicklungszyklen verkürzt werden, können Patient:innen, Ärzt:innen und IT-Mitarbeitende regelmäßig Beitrag leisten, um Änderungswünsche einzubringen, denen die agilen Teams folgen können. Regelmäßig sollten zudem auch Kund:innen, Meinungsführer:innen und Partner:innen ihre Meinung darüber äußern können, wie die Lösung gestaltet werden soll. Dies können Medizintechnikunternehmen zum Beispiel durch gemeinsame Workshops oder Pilotphasen auf Grundlage von Zwischenproduktversionen ermöglichen.

Fazit

Die Einführung von neuen Prozessen, insbesondere in einer regulierten Umgebung, ist mit zusätzlichen Schwierigkeiten und Verzögerungen verbunden. Die Integration agiler Prinzipien, unterstützt von einem Team aus Branchenexperten und hochgradig automatisierten Prozessen, ermöglicht einer Organisation jedoch eine schnelle Reaktion und Antwort auf neue Herausforderungen, die sich aus den wandelnden Anforderungen der Medizintechnikbranche mit einer stark regulierten Umgebung ergeben.

➡️ Kontaktieren Sie uns, um sich über Ihre Ideen auszutauschen und wie wir helfen können. Besuchen Sie auch unsere Website, um mehr über uns und unsere Dienstleistungen zu erfahren.

➡️ Weitere Blogartikel zum Thema Health Solutions finden Sie hier.

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.

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.

Der QA Navigation Board Workshop

Qualitätssicherung

Mit dem QA Navigation Board haben die agilen Entwicklungsteams ein visuelles Hilfsmittel, mit dem sie frühzeitig die planerischen Aspekte der Qualitätssicherung beurteilen können. Dabei kann das QA Navigation Board innerhalb der Projektlaufzeit auch als Referenz des aktuellen Vorgehens und als Ansatz für potenzielle Verbesserung genutzt werden. » QA Navigation Board

Das QA Navigation Board wird innerhalb eines Workshops entwickelt, welcher von einem agilen QA-Coach durchgeführt wird. Der Workshop sollte nicht langer als 1,5 Stunden dauern.

Vorbereitung

Es sollten alle Beteiligten des agilen Projektes eingeladen werden:

Entwicklerteam (Entwickler, Tester)
Scrum Master
Product Owner
weitere Stake- und Shareholder

Das QA Navigation Board wird an einer (Pinn-) Wand befestigt. Zusätzlich wird der QA-Oktant als Arbeitsblatt für jeden Teilnehmer ausgedruckt.

Schritt 1:

Vorstellung des QA Navigation Board und der Ziele des Workshops durch den Moderator (agiler QA-Coach) sowie Vorstellung der Beteiligten.

Schritt 2:

Kurze Vorstellung des QA-Oktanten und der Qualitätskriterien. Ziel ist es, dass alle Beteiligten das Arbeitsblatt ausfüllen können und alle die Qualitätskriterien verstanden haben bzw. nicht anschließend aneinander vorbeireden.

Des Weiteren stimmen sich die Teilnehmer über die Dimensionen des QA-Oktanten ab: Wie sollen die Abstände des Diagrammes bewertet werden (1, 2, 3 oder S, M, L, XL etc.)? Danach werden die Arbeitsblätter ausgeteilt und innerhalb von 5 bis 10 min von jedem Beteiligten alleine ausgefüllt und mit seinem Namen versehen (siehe Blogbeitrag: Wie verwende ich den QA-Oktanten).

Schritt 3:

Nach Ablauf der Zeit sammelt der Moderator die Arbeitsblätter wieder ein und platziert sie auf einer (Pinn-) Wand.

Die Aufgabe des Moderators ist es nun, die einzelnen Qualitätskriterien durchzugehen. Dazu identifiziert er pro Kriterium den gemeinsamen Nenner (Durchschnitt) und bespricht die größten Abweichungen mit den dazugehörigen Personen (siehe Planning poker). Wurde im Team ein Konsens über den Wert des Kriteriums erzielt, wird dieser Wert vom Moderator dokumentiert.

Schritt 4:

Auf Basis der Wertung der Qualitätskriterien leiten nun die Beteiligten die notwendigen Testarten ab. Je wichtiger ein Qualitätskriterium bewertet wurde, desto wahrscheinlicher muss es durch ein passendes Testvorgehen geprüft werden. Die identifizerten Testarten werden vom Team in der Testpyramide des QA Navigation Board platziert.

Schritt 5:

Sind alle Testarten identifiziert und platziert, können die notwendigen Testressourcen und anderen Testartefakte auf dem QA Navigation Board platziert werden. Hier kann eine Checkliste helfen (siehe Blogbeitrag: Die QA-Karte oder „Wie fülle ich das QA Navigation Board…“).

Schritt 6:

Hat das Team das QA Navigation Board weitestgehend ausgefüllt, wird es an einem passenden Platz im Teamraum aufgehängt. Der Moderator schließt den Workshop ab und verweist darauf, dass das QA Navigation Board vom Team weiterentwickelt und auch in den Retrospektiven genutzt werden kann.

Download Arbeitsblatt „QA-Oktant“

Die QA-Karte oder „Wie fülle ich das QA Navigation Board…“

Qualitätssicherung

Mit dem QA Navigation Board haben die Entwicklungsteams ein visuelles Hilfsmittel, mit dem sie frühzeitig die planerischen Aspekte der Qualitätssicherung beurteilen können. Dabei kann das QA Navigation Board innerhalb der Projektlaufzeit auch als Referenz des aktuellen Vorgehens und als Ansatz für potenzielle Verbesserung genutzt werden. Aber wie lassen sich die Testarten und anderen Testartefakte auf dem QA Navigation Board platzieren?

Um die Frage „Wie und wo wollen wir testen?“ zu beantworten, müsste das Team den gesamten Entwicklungsprozess nach Test- und QA-Aspekten durchforsten und diese dokumentieren. Je nach Projekt kann der Entwicklungsprozess unterschiedlich ausgeprägt sein und damit die Fragestellung schnell recht komplex werden lassen.

*Abbildung 1: Entwicklungs- und QA-Prozess*

Um auch hier den Teams einen mühelosen Einstieg in das Thema zu geben, haben wir die QA-Karte entwickelt. Die QA-Karte bietet dem Team eine praktische Möglichkeit, die Maßnahmen für eine optimale Testbarkeit der Projekte zu planen und zu dokumentieren. Ziel ist es, bereits zu einem frühen Zeitpunkt alle QA-relevanten Fragen für die Teams und Entwicklungsprojekte durch einen spielerischen Ansatz zu ermitteln.

Nach der Definition der Testschwerpunkte durch die Nutzung des QA-Oktanten und der Bestimmung der notwendigen Testarten können alle Aspekte der Teststrategie wie Testarten, Ressourcen und Werkzeuge visualisiert, diskutiert und priorisiert werden.

Als Good-Practice der durchgeführten Workshops kristallisierte sich heraus, dass es hilfreich ist, bei der Steuerung der Befüllung der QA-Karte zwei Hilfsmittel zu nutzen. Zum einen einen guten Moderator, der den Workshop in die richtige Richtung leitet und zum anderen die Nutzung einer Checkliste. Die Checkliste beinhaltet passende Fragen, die im Workshop als Anregung dienen sollen, um die verschiedenen Teile der QA-Karte zu befüllen. Diese Fragen sind nachfolgend aufgelistet und dem jeweilig zu befüllenden Feld zugeordnet.

Requirements

Wo liegen die Anforderungen?
Unterstützen die Anforderungen die Testfallerstellung?
Lassen sich Anforderungen und Tests verknüpfen?

Test / Code

Wo werden die Tests platziert?
Haben wir die nötigen Skills?

Repository

Wo werden die Testartefakte gespeichert?
Gibt es unterschiedliche Artefakte?

Test Management

Wie planen wir unsere Tests?
Wie dokumentieren wir unsere Tests?
Wie informieren wir? Und wen?

Automation

Wieviel Testautomatisierung ist nötig?
Benötigen wir weitere Werkzeuge?
Benötigen wir Testdaten?

Build

Wie oft wollen wir bauen und testen?
Wie wollen wir die QA integrieren?
Wollen wir Wartbarkeit prüfen?

Test Environments

Haben wir für jeden Test die passende Umgebung?
Kommen wir uns in die Quere?

*Abbildung 3: Beispiel 1 eines ausgefüllten QA Navigation Boards*

*Abbildung 4: Beispiel 2 eines ausgefüllten QA Navigation Boards*

Sobald alle Testarten ausgewählt wurden und das Team begonnen hat, die anderen Testartefakte (z.B. Werkzeuge, Umgebungen) zu platzieren, kann sich der Moderator zurückziehen. Das finale Wandbild sollte vom Team plakativ im Teamraum angebracht werden. So dient das QA Navigation Board als Referenz des aktuellen Vorgehens und als Ansatz für potenzielle Verbesserung.

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.

Der Nutzer im Mittelpunkt der Softwareentwicklung

Usability

Im Mittelpunkt dieses Blogbeitrags steht die Integration von User Centered Design (UCD) in unseren agilen Softwareentwicklungsprozess bei der Saxonia Systems AG (seit 03/2020 ZEISS Digital Innovation). Dabei wird vor allem auf die Artefakte und Methoden eingegangen, welche dafür sorgen, dass die Software auf den tatsächlichen Nutzer maßgeschneidert wird.

Die Wurzel schlechter Usability

Warum benutzt niemand die neue Software? Wenn diese Frage aufkommt, ist es meist schon viel zu spät. Die Entwicklung ist bereits abgeschlossen und die Nutzer bleiben aus bzw. halten an der alten Lösung fest. Dann ist es wahrscheinlich wieder einmal passiert, dass bei der Aufnahme der Anforderungen Annahmen getroffen wurden, welche an den tatsächlichen Bedürfnissen der Nutzer vorbei gehen. Dies ist ein in der Praxis leider häufig vorkommendes Phänomen, welches sich in schlechter Benutzbarkeit und niedriger Akzeptanz der finalen Software ausdrückt. Ein Lösungsansatz hierfür bietet das User Centered Design (UCD). Dieses stellt die Aufgaben, Eigenschaften und Ziele der zukünftigen Nutzergruppen in den Mittelpunkt des Softwareentwicklungsprozesses, um eine hohe Usability des Endproduktes zu gewährleisten.

User Centered Design

Durch unser agiles Vorgehensmodell sind wir in der Lage, schnell auf Änderungen und neue Anforderungen zu reagieren. Frühes Feedback von zukünftigen Nutzern ist essenziell für eine hohe Benutzbarkeit. Durch Artefakte und Methoden des Usability Engineerings wird unser an Scrum angelehntes Vorgehen so erweitert, dass der Nutzer von Anfang an regelmäßig eingebunden wird.

*Abbildung 1: UCD-Artefakte unseres agilen Vorgehensmodells*

Bereits zu Beginn des Projekts werden UCD-Elemente innerhalb der Product Vision verankert. Neben klassischen Bestandteilen, wie beispielsweise dem Projektziel oder der Systemgrenze, sind die Beschreibung der Nutzergruppen und des Nutzungskontexts sinnvolle UCD-Ergänzungen.

Im Product Backlog gibt es neben User Stories und technischen Spikes explizit Platz für Design Spikes, welche es dem Team erlauben, sich intensiv mit komplexen Usability-Themen zu befassen. Hierbei werden beispielsweise verschiedene Prototypen als Entscheidungsgrundlage entworfen oder Nutzerstudien konzipiert und durchgeführt.

In den beiden Scrum-Artefakten Definition of Ready und Definition of Done sind zusätzliche Qualitätsschranken integriert, um zu garantieren, dass die Software die zukünftigen Nutzungsanforderungen erfüllt. Durch vorgelagertes Prototyping ermitteln unsere Usability-Experten schon vor der Umsetzung, ob die Anforderungen zu den Bedürfnissen der Nutzer passen.

Bevor User Stories für ihre Umsetzung bereit sind, werden sie mit Skizzen, Mockups oder Designs (als Output aus dem Prototyp) erweitert. Diese verdeutlichen die zu implementierenden Funktionen für das Entwicklungsteam visuell. Sofern sie angewendet werden können, sind auch Prozessmodelle enthalten, um komplexe Abläufe zu veranschaulichen.

User Stories gelten aus UCD-Sicht als abgeschlossen, wenn die Usability-Prinzipien eingehalten wurden. Dies kann durch eine Experten-Evaluation überprüft werden. Dabei untersucht der Usability Engineer die neue Funktion heuristisch auf die Einhaltung von Richtlinien. Zusätzlich wird geprüft, ob der Styleguide eingehalten wurde und so die Konsistenz der Anwendung sichergestellt ist.

Zur Ablage von Usability-relevantem Hintergrundwissen empfiehlt sich ein zentraler Sammelort (Project Knowledge Base), z. B. in Form eines Team-Wikis.

Somit kann sich das Team jederzeit über das ermittelte Nutzerfeedback und den aktuellen Stand aus UCD-Sicht informieren. Empfehlenswerte Inhalte sind:

Informationsarchitektur
Domänenmodell
Systemdokumentation
Studien- und Testergebnisse, z. B. Nutzerstudien und CUI-Tracking
Personas

Wie in den obigen Abschnitten deutlich wird, beziehen wir den Nutzer an zahlreichen Stellen bei der Entwicklung von Individualsoftware ein. Unserer Erfahrung nach ist dies für eine hohe Nutzbarkeit und die Akzeptanz des Endprodukts essenziell. Durch das frühzeitige Einholen von Nutzerfeedback mit agilen und leichtgewichtigen Methoden können Sie die anfängliche Frage „Warum benutzt niemand die neue Software?“ aus ihrem Wortschatz streichen, denn der Nutzer ist der Schlüssel zum Erfolg.

Von Sprint zu Sprint – mein Weg zum Scrum Master

In meinem Blogbeitrag beschreibe ich euch meinen Weg zum Scrum Master und zeige, wie genau sich ein solcher Rollenwechsel gestalten kann. Dabei gebe ich euch ein paar Tipps mit auf den Weg und unterhaltsam ist es hoffentlich auch.

Viele von uns werden es kennen: Ein neues Projekt beginnt, neue Kollegen kommen auf einen zu, neue Netzwerke, Tools etc. Als Consultant beginnt man, sich mit der neuen Umgebung anzufreunden. Als Spezialist werde ich trotz aller neuen Variablen einen guten Job abliefern. Interessant wird es immer dann, wenn ich meine Spezialistenrolle verlasse und somit auch aus meiner Komfortzone heraustrete. Wie wäre es an dieser Stelle, mal in eine neue Aufgabe zu schlüpfen? Eine Rolle, die indirekt einen Einfluss auf das Projektteam haben kann und sollte?

Erster Sprint: Aller Anfang ist schwer oder wie war das?

Mit anfangs unruhigen Nächten war zu rechnen. Viele Fragen und Ideen rund um den Scrum Master standen im Raum: Wo fange ich mit meiner Arbeit an? Was denkt das Team darüber? Was zur Hölle muss ich eigentlich genau tun?

Es hat etwas Gutes, dass einem so viele Gedanken in den Kopf kommen – abgesehen vom fehlenden Schlaf. Alle Fragen, die ich mir selbst stelle, will ich auch beantwortet haben.

Tipp 1: Klärt offene Fragen schnellstmöglich, dann gewinnt ihr immer mehr an Sicherheit.

Mittlerweile kann ich sagen, dass man nicht alle Fragen allein beantworten muss. Unterstützung wird man auf Nachfrage bekommen.

Zweiter Sprint: Die Vorbereitungsphase

Das theoretische Wissen zu einer neuen Aufgabe konnte ich mir schnell aneignen. Ich habe mich hierbei mit dem agilen Manifest (das must know für Scrum Master) mit Podcasts, Blogs und Fachzeitschriften beschäftigt.

Theorie ist gut und bildet auch die Grundlage, aber ohne ihre praktische Anwendung ist diese nicht viel wert. Werte wie Vertrauen und Empathie kommen in der Rolle stärker ins Spiel. Was einem bewusst sein muss, ist, dass man als Scrum Master ohne das Team nicht wirklich etwas bewegen kann. Daher wollte ich hier beginnen und meinen Fokus ansetzen. Vielleicht konnte ich ja schon vorher mit Kollegen aus dem neuen Projekt ins Gespräch kommen?

Tipp 2: Es ist kein Problem offen zuzugeben, dass man noch nicht x Projekte als Scrum Master durchgeführt hat. Gegebenenfalls animiert es das Team sogar, die neuen Wege gemeinsam zu gehen.

Dritter Sprint: Der Start

Meine Arbeit begann mit der Vorstellung im Team. Wie in Sprint 2 beschrieben hatte ich das aber bereits getan. Also ging es in erster Linie darum, was ich für das Team beisteuern werde. Organisator, Moderator, Unterstützer und noch einige Worte mehr kamen dabei auf. Überraschend war das nicht. In Sprint 1 und 2 sind diese Worte oft vorgekommen, wenn es um die Aufgaben eines Scrum Masters ging.

Im nächsten Schritt galt es, die ganzen Informationen, die ich gelesen und gehört hatte, auch im Arbeitsalltag anzuwenden. Hier brauchte ich definitiv Menschen, die in dem Bereich Erfahrung hatten – Ansprechpartner, welche mich durch die erste Zeit begleiteten. An dieser Stelle geht noch mal ein Dank an meinen Coach Ines. Ich konnte ersten Reviews und Plannings beiwohnen mit anschließender Auswertung und Coaching. Langsam bekam ich eine Vorstellung von dem, was alles auf mich zukommen würde.

Eine der ersten Lektüren, die ich zu Beginn gelesen habe, war „Was macht der Scrum Master den ganzen Tag“ von Henning Wolf. Bald konnte ich diese Lektüre zur Seite legen. Es war weit mehr, als ich dachte.

Tipp 3: Fragt euch als Scrum Master nicht nur am Anfang, sondern in jeder Iteration: „Was habe ich dazu beigetragen, dass unser Team besser wird?“

Vierter Sprint: Do It!

In meinen ersten Tagen als Scrum Master war es meine Aufgabe, die Rahmenbedingungen für Verbesserungen im Team zu schaffen. Durch die enge Zusammenarbeit mit dem Business Analysten (Unterstützer des kundenseitigen Product Owners) und dem Team konnten wir schnell offene Punkte identifizieren. Hier war das Wasser, in das ich gesprungen war, nicht ganz so kalt. Wir optimierten nach und nach Terminketten, passten Abläufe an und erarbeiteten neue Ideen mit dem Team, die uns in der Arbeit voranbringen sollten. Neben dem Organisatorischen stand auch meine erste Retrospektive an. Ich denke, man kann sich vorstellen, dass dies ein ziemlich aufregender Termin für mich war.

Sahen die ersten Versuche am Flipchart noch ziemlich, naja sagen wir mal, „bescheiden“ aus, konnte das im Laufe der Zeit stetig verbessert werden.

Tipp 4: Besucht ein Flipchart-Coaching, wenn sich euch die Gelegenheit bietet – schon mit ein paar Tricks könnt ihr eure Präsentation entscheidend verbessern.

Fünfter Sprint: Zusammenfassung

Es fällt mir jetzt nicht schwer, die anfangs erwähnte Frage von Henning Wolf „Was macht der Scrum Master den ganzen Tag“ zu beantworten. Es ist eine ständige Herausforderung an den Scrum Master und damit an mich, für das Team optimale Unterstützung zu leisten und sich dabei kontinuierlich weiter zu entwickeln.

Meine Zertifizierung „CSM“ konnte ich erfolgreich absolvieren, was aber sicher nicht der letzte Meilenstein gewesen sein soll.

Tipp 5: Die Ausbildung zum Scrum Master und das agile Arbeiten sind „easy to learn but hard to master“.

Soll heißen, die Werkzeuge bzw. die Theorie sind schnell angelegt, das tägliche Arbeiten damit ist jedoch die erst die eigentliche Herausforderung. Denn es bedeutet, Tag für Tag das oben beschriebene Procedere durchzusetzen und das richtige „Denken“ ins Team zu bringen. Aber genau das macht die Rolle als Scrum Master auch so spannend und lehrreich.

Ich freue mich auf all das Kommende in meiner neuen Rolle und natürlich auch auf weitere Scrum Master Kollegen. 😉 Wenn Du also auch Interesse hast, zukünftig als Scrum Master unser Team zu unterstützen, dann melde Dich gerne bei unserem Personalteam unter jobs.digitalinnovation@zeiss.com.

Paartherapie – Dienstleister erfolgreich integrieren

Zusammenarbeit

In einer Studie der Capgemini (Capgemini Consulting, 2016) benennen die Befragten „Zu wenig Mitarbeiter mit entsprechendem Know-how“ als größte Hürde der Digitalisierung in ihrem Unternehmen. Nicht selten versucht man, diesem Problem durch die Integration eines oder mehrerer externer Dienstleister beizukommen. Aus gleicher Studie geht zudem hervor, dass diese Dienstleister zusehends in Bereichen oder Projekten eingesetzt werden, in denen innovative Lösungen geschaffen werden sollen. Vermutlich in diesem Zusammenhang gehen durchschnittlich bereits 23,3% der Befragten in Projekten nach agilen Frameworks, Methodiken oder Philosophien wie Scrum, Kanban, DevOps oder Scaled Agile Framework vor.

Wir setzen als Dienstleistungsunternehmen schon seit Langem auf agile Vorgehensweisen. Seit 2013 bilden wir gemischte Teams aus Auftraggeber und Dienstleister nach unserem Konzept für verteilte agile Entwicklung: Ein Team, ein Office, kurz ETEO und geben diesen Teams Werkzeuge und Good Practices für diese anfangs außergewöhnliche Arbeitssituation an die Hand. Das Konzept bedient sich der Erkenntnisse aus der Befragung unserer Teams, die bereits nach diesem Muster arbeiteten und wurde anschließend in einem crossfunktionalen Team wissenschaftlich fundiert weiterentwickelt, wobei immer neue Erkenntnisse aus unseren Teams einflossen.

Bei uns sitzt das Team gemeinsam in einem Projektraum. Die typischerweise 2-3 physischen Räume an den einzelnen Standorten sind über permanente Videokonferenz verbunden. Jeder Standort verfügt idealerweise über einen 80-Zoll-Bildschirm pro Standort, sodass der Eindruck entsteht, das andere Teilteam durch ein Fenster zu sehen.

Ein Werkzeug, mit dem wir sowohl in unseren Teams, als auch bei externen Coachings arbeiten, ist der ETEO Wertekompass, welcher die fünf Scrum Werte Offenheit, Verpflichtung, Fokus, Respekt und Mut mit weiteren Werten vereint, die speziell – aber nicht nur – in verteilten Teams kritisch zu sein scheinen: Identität, Vertrauen, Empathie, Zusammenarbeit und Einfachheit.

Während der Coachings befragen wir die Teams meist, welcher Wert für sie der wichtigste ist. Wenig überraschend wird hier häufig der Wert Vertrauen genannt. Schon Patrick Lencioni beschrieb in seinen „Five Dysfunctions of a Team“ (Lencioni, 2002) das Vertrauen als die Basis jeglicher Zusammenarbeit im Team. Und letztlich scheinen auch die einzelnen Werte in Wechselwirkung zueinander zu stehen. Beispielsweise schafft Offenheit im Team Vertrauen untereinander. Auch ist es bei Scrum – wo nicht der einzelne Beitrag, sondern die Teamleistung zählt – nur dann möglich, sich auf ein gemeinsames Sprintziel zu verpflichten, wenn man einander vertraut.

Doch wie schafft man in einem verteilten Team Vertrauen, in dem man sich nur vergleichsweise selten sieht und kleine Missverständnisse sich nicht mal eben in der Mittagspause oder bei einem gemeinsamen Heißgetränk in der Kaffeeküche aufklären lassen? Unausgesprochene Dinge können schnell zu Konfliktherden heranschwielen und lassen das Vertrauen im Team sinken oder sogar ganz verschwinden.

Paartherapie

Deshalb ist es besonders wichtig, sich zunächst durch eine ausgiebige Präsenzphase über 4-6 Wochen kennenzulernen, um einander einschätzen zu können. Denn gerade über schriftliche, asynchrone Kommunikation wie E-Mail entstehen schnell Missverständnisse. Hier hat sich die ständige Videokonferenzschaltung bewährt, denn sie hilft zu sehen, wer gerade anwesend ist und wie sich jeder augenscheinlich fühlt. Doch selbst wenn man eine Videokonferenzanlage im Einsatz hat, sollte man darauf achten, diese nicht ausschließlich für den fachlichen Austausch zu nutzen. Ist das Vertrauen einmal gering, überrascht es uns immer wieder, wie schnell kleine verbale oder nonverbale Signale dazu führen können, dass das Vertrauen gänzlich erschüttert wird. Beispielsweise hatten wir in einem Projektteam die Situation, dass sich die Teammitglieder an einem Standort aus Bequemlichkeit im Daily vor der Videokonferenz an einen hinter ihnen stehenden Tisch lehnten. Die Kollegen am anderen Standort beschrieben, dass dies wie eine bedrohliche Front auf sie wirkte. Solche Missverständnisse treten vor allem dann auf, wenn nicht in die Stärkung des Vertrauens investiert wird und sich das Team nicht in regelmäßigen Abständen (alle 6-8 Wochen) wieder trifft.

Noch günstiger ist es, jeden Sprintwechsel an einem Standort verbringen zu können. Dies eröffnet auch die Möglichkeit, die Sprint Retrospektive gemeinsam in einem Raum durchzuführen – ein großer Vorteil bei einem Meeting, dass einen großen Mehrwert aus dem Vertrauen schöpft, das im Team herrscht. Denn Vertrauen bildet ein Fundament für den Respekt voreinander sowie für den Mut, Verbesserungspotential im Team mit kreativen, innovativen Lösungsansätzen zu entfachen.

Die Arbeit mit einem gemeinsamen Wertesystem ist jedoch nur eine Herausforderung bei der Integration eines externen Dienstleisters. Mehr erfahren Sie in unserem Vortrag „Liebling, ich habe einen Neuen – Dienstleister erfolgreich integrieren“ auf der solutions.hamburg. Der Track „Paartherapie 2.0“ bietet weitere spannende Eindrücke und Therapieansätze aus dem Spannungsfeld „IT meets Business“.

Verweise

Capgemini Consulting. (2016). IT Trends 2016. Von capgemini: https://www.de.capgemini.com/resource-file-access/resource/pdf/capgemini-it-trends-studie-2016_0.pdf abgerufen
Lencioni, P. (2002). 5 Dysfunctions of a Team. Jossey-Bass.

Unabhängigkeit der Tester im agilen Team

Qualitätssicherung

Sobald ich über Testen in agilen Teams spreche und betone, dass Tester und Entwickler sehr eng zusammenarbeiten, bekomme ich immer die Frage gestellt: Was ist mit der Unabhängigkeit der Tester?

Die Unabhängigkeit ist besonders im Wasserfall- und V-Modell-basierenden Projekten ein wichtiger Baustein und eine Sicherheit für die Qualität des Produktes. Die Tester stellen die unvoreingenommenen Prüfer der Anforderungen und der Ergebnisse der Entwicklung dar. Sie validieren beides aus der Sicht der Nutzer und durch die Trennung von den Entwicklern erwartet man eine unbeeinflusste Arbeitsweise.

In einem agilen Entwicklungsteam arbeiten alle Beteiligten im Entwicklungsprozess eng zusammen. Das Team ist interdisziplinär aufgebaut und besteht aus Testern, Entwicklern, Designer. Quasi alles was für die Umsetzung der Lösung benötigt wird. Und das Team arbeitet Hand in Hand mit dem Kunden und dem Product Owner. Die vom klassischen Vorgehen geforderte Unabhängigkeit ist natürlich in einem agilen Entwicklungsteam nicht gegeben. Aber sie wird auch nicht mehr benötigt.

Das wurde mir wieder bewusst als ich vor ein paar Tagen im Planning eines Scrum-Teams saß und die Akzeptanzkriterien für eine Story definiert wurden: Es ging um das Löschen eines Artefaktes und speziell um die Sicherheitsabfrage vor dem Löschen. Als alter Testhase schlug ich dem Team vor, ein Akzeptanzkriterium bzw. eine Testidee für den Fall aufzunehmen, indem der Nutzer auf Abbrechen klickt und dann das Artefakt nicht gelöscht werden sollte. Prompt bekam ich die Antwort zurück: „Wieso? Das ist selbst verständlich und jeder Entwickler, der dies vergisst, kommt an den Pranger“. Die Antwort kam nicht von einem Tester, sondern einem Entwickler. Und das Team war genau derselben Meinung. Und wie versprochen, sahen die erstellten Testfälle den Sachverhalt vor und gingen natürlich auf grün, weil die Entwickler es korrekt umgesetzt hatten.

Die Unabhängigkeit der Tester in der alten Welt weicht einer „neuen“ Idee: Jeder bzw. alle Projektbeteiligten sind für die Qualität verantwortlich! Außerdem sorgt die Arbeit des Product Owners für die notwendige Einbeziehung der Kundensicht. Die Tester bringen geschultes Testvorgehen in das Team ein und die Entwickler teilen ihr Wissen über Programmierung. Die agilen Prinzipien sorgen dafür, dass die – der Entwicklung nachgelagerte – Prüfinstanz nicht notwendig ist und ich habe speziell für mein Scrumteam das Vertrauen, dass sie auch die weiteren Stories korrekt umsetzen werden.