Skip to main content
Erschienen in:
Buchtitelbild

Open Access 2023 | OriginalPaper | Buchkapitel

Agile IT-Entwicklung gesundheitsförderlich gestalten – Erfahrungen aus der betrieblichen Praxis

verfasst von : Bärbel Rolfes, Ralph Brandes

Erschienen in: Flexible Dienstleistungsarbeit gesundheitsförderlich gestalten

Verlag: Springer Fachmedien Wiesbaden

Aktivieren Sie unsere intelligente Suche, um passende Fachinhalte oder Patente zu finden.

search-config
loading …

Zusammenfassung

Bei der HEC GmbH, einem agil arbeitenden Unternehmen der Softwareentwicklung, wurden im Rahmen des FlexiGesA Projektes Methoden entwickelt und erprobt, um typische psychische Belastungssituationen zu erkennen und zu vermindern (das Legoboard). Auch wenn das Legoboard in der Praxis nicht für alle Teams hilfreich ist, hat sich doch gerade für Multi-Projekt-Teams ein deutlicher Vorteil gezeigt. Die psychische Gefährdungsbeurteilung wurde durch Adaption eines im Scrum Verfahren routinemäßig verwendeten Teilschrittes, der Retrospektive, etabliert und kann damit leichter verstetigt werden. Die Gesundheitsretro hat sich als hilfreiches Format erwiesen, um den Prozess der psychischen Gefährdungsbeurteilung in einem vertrauten Setting schnell und effektiv durchzuführen.

1 Einleitung

In diesem Beitrag geht es um die Frage, wie agile IT-Entwicklungsarbeit gesundheitsförderlich gestaltet werden kann. Dies soll am Beispiel des FlexiGesA-Unternehmenspartners, der HEC GmbH, aufgezeigt werden. Zunächst werden das Unternehmen und dessen agile Arbeitsweise vorgestellt. Danach wird die gesundheitsförderliche Gestaltung der agilen IT-Entwicklungsarbeit an zwei Beispielen, dem Legoboard und der Gesundheitsretro, näher erläutert werden. Der Beitrag schließt mit einem kurzen Fazit und Ausblick ab.

2 Die HEC GmbH

Die HEC GmbH wurde 1988 gegründet und begleitet kleine, mittelständische und große Unternehmen in unterschiedlichen Branchen sowie öffentliche Auftraggeber*innen auf dem Weg in die digitale Zukunft. Heute ist die HEC ein Teil der Unternehmensgruppe team neusta. Diese besteht aus insgesamt über 30 Unternehmen mit rund 1200 Mitarbeitenden und bietet Dienstleistungen entlang der gesamten Wertschöpfungskette aus einer Hand an.
Mit ihrem Team von 170 Mitarbeitenden in Bremen, Berlin und Essen setzt die HEC überall dort an, wo fertige Softwareprodukte zu kurz greifen. Die HEC berät Unternehmen über chancenreiche neue Technologien und Geschäftsmodelle, entwickelt fortschrittliche IT-Lösungen und qualifiziert mit Umschulungen und Weiterbildungen. Im Rahmen von Transformationen bietet sie ein breites Portfolio zu Innovationen, Digitalisierung, agiler Vorgehensweise und unterstützt bei Förderungsprojekten. Im Entwicklungsumfeld werden individuelle Softwarelösungen erstellt. Darüber hinaus bietet die HEC Entwicklungsleistungen im Umfeld von Qualitätssicherung und Test, Microsoft 365, Augmented und Virtual Reality sowie der künstlichen Intelligenz an und bildet so eine optimale Verbindung von Technologie-, Prozess- und Organisationskompetenz. So werden digitale Innovationen und Softwarelösungen mit nachhaltigem Nutzen geschaffen.

3 Agile Arbeitsweise nach der Scrum-Methode bei der HEC GmbH

Die agile Vorgehensweise zeichnet sich durch kurze Entwicklungszyklen, ein hohes Maß an Kund*innenintegration und somit frühe Feedbackmöglichkeiten aus. Der Prozess ist transparent und durch die frühen Rückmeldungen kann flexibel auf die Kund*innenwünsche eingegangen werden. Die jeweiligen Teams arbeiten hier selbstorganisiert und es erfolgt eine direkte Kund*innenabstimmung. In kurzen, regelmäßigen Abständen wird das Vorgehen geprüft und bei Bedarf angepasst (inspect and adapt).
So werden Risiken und eventuelle Fehlinterpretationen früh erkannt und mit entsprechenden abgestimmten Maßnahmen entgegengewirkt. Dies führt zu mehr Zufriedenheit bei Kund*innen und auch beim Team.
Der agilen Arbeitsweise liegt das agile Manifest1 zugrunde, das vier Leitsätze formuliert:
  • Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
  • Funktionierende Software ist wichtiger als umfassende Dokumentationen.
  • Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.
  • Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans.
