Agilität als Gesundheitsrisiko...Agilität als Gesundheitsrisiko? Frankfurter Entwicklertag 2018...

Agilität als Gesundheitsrisiko? Frankfurter Entwicklertag 2018

21. Februar - Conference Day

Goethe Universität, Frankfurt

Dr. Stephanie Porschen-Hueck

Dieses Forschungs- und Entwicklungsprojekt wird mit Mitteln des Bundesministeriums für Bildung

und Forschung (BMBF) im Rahmen des FuE-Programms „Zukunft der Arbeit“ als Teil des

Dachprogramms „Innovationen für die Produktion, Dienstleistung und Arbeit von morgen“

gefördert und vom Projektträger Karlsruhe (PTKA) betreut. Die Verantwortung für den Inhalt

dieser Veröffentlichung liegt beim Autor.

Stephanie Porschen-Hueck: „Agilität als Gesundheitsrisiko?“, 21.02.2018 / Folie 2

Agilität als Gesundheitsrisiko?

Blick von außen auf neue Entwicklungstrends in der Arbeit: Agilität als Chance oder/und

(Gesundheits-)Risiko…?


Was nehmen wir uns vor (to do)?

1. Agilität in aller Munde!

2. Belastungen in der technischen Entwicklung – „alte Bekannte“

3. Agilität als Entlastung und/oder Belastung?

4. Das Projekt PräFo „Prävention von Belastungen bei formalisierter Arbeit

in der technischen Entwicklung“

5. Neue Belastungskonstellationen – Ambivalenzen und widersprüchliche

Arbeitsanforderungen

6. Lessons learned:

Agile Umsetzung der agilen Methoden, Prozesse, Organisation


Transformation

Scrum Kanban

FRAGILE

Leadership

Methods in Large Scale

Teams

… in plan driven organization

Organisation

Design Thinking

Lean project management

Manifesto

Selbstorganisation

Scaling

Arbeit 4.0

VUKA-Arbeitswelt Arbeits-welt

KA

VU

XP Feature Driven Development

1. Agilität in aller Munde

Veränderungen/Schwankungen + / geringere Vorhersagbarkeit, Planbarkeit - / Unbestimmtheit + / Mehrdeutigkeit von Phänomenen/Zuständen



Agilität: Aktualität, Verbreitung, Bedeutung

● Agile Methoden haben sich neben dem klassischen Projektmanagement –

auch außerhalb der IT – etabliert

● Nutzung in der Softwareentwicklung dominiert, aber 40 % setzen agile Methoden in

„nur“ IT-nahen Themen ein, 34 % in Themen ohne IT-Bezug.

● Bei drei Viertel der Befragten aber erst seit ca. vier Jahren ein (also seit 2012)

● Nutzung agiler Methoden hat in den letzten Jahren über die IT hinaus deutlich

zugenommen (obwohl z. B. die Scrum-Methode in ihren Grundzügen bereits seit 1995

bekannt ist.)!

2016 am BPM-Labor der Hochschule Koblenz in Zusammenarbeit mit der GPM Deutschen Gesellschaft für Projektmanagement und der IPMA –

International Project Management Association, Studie mit über 1.000 Teinehmern in mehr als 30 Ländern: http://www.status-quo-agile.de/

Abschlussbericht: Status Quo Agile 2016/2017; Prof. Dr. Ayelt Komus




● Die Mehrheit setzt agile Methoden nicht in Reinform, sondern in hybrider

oder selektiver Form ein

● 20 % arbeiten vollständig nach einer agilen Methode (die zweitkleinste der

unterschiedenen vier Gruppen)

● 12% arbeiten durchgängig nach klassischen Projektmanagementmethoden (kleinste

Gruppe)

● Vorherrschende Einsatzformen sind vor allem Anwendungen in hybrider 37 % und in

selektiver Form 31 %







● Meistgenutzte Methoden sind Scrum (57%), Kanban (24%) und Lean

● Agile Methoden werden von ihren Anwendern äußerst positiv bewertet

● 73 % sehen Ergebnis- und Effizienzverbesserungen durch agile Methoden und damit

höhere Erfolgsquoten als durch klassisches Projektmanagement

● Dabei weist der

Einsatz agiler Methoden in Reinform höchste Erfolgsquote auf

und die Vermischung von agilen und klassischen Projektmanagementmethoden (hybride

Form agiler Methoden) erzielt einen deutlich höheren Erfolg als der durchgängige Einsatz

des klassischen Projektmanagements.

(Nur 20 % der Teilnehmer nutzen agile Methoden „by the book“; hybride und selektive

Methodennutzung dominieren.)







● Agil statt nach dem Wasserfallmodell entwickeln:

weniger Integrationsprobleme der Teilentwicklungen, geringere Fehlerzahlen

kurz vor dem Release-Termin, laufende Kommunikation Team, Kunden, Ergebnis-,

Effizienzsteigerung, höhere Erfolgsquote …

= ENTLASTUNG … !

Also … ALLES GUT ?