Eine der am meisten gelebten agilen Methoden ist Scrum.
Das Scrum Framework ist ein Rahmenwerk, mit dem auch komplexe Aufgabenstellungen bewältigt werden können. Mit ihm werden in kurzen Abständen nutzbare Produkte mit hohem Wert erstellt.
Agile Werte
Die fünf agilen Werte Mut, Fokus, Selbstverpflichtung, Respekt und Offenheit sind die Grundlage von Scrum.
  • Den Mut haben, die Wahrheit hinsichtlich Projektfortschritt und Schätzungen zu sagen. Mutig sein, Zusagen zu geben, fokussiert zu handeln, zu Fehlern zu stehen und auch mal „nein“ zu sagen.
  • Fokus: Konzentriert an dem arbeiten, was geplant ist. Alle Bemühungen und Fähigkeiten darauf fokussieren, an den Zusagen zu arbeiten.
  • Selbstverpflichtung: Bereit sein, sich auf ein gemeinschaftlich gestecktes Ziel zu verpflichten. Aktive Mitarbeit an der Zielsetzung ist dafür notwendig.
  • Respekt: Andere Menschen und ihre Meinungen und Erfahrungen respektieren. Ein Team besteht aus unterschiedlichen Menschen.
  • Offenheit: Informationen sollen zeitnah und transparent geliefert werden. Ein Umfeld erschaffen, in dem es für Wahrheit und Ehrlichkeit einen sicheren Raum gibt. Es ist für alle Teilnehmenden wichtig zu wissen, was gerade das größte Problem ist, damit jeder zur Lösung beitragen kann.
Die wichtigen Säulen bei der Scrum-Methode sind Transparenz, Überprüfung und Anpassung. Werden die agilen Werte verkörpert und gelebt, so werden die Scrum-Säulen lebendig und bauen bei allen Beteiligten Vertrauen zueinander auf.

3.1 Rollen

Bei Scrum unterscheidet man drei Rollen: den Product Owner, den Scrum Master und die Entwickler*innen.
  • Product Owner (PO)
Der PO beschreibt und erläutert die Anforderungen an das Ergebnis der Leistungserbringung, legt die Reihenfolge ihrer Umsetzung fest und erstellt – gemeinsam mit den Entwickler*innen – das Product Backlog (priorisierte Auflistung der Anforderungen an das Ergebnis der Leistungserbringung). Der PO ist für die Pflege des Product Backlog zuständig. Somit steuert der PO das Projekt und hält dessen Wirtschaftlichkeit im Blick.
  • Scrum Master
Der Scrum Master ist dafür verantwortlich, dass die agile Vorgehensweise eingehalten wird. Er kümmert sich um die Behebung von Störungen und Hindernissen innerhalb des Projekts (z. B. mangelnde Kommunikation oder Zusammenarbeit). Der Scrum Master ist zudem als Coach für den agilen Prozess verantwortlich.
  • Entwicklung
Die Entwickler*innen realisieren die im Product Backlog priorisierten Anforderungen. Gemeinsam mit dem PO und dem Scrum Master definieren sie den Inhalt eines Entwicklungszyklus (Sprint).

3.2 Product Backlog

Das Product Backlog ist eine priorisierte Auflistung der Anforderungen an das Ergebnis der Leistungserbringung. Zu Beginn des Projektes ist es nicht vollständig, vielmehr wird es vom PO fortlaufend weiterentwickelt und aktualisiert.

3.3 Scrum Ereignisse

Der Scrum-Prozess kennt folgende Regeltermine (s. Abb. 1):
  • Sprint Planning
Im Sprint Planning wird vom PO und den Entwickler*innen festgelegt, welche Anforderungen an das Ergebnis der Leistungserbringung im nächsten Sprint realisiert werden sollen. Das Ergebnis des Sprint Planning ist das Sprint Backlog.
  • Daily Scrum
An jedem Arbeitstag treffen sich die Entwickler*innen zu einem max. 15-minütigen Daily Scrum, um den aktuellen Stand der Arbeiten zu besprechen. Auch Scrum Master und PO können am Daily Scrum teilnehmen.
  • Sprint Review
Das Sprint Review steht am Ende eines jeden Sprints. Im Rahmen des Sprint Reviews präsentiert der PO mit Unterstützung der Entwickler*innen den Kund*innen die erreichten Ergebnisse. Zudem wird überprüft, ob das gesteckte Sprintziel erreicht wurde.
  • Sprint-Retrospektive
In der Sprint Retrospektive überprüft das Scrumteam seine bisherige Arbeitsweise, um Verbesserungspotenziale zu identifizieren. Der Scrum Master unterstützt die Entwickler*innen dabei.

3.4 Selbstorganisierte Teams

Die besten Architekturen, Anforderungen und Entwürfe für die Softwareentwicklung entstehen durch selbstorganisierte Teams. Durch Selbstorganisation können aber auch Probleme entstehen. Sie birgt Risiken durch Konfliktpotentiale und Einbußen bei der Arbeitsstruktur.
Komplexe Problemstellungen können am effektivsten gemeinschaftlich gelöst werden, da Einzelne nicht alle Informationen besitzen können, um komplexe Aufgabenstellungen zu lösen. Die gesamte Verantwortung an Einzelne zu übertragen, beinhaltet ebenfalls Überforderungspotential. Solange Vorgesetzte (Teamleiter*innen, Projektleiter*innen, Projektmanager*innen, …) die „Verantwortung“ für die Arbeitsergebnisse innehaben, werden die Teammitglieder diese Verantwortung auch nicht voll annehmen.
Über die Selbstorganisation des Teams werden diese Verantwortlichkeiten gleichmäßig verteilt. Aber auch Selbstorganisation erfordert eine Struktur, an der man sich orientieren kann. Dabei ist es wichtig, dass alle Teammitglieder in die Definition der Arbeitsziele eingebunden sind und konstant darüber informiert bleiben. Dies dient der Identifikation mit dem Team und stärkt das Wir-Gefühl. Ein definierter Rahmen gibt Sicherheit. Die Führung unterstützt das Team durch Definition der Rahmenbedingungen (Budget, Raum, Arbeitsmittel usw.).
Die Säulen der Selbstorganisation sind Exzellenz, Transparenz, soziale Skills und Diversität. Nur mit einer ausgewogenen Mischung aus diesen Merkmalen kann ein Team selbstorganisiert arbeiten.
  • Exzellenz des fachlichen oder technischen Wissens.
  • Transparenz nicht nur über Arbeitsfortschritt und Teamleistung, sondern auch um Fehler und Mängel und Know-How-Defizite zu erkennen und gemeinsam anzugehen.
  • Soziale Skills sind insbesondere im Bereich der Kommunikation- und Teamfähigkeit gefordert. Hierbei gibt es verschiedene Skills, die unterschiedlich stark ausgeprägt sein können: Selbstkritik und Offenheit, Freundlichkeit und Diplomatie, Flexibilität, Verantwortlichkeit, Lernfähigkeit und Handlungsfreiheit.
  • Diversität bereichert die Arbeit durch unterschiedliche Sichten. Innovationen und Verbesserungen entstehen durch Reibung und Konflikte. Harmonie allein führt zu Stillstand.
Bei den Projekten handelt es sich um unterschiedliche Kund*innen, Branchen und zum Teil auch Technologien. Oft sind es nur ein bis zwei große Projekte und viele kleinere Projekte, die zeitgleich umgesetzt oder betreut werden. Dadurch sind Multi-Projekt-Teams, die mehrere und oft kleinere Projekte parallel bearbeiten, sehr flexibel und können kurzfristig kleinere Projekte umsetzen, ohne dass das Team neu besetzt werden muss.
Ein Multi-Projekt-Team steht aber auch vor unterschiedlichen Herausforderungen:
  • Die verschiedenen Projekte mit ihren Themen, Inhalten und Technologien bedürfen breitgefächerter Expertisen und Weiterbildungen innerhalb des Teams, die deutlich unterschiedlich zu anderen Teams sein können.
  • Der Wechsel zwischen den kleinen Projekten führt zu vielen Kontextwechseln der Mitarbeitenden und erlaubt keine durchgängige Konzentration auf ein Thema.
  • Es müssen die jeweiligen Stakeholder (Interessierte, Verantwortliche, Betroffene sowohl bei Auftraggeber*innen als auch Auftragnehmer*innen) mit konkurrierenden Prioritäten befriedigt und im Blick behalten werden. Dies gilt insbesondere für viele unvorhergesehene Aufgaben, die sich im Laufe eines Projektes vielfach ergeben.
  • Die wechselnden Anforderungen bzw. Prioritäten führen zu fehlender Stringenz in der alltäglichen Arbeit und einem ständigen Perspektivwechsel.
  • Viele kleine Projekte bedeuten auch ein wesentlich höheres Maß an stetiger Akquise, damit eine hinreichende Auslastung gewährleistet wird.
  • Die Planung vieler kleiner Projekte mit Prioritätswechseln beinhalten oft eine unübersichtliche Planung bzw. lassen eine Langzeitplanung nicht zu.
Eine übersichtliche Planung bedeutet mehr Sicherheit und mehr Aussagekraft über die weitere Auslastung des Teams. Damit können dann auch Zeiten mit hoher oder weniger hoher Belastung erkannt werden. Besonders bei Multi-Projekt-Teams, die selbstorganisiert arbeiten, ist eine Übersicht und eine Grundlage für die gemeinsame Planung unerlässlich. Eine Möglichkeit der Übersicht stellt das Legoboard dar.

4 Gesundheitsförderliche Auslastungssteuerung mit dem Legoboard

Die Einbindung von Mitarbeitenden in verschiedene Teams und damit in mehrere Projekte geht mit der Möglichkeit von Terminkonflikten und Aufgabenkollisionen einher. Eine Projektplanung ohne hinreichende Kenntnis der Ressourcen der Mitarbeitenden kann leicht zu einer Über- oder Unterforderungssituation auch und gerade in selbstorganisierten Teams führen, wenn die Be- bzw. Auslastungssituation der Mitarbeitenden untereinander nicht bekannt ist.
Die daraus resultierenden psychischen Belastungssituationen im Arbeitsablauf, etwa durch Aufgabenanforderungen, die mit den zur Verfügung stehenden (z. B. zeitlichen) Ressourcen nicht oder nur knapp zu bewältigen sind, bilden ein kritisches Merkmal, das bei unzureichender Transparenz der Belastung des Einzelnen im Team entstehen kann. Rechtfertigungs- oder Erklärungsnotwendigkeiten gegenüber anderen Teammitgliedern erzwingen eine Verteidigungsposition, die ihrerseits zu Spannungen führen kann.
Es ist also von erheblicher Relevanz, den Teammitgliedern eine transparente Möglichkeit der Übersicht über die Aus- und Belastung aller Teammitglieder zu ermöglichen.
Aus einem Team heraus kam die Idee, die Planungs- und Auslastungsübersicht mittels eines Legoboards zu visualisieren. Dieses Board soll dabei nur die aktuelle Planung darstellen und nicht die Vergangenheit dokumentieren.
In einem alle 6 Wochen stattfindenden „Campfire“ findet sich dieses Team zusammen und nimmt sich Zeit für unterschiedliche Betrachtungen: interne Weiterbildung, Organisationsoptimierungen, strategische Ausrichtungen, usw.
Thema eines dieser Campfires war es, alle Fragen rund um den Aufbau und die Nutzung eines Legoboards (s. Abb. 2) zu klären:
Was bedeuten Farben? Welche zeitliche Skalierung? Wie werden Budgets dargestellt? Wie kann das flexibel gesteckt werden? Wann wird gesteckt? Mit oder ohne Urlaub?
Dabei wurden folgende Punkte definiert:
  • Die Grundplatten sollen grau sein.
  • Jeder Kunde/jede Kundin bzw. jedes Projekt bekommt eine eigene Farbe. Eine entsprechende Legende zur Darstellung wird am unteren Rand des Boards gesteckt.
    Daraus folgt, dass ungefähr 20 verschiedene Farben benötigt werden.
  • Für Abwesenheit (Urlaub, Gleitzeit, keine Bürozeit, Krankheit) werden weiße Steine verwendet.
  • Für interne Themen (bei diesem Team z. B. Wartung und Betrieb des Intranets) wurde die Farbe Rot gewählt.
  • Ein Punkt auf einem Stein bedeutet einen halben Tag,
    ein Zweier-Stein also einen Tag,
    ein 10er-Stein somit eine Woche.
  • Horizontal wird die Zeitachse mit den Wochen und Monaten dargestellt.
  • Ein Monatswechsel wird durch eine vertikale Linie/einen Faden dargestellt.
  • Es soll mindestens ein halbes Jahr abgebildet werden.
  • Jedem Teammitglied wird eine Reihe/Zeile auf dem Board zugewiesen.
  • Zur Beschriftung des Namens des Teammitglieds, der Kund*innen- bzw. Projektnamen, der Kalenderwochen, usw. werden glatte Steine genommen.
  • Pro Projekt wird das Projektbudget in Form von Steinen auf dem Board in einem speziellen Bereich „geparkt“.
    Beispiel: Für ein Projekt mit 20 Tagen Projektbudget werden Steine mit in Summe 40 Punkten benötigt.