● Straffe interne Marktsteuerung der Projektarbeit in IT-Unternehmen …

… birgt tendenziell die Gefahren einer Belastungskombination aus einer oftmals

vorhandenen Extensivierung von Arbeitszeiten und einer zunehmenden

Intensivierung der Arbeit.

Gerlmaier, Anja; Latniak, Erich (2013): Psychische Belastungen in der IT-Projektarbeit – betriebliche Ansatzpunkte der Gestaltung und ihre

Grenzen, in: Junghanns, Gisa; Morschhäuser, Martina (Hrsg.): Immer schneller, immer mehr : Psychische Belastung bei Wissens- und

Dienstleistungsarbeit. Wiesbaden: Springer Fachmedien Wiesbaden, 2013, S. 165 - 193

● Gesundheitsbezogene Risiko-

potenziale ergeben sich auch

aus den dominanten organisato-

rischen Veränderungskonzepten

und ihrer innerbetrieblichen

Umsetzung



● Ursachen für die psychischen Belastungen

● Ursachen für die Intensivierung der Arbeit:

Personalabbau

Neue Kapazitätsplanungssysteme (der Einzelne ist in verschiedenen Projekten

parallel eingesetzt, um eine „volle Auslastung“ zu erreichen)

● Ursachen für Arbeitsunterbrechungen:

„Service-Level-Agreements“ (SLAs) (Bearbeiten von SLAs führt zu

Arbeitsunterbrechungen)

● Eine Mehrheit ist von Mehrfachbelastungen betroffen

● Mehrfachbelastungen wirken sich „aufschaukelnd“ mit Blick auf erlebte

(negative) Beanspruchungsfolgen aus.

Gerlmaier, Anja; Latniak, Erich (2013): Psychische Belastungen in der IT-Projektarbeit – betriebliche Ansatzpunkte der Gestaltung und ihre

Grenzen, in: Junghanns, Gisa; Morschhäuser, Martina (Hrsg.): Immer schneller, immer mehr : Psychische Belastung bei Wissens- und

Dienstleistungsarbeit. Wiesbaden: Springer Fachmedien Wiesbaden, 2013, S. 165 - 193



● Häufige Stressfaktoren bei der Projektarbeit in Entwicklungsprozessen

über Zeitdruck hinaus:

● Zeitdruck Gefahr, Ziele hinsichtlich Qualität, Kosten und

Termine nicht einzuhalten à Überstunden,

Selbstausbeutung etc.

● Optionsstress Entscheidungen aus Vielfalt der Optionen beim

Entwickeln; verstärkt durch Zeit- und

Ressourcenknappheit

● Kooperationsbelastungen Aushandlungs-, Verständigungs-, und

Lernprozesse, v.a. mit anderen Unternehmen

Kalkowski, P., & Mickler, O. (2015): Kooperative Produktentwicklung, Fallstudien aus der Automobilindustrie, dem Maschinenbau und der

IT-Industrie, Nomos Verlag



● Demografischer Wandel und Prävention in der IT-Branche – Gesundheit

am seidenen Faden

● Auch in der ‚jungen‘ Innovationsbranche IT werden die Mitarbeiter älter…

● Veränderung der betrieblichen Sozialordnungen

● Unsicherheit und permanente Bewährung

● Leistungsverdichtung

● Paradoxien neuer Managementkonzepte

Verlust von Kohärenzsinn


Andreas Boes, Tobias Kämpf, Katrin Trinks (2009): Gesundheit am seidenen Faden – Zur Gesundheits- und Belastungssituation in der IT-Industrie. In: ver.di (Hg.): Hochseilakt - Leben und Arbeiten in der IT-Branche. Ein Reader. Berlin, S. 53-64.


● Belastungen in der Innovationsarbeit, vor allem dann, wenn …

… keine Erfolgserlebnisse eintreten

… keine ausreichenden Regenerationsphasen vorhanden sind

… und die Kernaufgaben in der Arbeitszeit überwiegend nicht erfüllt werden können

● Problematisch ist es auch, wenn …

… formelle Prozesse nicht zu Arbeitsrealität passen und zu Mehrarbeit führen

… Dokumentationsaufgaben überhand nehmen

… „geerbte Aufgaben“ erledigt werden müssen

… Meetings formal aufgesetzt sind und den Kern des Informations- und

Wissensaustausches einschränken.


Wühr, D., Pfeiffer, S., Schütt, P., & Huchler, N. (2012). Innovation an der Grenze. In Smarte Innovation, VS Verlag für Sozialwissenschaften, S. 141-164.


Potenziale …

… des agilen Manifestes

● Versuch, Softwareentwicklung von bürokratischen Hürden wie überbordenden

Dokumentationsanforderungen und Vertragswerken sowie unrealistisch detaillierten

Planungen und Bevormundung zu befreien

Individuen und Interaktionen stehen über Prozessen und Werkzeugen

Funktionierende Software steht über einer umfassenden Dokumentation

Zusammenarbeit mit dem Kunden steht über der Vertragsverhandlung