Daraus konnte die benötigte Anzahl an Steinen und Platten ermittelt werden; im Sinne der Nachhaltigkeit wurden diese gebraucht beschafft.
Neben der Struktur wurde auch die Aufhängung im Team konzipiert und aus Holzlatten selbst gebaut. Die Platten wurden auf Holzplatten geklebt, sodass eine Holzplatte immer ein Quartal bedeutet. Die Holzplatten wurden auf Schienen aufgehängt, sodass beim Quartalswechsel die bereits geplanten Steine nicht umgehängt werden müssen, sondern das vergangene Quartal abgenommen, die verbleibenden Quartale auf ihren Holzplatten komplett verschoben und die abgenommene Platte wieder ans Ende gehängt werden kann. Durch dieses rollierende System kann über Quartalsgrenzen hinweg geplant werden, ohne beim Quartalswechsel auch Steine umhängen zu müssen.
Das Board wurde im Teamraum aufgehängt, sodass es immer direkt im Blickfeld der Teammitglieder ist.
Dadurch ist die Teamauslastung für jeden und auch für andere Teams jederzeit einsehbar und bildet eine gute Diskussionsgrundlage, wenn neue Projekte angegangen oder übernommen werden sollen.
Zur konstanten Visualisierung für das Team wurde das Daily direkt vor dem Board abgehalten, sodass Planungsabweichungen sofort erkennbar sind. Auf notwendige Änderungen kann direkt reagiert werden. Nach neuer Planung und Abstimmung wird das Board im Daily entsprechend aktualisiert.
In einem wöchentlichen Termin (Weekly) trifft sich das Team beim Legoboard, dabei steckt jedes Mitglied die von ihm geplanten Projekte für die nächsten 2–4 Wochen. Bei Projekten mit einem festen Budget werden diese Steine aus dem geparkten Bereich genommen, sodass sofort gesehen werden kann, wieviel Budget noch zu verteilen ist.
Auch kann erkannt werden, wenn ein Teammitglied zu viele Projekte für sich plant, da in dem Fall zu viele Legosteine in einer Woche gesteckt wurden.
Viele verschiedene Farben in der Planungszeile eines Teammitglieds zeigen, dass dieses Teammitglied in vielen unterschiedlichen Projekten eingebunden ist. Dies kann zu anstrengenden Kontextwechseln führen. Auch die Erwartungshaltung von vielen unterschiedlichen Stakeholdern kann bei diesem Teammitglied zu Problemen führen. Dies wird im Weekly betrachtet und die Planung im Team gemeinsam angepasst, sodass die Aufgaben gleichmäßig verteilt werden.

4.1 Erkenntnisse zur Anwendung des Legoboards

Das Legoboard wurde parallel in einem zweiten Multi-Projekt-Team für die Planung evaluiert, um unterschiedliche Betrachtungsweisen und Ergebnisse zu erhalten.
Beide Teams haben das Board über mehrere Monate hinweg für die Planung genutzt, nach einer mehrmonatigen Evaluationszeit wurden die Erkenntnisse der beiden Teams ausgetauscht.
Das Board hat sich als sehr sinnvoll für selbstorganisierte Teams mit vielen verschiedenen Aufgaben erwiesen.
Die Weiterentwicklung der Selbstorganisation wird durch das Legoboard gefördert, es lassen sich Weiterbildungsbedarfe im Team erkennen und es hilft Überlastsituationen einzelner Mitarbeitender mit spezifischer Expertise zu vermeiden.
Das Board erhöht die Transparenz in der Planung, aber auch in der Kommunikation innerhalb des Teams, da der aktuelle Arbeitsschwerpunkt der einzelnen Mitglieder für jeden sofort ersichtlich ist. Es lassen sich auch weitere Erkenntnisse entwickeln, bis hin zur strategischen Ausrichtung aufgrund der sichtbaren Auslastung in unterschiedlichen Bereichen oder Kund*innenumfeldern.
Für Teams, die neben kleinen Projekten auch große Projekte umsetzen oder Mitglieder haben, die ausschließlich an einem Projekt arbeiten, ist diese Methode weniger hilfreich. Hier hat sich gezeigt, dass nur für einige Mitglieder die Planung regelmäßig aktualisiert und dargestellt werden muss. Bei Mitarbeitenden, die dauerhaft in einem Projekt eingebunden sind, werden immer durchgehend die gleichen Steine gesteckt. Für diese Kolleg*innen hat das Board keinen Mehrwert gezeigt.
Die Projektstruktur des zweiten Teams besteht zu einem erheblichen Anteil aus länger andauernden Projekten. Das zweite Team entschied sich daher gegen das Legoboard.
Das erste Team war von dem Einsatz des Boards überzeugt und hat es weiterhin genutzt.
Mit dem Beginn der Corona-Pandemie wurde komplett von zu Hause gearbeitet. In dieser Zeit zeigte sich, dass die Transparenz und die Möglichkeiten, die das Legoboard bietet, dem Team sehr fehlten.
Da einige Teammitglieder schon vor der Pandemie teilweise im Homeoffice gearbeitet hatten, wurden alle Regeltermine seit längerer Zeit als Videokonferenz im Hybrid – Modus abgehalten (einige Kolleg*innen im Homeoffice, die anderen vor Ort im Büro).
Etwa sechs Wochen später wurde das Legoboard auf folgende Weise wieder reaktiviert:
Zum Weekly war mindestens eine Person vor Ort und schaltete sich von dort in die Videokonferenz. Mit einer Kamera aufs Board gerichtet, konnten die Teammitglieder Anweisungen geben, wie für sie die Steine jeweils gesteckt werden müssen.
Im Anschluss wurde das Ergebnis im Bild festgehalten und online allen Teammitgliedern zur Verfügung gestellt. Auf diese Weise hatte jedes Teammitglied Zugriff auf den Stand des letzten Weekly.
Aufgrund der verschärften pandemischen Lage war ab dem November 2020 keine Person mehr vor Ort. Eine räumliche Änderung innerhalb der Büros führte dazu, dass auch das Board abgehängt werden musste. Damit war das Team wieder in der Situation, dass die Planung und aktuelle Arbeitsauslastung nicht für alle übersichtlich dargestellt sind. Dies wurde durch den fehlenden Vor-Ort-Austausch noch verstärkt.

4.2 Abschließende Einschätzung des Legoboards und Ausblick

Insgesamt hat die Coronapandemie die Notwendigkeit einer hochgradigen Umstellung des gesamten Betriebsablaufs erzwungen, aber auch ermöglicht.
Die Räumlichkeiten und Arbeitsplätze in der HEC werden auf die durch die Pandemie veränderten Arbeitsweisen neu geplant und umgebaut. In diesem Zuge wird auch die für das Team notwendige Planungsübersicht mittels Legoboard berücksichtigt.
Das Team hat in den letzten Jahren unterschiedliche Methoden evaluiert und ist gemeinsam zu dem Schluss gekommen, dass das Legoboard die besten Möglichkeiten für die Visualisierung der Auslastung des Teams und seiner Mitglieder bietet.
Auch in der hybriden Arbeitswelt wird in der HEC ein physisches Board notwendig sein. Das gemeinsame „vor dem Board“ stehen führt zu Diskussionen und Austausch über die Planung, die mit einem digitalen Board in dieser Tiefe nicht erfolgen. Auch die Haptik des realen Umsteckens der Steine ist für die einzelnen Teammitglieder sehr wichtig.
Aufgrund der hybriden Arbeitsweise muss es aber digitalisiert werden, um für jeden immer sichtbar zu sein. Hier werden zurzeit Ansätze mit Fotos oder Webcam diskutiert.
Eine allen Teammitgliedern zugängliche Übersicht über die Aktivitäten und Auslastungen der einzelnen Teammitglieder erleichtert die Kommunikation und die Projektsteuerung nach der Erfahrung der Mitarbeitenden in der HEC erheblich und reduziert die Notwendigkeit etwa von „Rechtfertigungen“ bei Zeit- und Aufgabenkonflikten.
Es zeigte sich in der Praxis, dass sich das Instrument des Legoboards allerdings nur schlecht virtuell darstellen ließ: für den bestmöglichen Effekt scheint die physische Präsenz sowohl des Legoboards als auch zumindest zeitweise der Mitarbeitenden erforderlich zu sein. Dann allerdings hat es sich bei der HEC als wertvolle Unterstützung bei der Projektsteuerung und im Projektablauf bewährt.

5 Die Gesundheitsretro