Reagieren auf Veränderung steht über dem Befolgen eines Plans http://agilemanifesto.org/

… des am weitesten verbreiteten Ansatzes Scrum

● Sprint Planning als empowernde Selbstorganisation

● Sprint als Schutzraum

● Daily Scrum als „schnelle“ Abspracheplattform (vs. langatmige Meetings)

● Kollaboration als strukturelle wie personale Voraussetzung

Sauer, Stefan (2017): Agile Project Management as a Generator of Stress Relief and Efficiency? http://dx.doi.org/10.18374/IJSM-17-2.5. In: International Journal of Strategic Management, Heft Volume 17, Issue 2, pp. 64-74.

3. Führen die neuen Formen des agilen Projekt-managements zu weniger Arbeitsbelastung?


● Häufige(re)s Erleben von Erfolgen, bzw. weniger Misserfolgen da Wert auf kurzzyklische

Iterationsphasen und die Herstellung frühzeitig demonstrierbarer Zwischenergebnisse gelegt

wird, die ein schnelles Feedback aus dem Nutzungskontext erlauben. (Die Konzentration

auf Länge des Projektsprints und nicht auf gesamten Projektgegenstand kann zudem

Komplexitätsstress reduzieren)

● Prinzipiell Möglichkeit für Regenerationsphasen, die gegen Ansprüche von außen gesichert

sind, da das Team während der kurzen Iterationsphasen in den agilen Projekten selbst plant

und gemeinsam schätzt, was in dieser Phase realistisch an Arbeit geleistet werden kann

● Option auf Entlastung von arbeitsausgelagerten Kommunikationsaufwänden besteht,

da arbeitsorientierte Treffen auf kurze Zeiträume begrenzt sind und übergeordnete

Abstimmungserfordernisse an Akteure außerhalb des Meetings/des Teams delegiert werden

● Prinzipielle Chance auf weitgehende Fokussierung auf die Kernarbeit und auf die Erfahr-

barkeit der Gebrauchswertorientierung der eigenen Arbeit, da agiles Projektmanagement

das Team weitgehend von Aufwänden für übergeordnete Controlling- und Steuerungs-

ansprüche befreit

Pfeiffer, Sabine; Sauer, Stefan; Ritter, Tobias (2014): Agile Methoden als Werkzeug des Belastungsmanagements? Eine arbeitsvermögenbasierte

Perspektive. In: ARBEIT. Zeitschrift für Arbeitsforschung, Arbeitsgestaltung und Arbeitspolitik, Heft 23 (2), S. 119-132.

3. Führen die neuen Formen des agilen Projekt-managements (Scrum) zu weniger Arbeitsbelastung?


● Agile Methoden werden bei dem Teilkriterium „Mitarbeitermotivation“

besser bewertet als klassische Projektmanagementmethoden

● Bei Teammotivation und Teamwork werden besonders positiv bewertet

Scrum, Kanban, XP und Design Thinking

Vgl. BPM-Labor, Prof. Dr. A. Komus, Internationale Studie: Status Quo Agile 2014. www.status-quo-agile.de

3. Unterstützen die agilen Methoden die Mitarbeiterzufriedenheit und das Teamplay?


3. Agilität als Entlastung! Ja ___ aber …

https://www.scrum.de/die-herausforderungen-bei-scaling-agile/

„Agilität ist ein Mindset.

Bei ihrer Transition weg von alten Arbeitsweisen

halten sich die meisten Unternehmen an den Mythos

„Agile anzuwenden“. Es ist ein großer Unterschied,

„Agile anzuwenden“ oder „Agile zu sein.“


4. „Gesundheitsrisiko“ Innovations-/Entwicklungsarbeit im agilen Umfeld

Häufiges Scheitern an der Art der Realisierung, an der Passung,

am fehlenden Schutzraum in der Gesamtorganisation sowie

an der Sozialdynamik im agilen Team!

PräFo Empirie …


Untersuchungsdesign ...

4. „Prävention von Belastungen bei formalisierter Arbeit in der technischen Entwicklung“ (PräFo)


● Spannungsfeld zwischen formalen ergebnisorientieren Arbeitsstrukturen

sowie Freiräumen für selbstorganisiertes und informelles Handeln

● Herausforderungen und Belastungen, die sich z.B. aus agilen

Vorgehensweisen einerseits und der Formalisierung von (auch) diesen

Prozessen sowie überprüfbaren Ergebnissen andererseits bilden

● Gestaltungsmaßnahmen für ein partizipatives Präventionsmanagement,

das in agile Methoden des Projektmanagements integriert wird

Also nicht Ent-, sondern Belastungen bei AGILITÄT?

4. Das Projekt PräFo


4. Agile Methoden und Einsatzlogik: Flexibilisierung oder Formalisierung?

Agile Methoden

Vorgehen ohne definierte Methode

informal

… agil einsetzen

Schwergewichtiger Prozess

formal

Flexibilisierung Formalisierung

● Projektmanagement zwischen „hierarchischen Tankern“ und