Eine der größeren Herausforderungen für Themen der Arbeitsmedizin und Arbeitssicherheit ist die Verstetigung von Prozessen, die der regelmäßigen Überprüfung und gegebenenfalls Anpassung bedürfen. In Unternehmen, in denen diese Prozesse in den regulären Ablauf geplant, integriert und mit Ressourcen versehen sind, gelingt dies gut. Dort wo ein Thema neu aufgegriffen wird, z. B. die Gefährdungsbeurteilung, ist es Teil der Aufgabe, auch die Verstetigung und regelmäßige Überprüfung möglichst schon bei der Einführung zu berücksichtigen.
Instrumente und Prozesse zu nutzen, die dabei ohnehin im Unternehmen bekannt und gebraucht werden, ist eine erfolgversprechende Möglichkeit für diese Verstetigung, z. B. reguläre, physische Gefährdungsbeurteilungen bei routinemäßigen Betriebsbegehungen im Rahmen einer sich anschließenden Besprechung zu überprüfen.
Bei der HEC bot sich hierfür an das in die agile Arbeit gut integrierte und bekannte Format der Retrospektive zu wählen. Mitarbeitenden ist die Retro gut vertraut. Strukturen und Abläufe, die gut bekannt sind, erzeugen ein vertrautes Arbeitsklima, wenn der Fokus dann auf das Thema (psychische) Gesundheit und Gefährdung gelenkt wird.
Eine klassische Retro im Scrum Verfahren wird vom Scrum Master moderiert. Die Gesundheitsretro bei der HEC wurde zunächst von einer Scrum-Master-Kollegin geleitet und wird zukünftig von einer Mitarbeiterin der Personalentwicklung moderiert werden.
Wegen der besonderen Inhalte einer Gesundheitsretro ist es notwendig, die Moderator*innen mit den Inhalten und dem Rahmen psychischer Gefährdungen vertraut zu machen, wie sie gängige Verfahrensbeschreibungen zur psychischen Gefährdungsbeurteilung vorsehen:
1.
Arbeitsinhalt/Arbeitsaufgabe
 
2.
Arbeitsorganisation
 
3.
Soziale Beziehungen
 
4.
Arbeitsumgebung
 
5.
Neue Arbeitsformen
 
Dies erfolgte in einer Präsenzveranstaltung, in der genügend Zeit und Raum für Fragen und Austausch vorhanden waren.
Besondere Aufmerksamkeit erfährt das Thema „Neue Arbeitsformen“, nicht zuletzt da auch die Gesundheitsretro in dem neuen Format der Online-Veranstaltung oder später vielleicht auch als Hybridveranstaltung stattfand bzw. stattfinden wird.

5.1 Ablauf und Erprobung von Gesundheitsretros

Innerhalb eines Scrumprozesses wird in jeder Retro die Arbeitsweise des Teams überprüft. Dies geschieht in einem geschützten Raum (Las-Vegas-Regel: Was in der Retro passiert, bleibt in der Retro.).
Eine Gesundheitsretro bietet also einen geschützten Raum, in dem die Teilnehmenden ihre Situation insbesondere mit Blick auf psychische Belastungen und Stressfaktoren, aber auch gesundheitliche Ressourcen in der Arbeit reflektieren können. Dies gilt es sowohl innerhalb des Teams aber auch im Verhältnis zu den Kund*innen zu betrachten und darüber hinaus.
Das Team entscheidet in der Retro gemeinsam, welche Themen weiter betrachtet und welche Maßnahmen zur Verbesserung umgesetzt werden sollen.
Im FlexiGesA-Projektteam wurden erste Überlegungen zu einer solchen Retro angestellt:
  • Eine Gesundheitsretro sollte 2–3 h dauern. Nach Möglichkeit sollte sie einmal im Jahr pro Team erfolgen. Wenn das Format sich etabliert hat, kann es ggf. auch vom Team mit dem eigenen Scrum Master durchgeführt werden. Wenn besondere Belastungen erkannt werden, können diese Retros auch häufiger stattfinden.
  • Analog zum Scrum Master, der die reguläre Retro moderiert, sollte die Moderation der Gesundheitstretros von einem „Gesundheitsmaster“ durchgeführt werden. In einer späteren Namensfindungsphase wurde für den Gesundheitsmaster eine Umbenennung zu „HealthAngel“ vorgeschlagen.
Eine Infoveranstaltung mit dem FlexiGesA-Team der Universität Bremen, dem HEC Gesundheitsmaster und einem Kollegen mit Prokura diente der weiteren Planung und Zielsetzung von Gesundheitsretros.
Zur Struktur wurden analog zur regulären Retro diese Ideen entwickelt (s. Abb. 3).
  • Set the stage – Ankommen und Einstimmen der Teilnehmenden.
    • „Summen“: Summe oder singe ein Lied, das Deine aktuelle Situation/Stimmung widerspiegelt
    • Skala 1–10: Wie fühlst Du Dich auf einer Skala von 1 (nicht so gut) bis 10 (alles super)
    • Filmgenre: Wenn Deine aktuelle Situation ein Film wäre, welches Genre wäre es? Drama, Science-Fiction, Komödie, Liebesfilm, Thriller, …
  • Ergebnisse/Maßnahmen der letzten Retro (wenn vorhanden)
    Betrachtung der Maßnahmen, die in der letzten Retro definiert wurden:
    • Wurden sie umgesetzt?
    • Wenn messbar: Welche Ergebnisse wurden erzielt?
  • Gather data – Sammeln der Ereignisse, die in der Retro thematisiert werden sollen.
    Aus diesem Bereich sollten 2–4 Fragestellungen genommen werden und zwar immer mit einer Mischung aus positiven und negativen Abfragen.
    • Was macht mir Spaß?
    • Was stresst mich?
    • Worauf freust Du Dich bei Deiner Arbeit?
    • Was belastet mich?
    • Was fehlt mir?
    • Was kann ich Dir geben (außer mehr Geld), damit Du gerne bei uns arbeitest?
    • Was hätten wir nach der letzten Retro tun müssen, um jetzt perfekt zu sein?
    • Wenn wir eine super Retro gehabt hätten, was wäre heute anders/besser?
  • Clustern und Priorisieren
    Nachdem die Teilnehmenden zu den Fragestellungen Punkte aufgeschrieben und benannt haben, werden diese nach den bereits angeführten unterschiedlichen Bereichen einer Gefährdungsbeurteilung geclustert.
    • Arbeitsinhalt/Arbeitsaufgabe
    • Arbeitsorganisation
    • Soziale Beziehungen
    • Arbeitsumgebung
    • Neue Arbeitsformen
  • Generate insights – Analyse der zu betrachtenden Themen und Entwicklung von Maßnahmen.
    Die Cluster werden analysiert und mögliche Maßnahmen definiert, die zur Verbesserung führen können.
    • Priorisierung der genannten Punkte
    • Maßnahmen erstellen
  • Decide what to do – Entscheidung, welche Maßnahmen umgesetzt werden sollen, inkl. Terminierung und Zuweisung von Verantwortlichkeiten.
    • Priorisierung der Maßnahmen mit
      • Verantwortlichkeiten
      • Fristen
      • Kennzeichen öffentlich/privat
    • Plan der Maßnahmen
  • Closing – Abschluss und Verabschiedung
    Zum Abschluss kann die Fragestellung aus dem ersten Punkt wieder aufgenommen werden.
    Hier aber als Feedback zur Retro oder als Blick in die Zukunft.