„hemdsärmeligem Vorgehen“

● Agiles Projektmanagement als ‚rahmende Öffnung‘ und ‚maßvolle

Formalisierung‘


4. Agilität und Implementierungslogik

Lehrbuch theoretisierend

Arbeitsprozesslogik rahmend

Kontrolllogik instrumentalisierend

● Scrum als Prozessbeschleuniger und Belastungsminimierer?

● Heterogene Umsetzung/Ausgestaltung von Agilität zwischen Lehrbuch-,

Kontroll- und Arbeitsprozesslogik

● Unterschiedliche Grade der Vermischung mit konventionellen Konzepten /

verschiedener agiler Ansätze

“[…]agile project means that you work

under pressure and every delay has

impact on the delivery […] In waterfall you

are more relaxed. You do not have time

pressure, so you have all dependencies

from other team because you have your

task which you can do a long time and you

can switch tasks maybe in your calendar, if

you are stuck with something. This is why I

say waterfall is a more relaxed project. “


Projektorganisation

Reorganisation

Embedded Entwicklungen

Agiles Projektmanagement

Selbstorganisation und professionelle

Informalität

Unternehmensorganisation

und -kultur

Ambivalenzen /

widersprüchliche

Anforderungen

5. Agilität im Spannungsfeld: Selbstverausgabung, Teamdruck und Stress durch die Verhältnisse

Sprint Schutzraum Taylorisierung

Daily Scrum wechselseitige

Hilfestellung Kontrolle,

Selbstdarstellung, sinnentleerte

Routine

Rollendefinitionen Verantwortlichkeit

und Klarheit kontraproduktive

Überstilisierung (forcierte

Rollenerfüllung)

Leistungssteuerung durch Transparenz

Kundenfeedback Kooperation /

Orientierung Maßlosigkeit in den

Anforderungen

Betriebsklima offen geschlossen

Fremd- und Selbstorganisation Agile

Scaling (dezentral) Hierarchie - Stab- und

Linienorganisation (zentral)

Formelle/informelle Standards (von DIN Normen bis „Entwicklerszene“)

nachvollziehbar unverständlich

Timeboxing Orientierungsrahmen

unangemessener Zeitdruck

Aufgaben aus alten Projekten

Paperwork (administrative Tätigkeiten) on

top

Multiprojektmanagement Zusammenhängende Projekte Strategie- Zielkonflikte

Kundenorientierung Orientierung am Standardprodukt Individualisierung

Projektmanagement-formen (Stage Gate, Scrum, IT-Kanban) Vereinbarkeit / Synchronisation Widersprüche/

Retrospektive Reflexion der agilen

Arbeitsprozesse Kampfbühne, Machtbühne

Schätzen im Team

Komplexität Überplanung

Standortübergreifende Zusammenarbeit Remote Teams Face to face- Verbindlichkeit?


5. Agilität und Belastungen: Selbstverausgabung und Teamdruck

Ambivalenzen /

widersprüchliche

Anforderungen

Selbstorganisation und professionelle

Informalität

„…, dass sich viele erst mal mehr Aufgaben

aufhalsen, als sie eigentlich machen können.

Gerade eben aufgrund von dieser Motivation

auch, die allein mal dadurch entsteht, dass ich

selber planen darf. […] Wie viel allein das

ausmacht […], dass ich mal nicht mehr der bin,

der irgendwie so Befehlsempfänger ist

sozusagen, sondern sagt hey, ich darf jetzt hier

mal selbstständig schauen, was mache ich

eigentlich…“

„Ich glaube, dass ich mir den [Druck]

selber mache. Man kriegt schon mit, von

wegen Leute warten auf gewisse Sachen,

also es ist ein bisschen da, aber mehr so

aus der Natur der Sache, fachlich ist es

einfach so gegeben, dass es

Abhängigkeiten gibt, wir können erst das

machen wenn das da ist oder man weiß,

das soll für den Kunden fertig sein und

hat eine Deadline. Also es kommt nicht

von den Kollegen, sondern aus den

Aufgaben selber sage ich mal…“

Siehe zu dieser Form der Belastung auch: Moosbrugger, Jeanette (2008): Subjektivierung von Arbeit:

Freiwillige Selbstausbeutung. Ein Erklärungsmodell für die Verausgabungsbereitschaft von Hochqualifizierten. Wiesbaden.


5. Belastung im agilen Team (Fallbeispiel)

Agiles Entwicklerteam in einem osteuropäischen Projekt (Fallskizze)

● Agiles Team mit zunächst 6 sehr guten Entwicklern wurde aus einem Mitarbeiterpool

zusammengestellt: Gute Teamdynamik!

● Das agile Team schrumpft auf 4 Mitarbeiter, da der Auftrag nach einer Zeit weniger

Kapazitäten erforderte: Veränderung der Teamdynamik!

● Das agile Team schrumpft sich selbst, mit Blessuren für ein Teammitglied: Kaputte

Teamdynamik!

Was ist geschehen?

Selbstgemachter Leistungsdruck

Leistungsdivergenz im Team

Kohäsion und Chemie im Team?

Scrummaster – wo und wie?


Leistungskultur „von innen getrieben“

● Highperformer treibt hohes Tempo im Team („Maßstab im Planning Meeting

hochgehängt!“)

● Entwicklungsgeschwindigkeit konnte einer mittragen (erste Qualitätseinbußen), zwei trotz

produktiver Arbeit nicht

Abgehängt 1: Immer weniger aber noch ordentliche Arbeitsergebnisse. Irgendwann sind

aber keine Codezeilen mehr von ihm in das Produkt eingeflossen der Highperformer

hat ihn mitgezogen

Abgehängt 2: Komplett abgehängt und in sich zusammengefallen. Nichts von dem, was

er einbringen wollte, wurde angenommen. Wurde fallen gelassen!

● Selbsterzeugter Leistungsdruck im Team und persönliche Beziehungen (Koalitionen) mit

entscheidend

Abgehängt 2:

• Zu dem Zeitpunkt – schwierige Jobverhältnisse, Verlust – hoher persönlicher Druck!

• Druck im Team zu groß, schlechtere Joboption: Mobbing und Gesichtsverlust!




Rolle des Scrum-Masters?

Als Scrummaster war ein Manager benannt

Scrummaster war nicht aktiv, um das Team zu schützen (hatte das Team nicht im Griff)

Angst, dass Highperformer das Unternehmen verlässt – obwohl sich dieser viel erlaubt

Motivation des Highperfomers nicht ergründet (keine Akzeptanz für Codes, die er nicht

selbst geschrieben hat)

● Gruppendynamische Prozesse müssen begleitet werden

● Highperformer nicht immer die besten Teamplayer – Agilität Verbesserung der

Kollaboration?


Selbstorganisation

und professionelle

Informalität ?

Timeboxing Orientierungsrahmen unangemessener Zeitdruck


Daily Scrum wechselseitige Hilfestellung Kontrolle, Selbstdarstellung, sinnentleerte Routine

Rollendefinitionen Verantwortlich-keit und Klarheit leere „Labels“


Retrospektive Reflexion der agilen Arbeitsprozesse

Kampf-,Machtbühne

Kundenfeedback Kooperation / Orientierung Maßlosigkeit in den Anforderungen