Gemeinsam wurden Gruppen für die Teilnahme an einer Retro definiert. Hier sollen nicht nur Projektteams, sondern auch Gruppen aufgrund von gleichen Tätigkeitsfeldern gebildet werden. Dies wären z. B. Mitarbeitende aus der Verwaltung, ScrumMaster, Anforderungsmanager*innen oder auch Mitarbeitende, die viel bei Kund*innen vor Ort tätig sind.
Coronabedingt war die Mehrzahl der Mitarbeitenden von zu Hause tätig. Besonders die Entwicklungsteams waren nicht vor Ort und hatten dadurch schon einige Retros als Online-Retro durchgeführt.
Ein Projektteam mit Erfahrung in Online-Retros, ein Entwicklungsteam, wurde als erste Gruppe für die Durchführung einer Gesundheitsretro benannt. Diese Gesundheitsretro wurde dann als Videokonferenz erprobt.
Die erste Gesundheitsretro hat einige Punkte aufgezeigt, die insbesondere im Verhältnis zwischen Team und Teamleiter und im Bereich der Selbstorganisation zu verbessern sind. Nach Zustimmung der Teammitglieder waren als Beobachtende auch Mitarbeitende des FlexiGesA-Projektteams dabei (Uni Bremen, Betriebsarzt). Die Teilnehmenden der Gesundheitsretro diskutierten sehr offen und berührten zum Teil einige sehr persönliche Themen. Gemeinsam mit der Moderatorin wurden Maßnahmen definiert, die weiterverfolgt werden.
Die Durchführung der Retros und die gemeinsam definierten Maßnahmen sollen mittels Fotoprotokoll (bei Online-Retro Screenshots statt Fotos) dokumentiert werden. Dieses Protokoll wird den Teilnehmenden für ihre Dokumentation übergeben. Eine weitere Version wird zentral abgelegt und ist nur für die Gesundheitsmaster zugreifbar.
Die definierten Maßnahmen werden je nach Art unterschiedlich umgesetzt und verfolgt:
  • Teaminterne Maßnahmen nehmen die Teilnehmenden mit und verfolgen diese analog zu den Maßnahmen aus den üblichen eigenen Scrum Retros. Je nachdem welches System das entsprechende Team nutzt, erfolgt dies über das interne Ticketingsystem, als Planner-Eintrag, als Karte auf einem Board oder ähnliche Verfahren.
  • Unternehmensweite Maßnahmen oder Maßnahmen, die außerhalb der Entscheidungsbefugnis des Teams liegen, sind in der Verantwortung des Gesundheitsmasters. Diese werden im zentralen Ticketingsystem abgelegt und mit dem Team der Retro AG (s. Punkt Retro-AG) weiter ausgearbeitet und umgesetzt.
Die teaminternen Maßnahmen werden auf diesem Gesamtboard nur mit ihrem Titel und dem Verantwortlichen aus dem Team festgehalten. Der Gesundheitsmaster verfolgt und dokumentiert die Durchführung und Ergebnisse dieser Maßnahmen.
Die unternehmensweiten Maßnahmen und deren Stand werden für alle Mitarbeitende transparent dargestellt und allen zugänglich gemacht.
Aufgrund der besonderen Coronasituation wurde die Gesundheitsretro bei der HEC bisher online durchgeführt. Der derzeitige, intensive Veränderungsprozess kann aber auch zukünftig andere Formate notwendig machen, etwa Hybridveranstaltungen in Teilpräsenz oder in Präsenz.
Retros für Tätigkeitsgruppen wie Scrum Master, agile Coaches, Tester*innen sind noch zu implementieren.
Die Ergebnisse der Retros und Veränderungsvorschläge möglichst zeitnah umzusetzen, bleibt aber ein entscheidender Faktor für die Annahme und konstruktive Unterstützung der Mitarbeitenden.

6 Die Gesundheitsretro AG