Planning und Estimation Poker Realistische Planung im Team (Komplexität, Überplanung

“Kompetenz-/Leistungscheck“

Ambivalenzen /

widersprüchliche

Anforderungen

5. Agilität und Belastungen: Ambivalenzen im agilen Projektmanagement (Bsp. Scrum)


Selbstorganisation

und professionelle

Informalität ?

5. Belastungen im agilen Projektmanagement am Beispiel von Scrum



Daily Scrum wechselseitige Hilfestellung Kontrolle, Selbstdarstellung, sinnentleerte Routine Rollendefinitionen

Verantwortlichkeit und Klarheit kontraproduktive Überstilisierung (forcierte Rollenerfüllung)


Retrospektive Reflexion der agilen Arbeitsprozesse Kampfbühne, Machtbühne


Planning und Estimation Poker Realistische Planung im Team

“Kompetenz-check“

„Es ist halt so, diese Prio-Listen, die da jede Woche auch rum geschickt werden, das ist sowieso immer, da könnte man locker zwei Wochen mit füllen, es ist halt immer für

eine Woche.“

“…One date is the sprint delivery, … Well, here we have this stress for two days every sprint …”

„Und das sehe ich im Moment wirklich als riesen Problem an. Da geht bei mir alles auf Blockade und auf Schutz, Schutzmechanismen und weg und lass, ich höre dann vorbei.“

„Also das durchschnittliche Belastungsniveau ist in einem

Teamprojekt sicher höher, weil du einfach ständig unter Strom bist mit der Prämisse, jeden Sprint

einmal zu liefern, aber was du nicht hast ist, dass du dann am Ende

einfach diesen Big Bang hast. Diese komplette Krise. „

„Das sagt ja der Kollege .. auch, jetzt mal auf diesen Scrum Prozess bezogen. Also er kannte eher Projekte, wo danach dann immer auch noch so eine Testphase kam, wo ja auch dieses Scrum Entwicklungsteam dann mal ein Stückweit durchatmen konnte und dann mehr so ein Bugfixing machte, und im Moment challengen wir die mehr, also ein Entwicklungsthema nach dem anderen und erwarten, dass es dann auch noch getestet und zeigbar ist. Und das, also der ächzt im Moment ein bisschen hörbar.“

„Woran liegt das, dass die Schätzungen so abweichen von der Zeit, die wirklich gebraucht wird? … B1: Das liegt auch daran, dass manche Technologie neu ist, das heißt wir haben keine Erfahrung vorher. Und es wurde geschätzt, okay, zwei Wochen, aber man muss dann vorher auch etwas lesen um das Prinzip zu verstehen, dann dauert es länger.“

„Also […] mein Eindruck war, die meisten haben diese […] 15 Minuten abgesessen und gesagt, ich mach heute das und ich mache heute das, und also man, es kam zu wenig von diesem Team, von dieser Teamidee rüber.

„Eine wichtige Sache bei der Fehlerkultur ist meines Erachtens, wenn man mal mit dem Team anfängt, dass man die Retrospektive zum Beispiel als einzigen Ort sieht, der nicht transparent ist. Also es gehört auch ein Ort dazu, der geschützt sein muss. Und da ganz klar, das ist die Retrospektive. Und da muss man wirklich aufpassen, das was in der Retro gesagt wird, dass das nicht nach außen dringt. Und da muss der Coach sehr stark drauf achten und muss auch Dinge, die er dann aus der Retrospektive rausträgt fragen, ist das jetzt okay…“

„[…]der Product Owner schreibt eigentlich keine User Storys, sondern so Mini-Spezifikationen, wirft die über den Zaun und das Team soll das dann machen. Es ist

auch meistens so, der schreibt das und dann soll danach geschätzt werden. Es wird immer so dieses …

es ist eigentlich, als ob man Wasserfall nur auf Miniatur hat.“

„Und, aber an diesem Endtermin hat sich nichts geändert, also der Endtermin ist fest. Der wird sich auch nicht ändern lassen. Also wir müssen den Endtermin stemmen, egal wie, egal mit welchen Ressourcen. So ist der Plan. Das wir zu wenig sind im Team das ist ja allgemein bekannt, auch Single Source wird immer schwieriger wenn einer zum Beispiel unser Hardwareentwickler ist komplett alleine. Wenn er ausfällt, das ist ein Problem. „


Agiles Projektmanagement


Daily Scrum wechselseitige Hilfestellung Kontrolle, Selbstdarstellung, sinnentleerte Routine

Projektorganisation

Selbstorganisation

und professionelle

Informalität

Embedded Entwicklungen

Rollendefinitionen Verantwortlichkeit und Klarheit leere „Labels“



Ambivalenzen /

widersprüchliche

Anforderungen


Aufgaben aus alten Projekten

Paperwork (administrative Tätigkeiten) on top

Multiprojektmanagement

Kundenorientierung Orientierung am Standardprodukt Individualisierung

Projektmanagement-formen (Stage Gate, Scrum, IT-Kanban) Vereinbarkeit / Synchronisation Widersprüche/

Retrospektive Reflexion der agilen Arbeitsprozesse Kampfbühne, Machtbühne

„Und muss dann entsprechend als Projektleiter diese Teammeetings und die

Meetings mit den Gatekeepern dann vorbereiten und Präsentationen, Folien

und habe noch als Aufgabe als Entwicklungsleiter diese ganzen Lastenhefte

und Pflichtenhefte zu erstellen. D. h. im Prinzip habe ich als Entwicklungs-

leiter zu wenig Zeit, da ich die anderen Aufgaben noch hier bewerkstelligen

muss.“

5. Agilität und Belastungen: Ambivalenzen konventionelles-agiles Projektmanagement und Zusammenarbeit im Rahmen unterschiedlicher Projektlogiken


● Teamdynamik konventionelle Entwicklung/PM und agiler Entwicklung

● Gegenseitiges Verstehen ist schwierig

● Abgleiten in gegenseitige Vorwürfe, z.B. über verschiedene Standorte

● „Traditionelle“ Entwickler fühlen sich überrumpelt, abgewertet und haben Ängste

bis hin zum Arbeitsplatzverlust

● „Agile“ Entwickler sehen sich missverstanden und ausgebremst

● Bei der Einführung als Herausforderung benannt

● Ansprüche in agilen Entwicklungsprozessen wie „zusammen Reden“ und

„Teamcomittment“

● Anspruch an das Team, Verantwortung für die Planung(sschritte) zu übernehmen

● Verbreiterung des Aufgaben- und Anforderungsspektrums

● Arbeitsunterbrechungen durch KundInnen und KollegInnen

● Emotionale Belastungen durch Kundenkommunikation

● Integration widersprüchlicher Anforderungen

5. Agilität und Belastungen: Ambivalenzen konventionelles-agiles Projektmanagement und Zusammenarbeit im Rahmen unterschiedlicher Projektlogiken (Fallbsp.)


Betriebsklima

offen geschlossen

Fremd- und

Selbstorganisation

Agile Scaling

Hierarchie - Stab- und

Linienorganisation

Formelle/informelle

Standards (von DIN Normen

bis „Entwicklerszene“)

nachvollziehbar

unverständlich

5. Agilität und Belastungen WAA Selbstorganisiertes PM – formale Organisation

Aufgaben

aus alten

Projekten

Paperwork/Controlling

(administrative

Tätigkeiten) on top

Multiprojektmanagement Kundenorientierung Orientierung am Standardprodukt Individualisierung

Projektmanageme

nt-formen (Stage

Gate, Scrum, IT-

Kanban)

Vereinbarkeit /

Synchronisation

Widersprüche/

Projektorganisation

Unternehmensorganisation

und -kultur

„Wir haben auch schon zum Scherz gefragt,

ja, wohin buchen wir die Zeit, die wir fürs

Buchen brauchen. Da hat es keine Antwort

gegeben.“

„Und was ich da erlebe, mal als Beispiel in einer Firma, einem mittelständischen

Unternehmen, hat die Führungskräfte, die Geschäftsführer unser Jahresseminar, wo

die ganze Firma eingeladen ist, das soll jetzt mal … sollen die Mitarbeiter mal selber

organisieren und wollten sozusagen mal loslassen, sollen die selber organisieren.

Und dann eine Woche oder zwei Wochen, bevor dann dieses Seminar war, haben sie

sich mal zeigen lassen, wie ist denn euer Konzept, und dann hat es ihnen überhaupt

nicht gefallen. Total eskaliert und dann haben sie auf den Tisch gehauen und dann so

nach dem Motto, ja, wir haben es ja gleich gewusst, dieses ganze autonome Arbeiten

funktioniert nicht. Und da habe ich gesagt, naja, also da habt ihr ein komplett falsches

Verständnis von autonomem Arbeiten. Weil wenn die Leute nicht wissen, was ihr

wollt, dann können die das sicher auch nicht ausrichten. […] Weil es ergibt natürlich

einen Zusammenhang und natürlich ist das Team in einem größeren Kontext. Und

jetzt ist sozusagen die neue Aufgabe, wie verhandeln wir jetzt unsere Motivationen?“


● Entlastung durch Freiräume, Verfügbarkeit und Einflussnahme über

(zeitliche) Arbeitsressourcen und Vermeidung von Überfrachtung…

Aber „alte bekannte“ und neue Belastungen…

● Breites Spektrum unterschiedlicher Anforderungen an das Selbst bei

widersprüchlichen Arbeitsanforderungen und „Scrum im Schnellkurs“

● Selbstobjektivierung und -rationalisierung (Böhle et al. 2011)

● Unhinterfragte Selbstorganisationsreife: Wo steht das Team, wo die

Organisation?

● Anerkennung als neuralgischer Punkt: Karriereparcours, Entlohnung,

Wertschätzung

Böhle, Fritz, Sabine Pfeiffer, Stephanie Porschen (2011): Herrschaft durch Objektivierung; in: Wolfgang, Bonß, Christoph Lau (Hg.): Macht und Herrschaft

in der reflexiven Moderne. Weilerswist, 244 -283

5. Zwischen Entlastung (Empowerment) und Belastungen durch Subjektivierung sowie Entsubjektivierung von Arbeit


● Transparenz ermöglicht neue Formen der Leistungskontrolle

Verschärfung durch Softwarewerkzeuge wie JIRA!

● Taktung / Sprints … Arbeitsextensivierung und -intensivierung,

Arbeitshetze!

Gefahr…

● Agilität als „Gelddruckmaschine“ ‚unter falscher Flagge‘ ohne Verständnis

für das „Prinzip Agilität“

5. Zwischen Entlastung (Empowerment) und Belastungen durch Subjektivierung sowie Entsubjektivierung von Arbeit


5. Gesundheitsrisiken?

● Viele agil Arbeitenden gehen regelmäßig an die Grenzen ihrer

Leistungsfähigkeit – (sehr) starke Belastung (Arbeit nicht mehr als

Herausforderung!)

● Hohe Arbeitsbelastung geht mit Stresssymptomen einher – beginnend damit,

dass das Abschalten in der arbeitsfreien Zeit immer schwieriger wird…

„Psychische Gesundheit von Erwerbstätigen ist immer Ausdruck eines komplexen

Zusammenspiels vielfältiger externer Anforderungen und individueller

Dispositionen, Ressourcen und Bewältigungsformen.“

Dunkel, Wolfgang; Kratzer, Nick; Menz, Wolfgang (2010): Psychische Belastungen durch neue Steuerungsformen. Befunde aus dem Projekt

PARGEMA. In: Heiner Keupp; Helga Dill (Hrsg.): Erschöpfende Arbeit. Gesundheit und Prävention in der flexiblen Arbeitswelt, Transcript,

Bielefeld, S. 100


6. Lessons learned: Belastung im agilen Team

● Sustainable Pace

https://www.agilealliance.org/glossary

“The Agile mindset views recourse to overtime, other than on an exceptional basis, as detrimental to productivity rather than enhancing it. Overtime tends to mask schedule, management or quality deficiencies; the Agile approach favors exposing these deficiencies as early as possible and remedying their underlying

causes, rather than merely treating the symptoms.”

Gar nicht so einfach!

Individuelle Copingstrategien können nicht alles sein…

Kümmerer?


6. Lessons learned: Agiles Team

Der Scrum Master …

… muss anerkannte und akzeptierte Rolle einnehmen können

… braucht Standing/Durchgriff in höhere Führungsebenen, um das Projektziel

erreichen zu können (Klarheit Zuständigkeit, Kompetenzreichweite etc. in der

Organisation

… muss ggf. an Spielregeln erinnern, z.B. wenn Linie durchgreifen darf, um

Anpassungen der Projektplanung (Eskalationsschema etc.) vorzunehmen

… muss Sorge tragen: „Ein Team muss als Team arbeiten können, wie ein Team…“

und kann dafür nicht ohne weiteres mehrere Rollen im agilen Team übernehmen

(z. B. Entwickler, Product Owner UND Scrum Master).

Rollen wie Scrum Master und Product Owner personell UND strukturell

sichern!


6. Lessons learned: Ambivalenzen im agilen Projektmanagement

● (Arbeits-)Anforderung und relevante Fähigkeiten der Entwickler müssen

zusammenpassen (herausfordernde, machbare Anteile des Projektgegenstands

im jeweiligen Projektsprint)

● Agile Implementierung: Eigenlogiken teambasierter Selbstorganisation und

Kompetenzausstattung (Zeit, Ressourcen, Durchsetzung) der Rollen (Scrum:

Product Owner, Scrum Master) beachten (z. B. keine Kontrolllogik im Daily!…)

● Kommunikationspartner im Projektteam dürfen gewisse Anzahl nicht

überschreiten (ideal 7, höchstens 8-10?)

● Stabiles gefestigtes soziales System (Teambuilding nicht immer von neuem

beginnen)

● Selbstorganisierte Projektplanung bedarfsgerecht und arbeitsprozessbezogen

durch das Team selbst ermöglichen



● Kollektive Aufwandsabschätzung als kollektiven Lernprozess durch

abschließendes Review anstoßen. Team sollte immer realistischer werden und

durch die Reflexion freiwillige Selbstausbeutung minimieren

● D. h. fairer Umgang mit „Verschätzen“ (zu langsam arbeiten/zu viel

vorgenommen) – Lernschleife!

● Dazu Berücksichtigung zeitlicher Passung von Schulungen (‚nicht zu früh und

nicht zu spät‘)

● Bedarf an praxisgerechten Hilfestellungen, Coaching gerecht werden

● Sprint (=Kernarbeitszeit/eigentliche Arbeitsaufgabe) über konsequentes

Timeboxing vor ungeplanten Zusatzaufgaben von außen schützen, d.h. u.a.

auch Einsatz in mehreren Projekten mäßigen…

● Team arbeitet im Sprint eng zusammen und wird auch nicht von übergeordneten

Positionen beeinflusst (Rücken frei halten!), um bedarfsgerechte und

arbeitsprozessbezogene Planung zu ermöglichen


● Scrum Tag nicht überplanen (7/6 h für 8-Tag!?) und projektfreie Tage (auch mal

am Produkt arbeiten…) ermöglichen. Nachhaltige Planung = Orientierung an

gangbarer Durchschnittsbelastung, Berücksichtigung von Unwägbarkeiten und

Mikropausenkultur!

● Sensibilität für die Gefährdung des Regenerationspuffer und „Schutzraumes“

Sprint z. B. durch die IT-Kanban-Fließfertigung in der Wissens- und

Innovationsarbeit!

„Lernkurve Selbstorganisationsreife“!



● Prinzipien Regenerationspuffer und Schutzraum auch in andere Formen des

Projektmanagements bzw. der Arbeitsorganisation implementieren (Formalitäts-

Informalitätscheck!)

● Coachende, begleitende, unterstützende Führung jenseits patriarchaler Hierarchie

und indirekter Steuerung über agile Teams hinaus

● Widerspruch Top-down- und Bottom-up-Logik bearbeiten

● An- und Einpassung der Selbstorganisation in Strukturen mit agilem Mindset

● Abstimmung verschiedener agiler und nicht-agiler Logiken als Verbindungs- statt

Schnittstellen

Reporting und Dokumentation bedarfsorientiert gestalten und auf Agilität abstimmen

Aktuell und zentral: Baustelle „Reflexive Skalierung“!

6. Lessons learned: Ambivalenzen im agilen und klassischen Projektmanagement sowie der Organisation


AutorIn1, AutorIn2: Titel des Vortrags ...........................

Weitere Informationen:

Dr. Stephanie Porschen-Hueck

ISF München

Jakob-Klar-Str. 9

80796 München

+49 (0) 89 272921-0

[email protected]

Herzlichen Dank für Ihre Aufmerksamkeit

Peter Maurer & Kerstin Treutner

Maurer & Treutner GmbH & Co.KG

Leopoldstraße 14

76344 Eggenstein-Leopoldshafen

+49 (0) 7247 954550

[email protected]

Projekthomepage PräFo: www.arbeit-form-zukunft.de

mailto:[email protected]








http://www.arbeit-form-zukunft.de/





Agilität als Gesundheitsrisiko...Agilität als Gesundheitsrisiko? Frankfurter Entwicklertag 2018...

Documents

Transcript of Agilität als Gesundheitsrisiko...Agilität als Gesundheitsrisiko? Frankfurter Entwicklertag 2018...