Ganz entscheidend für das Fortbestehen und die konstruktive Unterstützung von Projekten –nicht nur zur psychischen Gesundheit – durch Mitarbeitende ist die Rückmeldung zu Ergebnissen oder Vorschlägen, die zu ihrer Umsetzung der Entscheidung über organisatorische Maßnahmen, finanzielle oder personeller Ressourcen bedürfen. Dabei ist es häufig zunächst wichtiger überhaupt zu entscheiden und diese Entscheidung zu kommunizieren, als die Frage, ob diese Entscheidung, z. B. über Ressourcen, positiv oder negativ ausfällt. Vorschläge oder Ergebnisse nicht zu beantworten, führt bei Mitarbeitenden leicht zu der frustrierenden Annahme das bisherige Mühe und Zeit umsonst investiert wurden und zukünftiges Engagement wenig sinnvoll wäre.
Im Rahmen einer psychischen Gefährdungsbeurteilung werden z. B. in einer ASITA (ArbeitsSITuationsAnalyse), aber auch in der Gesundheitsretro Probleme und Lösungen erarbeitet und angedacht. Dieses Engagement durch Kenntnisnahme, aber auch Entscheidungen zu würdigen und zu kommunizieren ist essenziell für das Fortbestehen solcher Aktivitäten. Dabei kann die Entscheidung durchaus lauten, dass hierfür zurzeit keine hinreichenden finanziellen Ressourcen frei sind.
Wichtiger ist dabei die – unausgesprochene – Nachricht, dass die Überlegungen der Mitarbeitenden gesehen, gewürdigt und darüber entschieden wurde.
Für diese Entscheidungen bedarf es eines Entscheidungsgremiums, das aufgrund der Besetzung die Kompetenz haben muss, solche Entscheidungen zu treffen; etwa aufgrund eines zur Verfügung stehenden Budgets oder weil entsprechende Entscheidungsträger Teil dieses Gremiums sind.
Bei der HEC setzt sich dieses Gremium aus dem kaufmännischen Leiter, einer Mitarbeiterin der Personalabteilung und einer Scrum Master-Kollegin zusammen. Dieses Team heißt Gesundheitsretro AG.
Es ist somit für folgende Bereiche zuständig:
  • Benennung von Teams und Tätigkeitsgruppen für die Gesundheitsretros
  • Planung und Durchführung/Moderation der Gesundheitsretro
  • Maßnahmen definieren und einordnen
    • „interne“ Maßnahme der Gruppe
      • Zuständigkeit außerhalb der Gesundheitsretro AG, es bleibt in der Gruppe der Teilnehmenden
    • Unternehmensweite Maßnahme
      • Zuständigkeit der Gesundheitsretro AG
Dieses Gremium ist für die Umsetzung und Verfolgung der Maßnahmen zuständig. Es informiert unternehmensweit über die Maßnahmen und deren Stand. Zusätzlich wird verfolgt, ob die gruppen- bzw. teaminternen Maßnahmen umgesetzt werden.
Auch prüft es, ob es Überschneidungen mit Querschnittsaufgaben aus anderen Teams oder Alternativen bei der Umsetzung gibt. Durch die gewählte Besetzung ist das Gremium frei in der Entscheidung, wenn es um Budget- oder Personalentwicklungsfragen geht.
Um diese Aufgaben erfüllen zu können, sind regelmäßige Teamtreffen der Gesundheitsretro AG geplant.

7 Fazit und Ausblick

Ein sehr hilfreiches Instrument zur Visualisierung von Aus- und Belastungen von Multi-Projekt-Teams und deren Mitgliedern ist das innerhalb der HEC entstandene Legoboard. Dies wird auch in der zukünftigen HEC Arbeitswelt von diesen Teams weiter genutzt werden und kann bei ähnlichen Problemkonstellationen auch in anderen Unternehmen Belastungssituationen verringern. Teams, deren Mitglieder langfristig mit nur einem Projekt beschäftigt sind, konnten nicht so stark davon profitieren.
Die Implementierung einer Gesundheitsretro als Mittel der psychischen Gefährdungsbeurteilung hat in einem agil arbeitenden Unternehmen die Erfahrung und Vertrautheit mit der Scrum Methode nutzen können, um den sonst oft mit Vorbehalten versehenen Prozess der psychischen Gefährdungsbeurteilung zu initiieren und eine erste effektive Gesundheitsretro ermöglicht. Auch die Hürde der coronabedingt virtuellen Durchführung war aufgrund der Vertrautheit mit Videobesprechungen kein wesentliches Hindernis.
Open Access Dieses Kapitel wird unter der Creative Commons Namensnennung 4.0 International Lizenz (http://​creativecommons.​org/​licenses/​by/​4.​0/​deed.​de) veröffentlicht, welche die Nutzung, Vervielfältigung, Bearbeitung, Verbreitung und Wiedergabe in jeglichem Medium und Format erlaubt, sofern Sie den/die ursprünglichen Autor(en) und die Quelle ordnungsgemäß nennen, einen Link zur Creative Commons Lizenz beifügen und angeben, ob Änderungen vorgenommen wurden.
Die in diesem Kapitel enthaltenen Bilder und sonstiges Drittmaterial unterliegen ebenfalls der genannten Creative Commons Lizenz, sofern sich aus der Abbildungslegende nichts anderes ergibt. Sofern das betreffende Material nicht unter der genannten Creative Commons Lizenz steht und die betreffende Handlung nicht nach gesetzlichen Vorschriften erlaubt ist, ist für die oben aufgeführten Weiterverwendungen des Materials die Einwilligung des jeweiligen Rechteinhabers einzuholen.
Fußnoten
1
Manifest für Agile Softwareentwicklung s. https://​agilemanifesto.​org/​iso/​de/​manifesto.​html.
 
Metadaten
Titel
Agile IT-Entwicklung gesundheitsförderlich gestalten – Erfahrungen aus der betrieblichen Praxis
verfasst von
Bärbel Rolfes
Ralph Brandes
Copyright-Jahr
2023
DOI
https://doi.org/10.1007/978-3-658-37055-8_10

Premium Partner