New Work in der IT - Eure Erfahrungen?

[Gast Pixelversteher]

Hallo zusammen,

aktuell schwappt ja der Trend "New Work" durch die Unternehmen. So ist es aktuell auch bei meinem Arbeitgeber (Mittelstand mit ca. 5.000 MA) in der (internen) IT-Abteilung. Corona und das Homeoffice waren dazu der Anstoß. Im Rahmen einer Umorganisation und der New-Work-Einführung hat sich doch einiges verändert und mit manchem fremdle ich. Daher würden mich eure Meinungen und Erfahrungen dazu interessieren.

Auf dem Papier hört sich New Work ja erstmal toll an: Selbstverantwortung, Fehlerkultur, (zeitliche und örtliche )Flexibilität, flache Hierarchien, kurze Wege, Sinnstiftung etc.....

Vieles davon funktioniert auch gut in der Praxis. Ich arbeite seit jeher sehr selbstständig und in meinem Team klappt die Zusammenarbeit wunderbar. Auch agiles Arbeiten ist kein Neuland für mich. Methoden, wie Scrum und Kanban sind mir geläufig und ich kenne die Mehrwerte der Methoden, wenn das Vorgehen zum jeweiligen Projekt passt. Es gibt gerade auch sehr viele spannende Tätigkeiten und Projekte im Unternehmen.

Mich stört jedoch das (falsch verstandene(?)) Führungsverhalten in "New Work". Die Führungskräfte sehen sich eher als Coach, denn als Entscheider. Damit kann ich im Tagesgeschäft und normalem "Grundrauschen" auch sehr gut umgehen. Leider werden auch große Projekte (teilweise mit einer Laufzeit von >1 Jahr ) nur noch bei den Teams "abgekippt" und sie sollen zusehen, wie sie zurecht kommen und wer aus dem Team ins Projekt geht - Stichwort: Selbstverantwortung. "Guten Teams" wird dabei auch mehr Arbeit aufgehalst, als "schlechten Teams". Bei letzteren habe ich da Gefühl, dass sie gedanklich schon ein wenig abgeschrieben wurden in der neuen Organisation und man die ihr Tagesgeschäft machen lässt.

Gespräche gab es zu dem Thema und zur Arbeitsbelastung schon genug. Die Führungskräfte verweigern sich jedoch jeglicher Priorisierung von Tätigkeiten und Projekten. Wenn ich selbst nach bestem Wissen priorisiere und sich jemand beschwert, der nach hinten priorisiert wurde, werde ich aufgefordert das zusätzlich mit zu machen (--> Keine Selbstverantwortung mehr, wenn es drauf ankommt.). So bin ich, neben dem Tagesgeschäft, parallel in 4 größeren Projekten. Vor lauter Meetings, Dailys und Eskalationsgesprächen schaffe ich inhaltlich kaum etwas in den Projekten beizutragen. Das empfinde ich als ziemlich frustrierend, denn inhaltlich hätte ich große Lust daran mitzuwirken und habe auch einen eigenen Anspruch an meine Arbeit.

Wie sind da eure Erfahrungen? Und wie kann ich mit diesem Führungsverständnis umgehen und zu einer Priorisierung kommen? Grundsätzlich bin ich mit den Kollegen und den Tätigkeiten in dem Unternehmen nämlich sehr zufrieden.

Danke für eure Rückmeldung.

[skylake]

Ähnliche Wandlungsprozess gibt es bei uns gerade auch massiv und einige haben genau die von dir geschilderten Probleme. Überall wird/soll agil gearbeitet werden in Strukturen, die das nicht ermöglichen. Die Antwort die du dir erhoffst wird dir hier keiner geben können, da hierfür tiefergehende Einblicke in dein Unternehmen und dessen Aufbau notwendig wäre. Solche beratenden Optimierungstätigkeiten werden im übrigen auch fürstlich entlohnt :). 

Ich selbst sehe es je nach internem Aufbau und Rahmenfaktoren auch bedenklich, wenn der Entscheidet plötzlich zum "Coach" oder "Begleiter" mutiert und es im ungünstigen Fall in einem unnötigen Overhead für die Basis endet. Das führt nicht selten zu größeren Effizienzeinbußen. 

Deine Führungsriege muss sich klar machen, wann ein Coach gefordert ist und wann nicht. Wenn sie das nicht wollen müsstest du oder andere Mitarbeiter diese Gelenkpunkte analysieren und entsprechende Veränderungen der Führungsriege vorschlagen, damit es wieder geschmeidiger läuft.

Die von dir geschilderten Meetings sind der absolute Klassiker wie Scrum und co. schief gehen kann. Dann wird aus dem 15 Minuten Daily schnell das 45 Minuten Daily oder man ist plötzlich in so vielen Projekten eingebunden, dass alleine diese Art von Treffen zu viel Zeit in Anspruch nehmen. 

Was nutzt Ihr denn genau? Scrum? Kanban? Scrumban? XP oder irgendeine Mischung aus allem?

 

[Gast Pixelversteher]

Danke für deine Antwort.

Das es da keine Musterlösung gibt, ist mir natürlich klar. Ebenso, dass es dafür Beratungsunternehmen gibt. Von solchen New-Work-Beratern möchte ich aber besser gar nicht anfangen. Die, die ich kennengelernt habe, waren doch sehr in ihrem Wolkenschloss unterwegs. Demnach kann jeder die Priorisierung mit seinen Stakeholdern selbst klären - und sei es die Geschäftsführung des Unternehmens. In einem kleinen Start-Up mag das funktionieren. Das das in einem größeren Unternehmen völlig weltfremd ist, brauche ich glaube ich nicht zu erwähnen ;-).

Mir ging es eher um Tipps und Möglichkeiten, wie ich direkt bei den Führungskräften ansetzen kann. Vielleicht hat ja jemand den Kampf schon erfolgreich ausgefochten? Oder bleibt am Ende doch nur Aussitzen und hoffen, dass jemand in der höheren Hierarchie das Problem erkennt?

Bei uns gibt es nicht die Methode. Jeder Projektleiter kann das selbst entscheiden. Der eine nutzt Scrum, der nächste Kanban und manch einer auch (leider) noch die klassische Excelliste mit Arbeitspaketen. Und ganz besonders schlimm sind die Projektleiter mit irgendwelchen Hybrid-Ansätzen, die versuchen einen vorgegebenen Projektplan in Sprints zu packen ;-).

Bearbeitet 15. August 2022 von Pixelversteher

[allesweg]

Problem bei diesen Umstellungen ist oft, dass diese NewWork-Berater vom Management eingekauft werden und ihnen erzählen, dass sie Verantwortung nach unten abgeben können. Was dabei oft vergessen wird, ist dass diese Verantwortung auch angenommen werden muss. Und dass Mischformen aus klassischem und agilem Management an den Schnittstellen EXTREME Reibungsverluste verursachen.

Leider nehmen sich viel zu wenige Unternehmen die Zeit, diese tiefgreifende Veränderung mit dem nötigen Vorlauf, Tools, Infrastruktur und Vorgaben zu starten sondern sagen "Ihr seit jetzt das Team, macht was draus!"

Wenn dann noch ein Unternehmen die Rolle des Projektleiters vergibt und dieser dann Scrum machen soll (oder darf), wird mir übel!

[skylake]

@allesweg genau das ist das Problem. Nur weil Scrum irgendwo draufsteht, muss es nicht drin sein. Es gibt viele Studien die das bereits eindrucksvoll belegt haben, wie durch eine ungünstige Implementierung von Scrum viel Chaos und Unzufriedenheit verursacht worden ist.

Aussitzen wird leider nicht funktionieren, meiner Erfahrung nach. Die 'neuen' Konzepte haben für gewisse Typen von Führungskräften nämlich den Vorteil, dass sie sehr viel Arbeit an die Basis abwälzen können, die vorher in ihrer Zuständigkeit lagen. Dann heißt es plump "ihr müsst euch selbst organisieren und das unter euch ausmachen, ich bin nur der Coach, der alle zwei Wochen Freitags beim Review dabei sitzt und nickt". 

Wenn du eine Änderung erreichen möchtest, müsstest du dich tiefgehend mit entspr. agilen Konzepten bzw. Frameworks beschäftigen, dir das rauspicken was bei euch am besten passt und es der Führung irgendwie schmackhaft machen. Alternativ (erfordert aber viel (agile) Projekterfahrung) könntest du dir Teile aus anderen Konzepten holen und es entsprechend mixen. Davor warnen aber Jeff Sutherland  und Ken Schwaber.

Ich sitzt z. B. im anderen Boot. Agiles Framework einer überalterten Basis näherbringen, die keine Lust/Interesse/Willen mehr dazu hat. Die lieben die gute alte Diktatur, bei denen wir entscheiden, was, wann und wo zu tun ist.

[allesweg]

vor 1 Stunde schrieb Pixelversteher:

So bin ich, neben dem Tagesgeschäft, parallel in 4 größeren Projekten.

in welcher Rolle in welchem Prozessmodell mit welcher Zeitaufteilung?

Scrum kann es schon mal nicht sein, weil mindestens 14 Tage Vorausplanung und Tagesgeschäft sich widersprechen.

[Rabber]

Dass Führungskräfte, allen voran die eher niedrigen, Heute gerne ganz agil zu Coach degradiert werden sollen ist nun einmal Hipp und Trendy. Gerne von ganz oben vorgegeben, sodass die betroffenen Führungskräfte gar nicht anders können als gute Miene zum bösen Spiel zu machen.

meine Erfahrung hierzu ist ebenfalls, dass die Ideen dahinter in der Theorie sehr gut klingen. In der Praxis hingegen fährt die große Masse mit alten, traditionellen Rollenbildern deutlich besser.

Ist im privaten ja ähnlich, dass außergewöhnliche Biografien und Modelle zum Ideal verklärt werden, aber 90% der Leute eigentlich nur so leben wollen, wie ihre Eltern und Großeltern auch schon. Ganz klassisch eben.

Oder in der Politik, wo laute Randgruppen (von allen Seiten) den Großteil der Themen diktieren, während die große Masse kopfschüttelnd daneben steht, was nun wieder für eine Sau durchs Dorf getrieben wird.

Aber ich schweife ab… eine wirkliche Hilfe kann ich dir hier nicht anbieten. Zum einen ist das der Zeitgeist, gegen den du nur bedingt ankommen wirst. Zum anderen kenne ich dein Unternehmen nicht und hier sind konkrete Hilfen gefragt.

[eneR]

vor 6 Stunden schrieb Rabber:

90% der Leute eigentlich nur so leben wollen, wie ihre Eltern und Großeltern auch schon. Ganz klassisch eben.

Die Daten wurden wo und wie erhoben?

vor 6 Stunden schrieb Rabber:

Oder in der Politik, wo laute Randgruppen (von allen Seiten) den Großteil der Themen diktieren, während die große Masse kopfschüttelnd daneben steht, was nun wieder für eine Sau durchs Dorf getrieben wird.

Bei einer durchschnittlichen Wahlbeteiligung von nur +-70% bei egal welchen Wahlen kann das Problem doch gar nicht so groß sein. 

[Gast Pixelversteher]

vor 9 Stunden schrieb skylake:

Wenn du eine Änderung erreichen möchtest, müsstest du dich tiefgehend mit entspr. agilen Konzepten bzw. Frameworks beschäftigen, dir das rauspicken was bei euch am besten passt und es der Führung irgendwie schmackhaft machen. Alternativ (erfordert aber viel (agile) Projekterfahrung) könntest du dir Teile aus anderen Konzepten holen und es entsprechend mixen. Davor warnen aber Jeff Sutherland  und Ken Schwaber.

Danke für diesen Impuls. Dazu mache ich mir mal Gedanken, ob ich den Weg gehen möchte. Hättest du dazu konkrete Literaturempfehlungen? Gerne auch Literatur, die neben den Chancen und Vorteilen auch die Risiken und Nachteile beschreibt, um einen realistischen Blick zu bekommen. Insbesondere würden mich Themen zum agilen Projektportfoliomangement (gibt es sowas?) oder Scrum of Scrums interessieren. Ich glaube daran mangelt es.

vor 9 Stunden schrieb allesweg:

in welcher Rolle in welchem Prozessmodell mit welcher Zeitaufteilung?

Scrum kann es schon mal nicht sein, weil mindestens 14 Tage Vorausplanung und Tagesgeschäft sich widersprechen.

Dazu möchte ich nicht zu sehr ins Detail gehen, um die Anonymität zu wahren. Grundsätzlich geht es um die Implementierung und/oder das Customizing von Unternehmenssoftware über den gesamten Softwarelebenszyklus. Das Tagesgeschäft schwankt ein wenig, liegt im Schnitt aber bei 2PT pro Woche. Eine feste Aufteilung für die Projekte gibt es leider nicht. Seit der New-Work-Einführung gibt es keine Ressourcenplanung mehr. Das ist daher leider im wieder ein permanentes Aushandeln der (geringen) Ressourcen in den Projekten. Von den 3PT "Projektzeit" verbringe ich geschätzt 1,5-2PT in irgendwelchen Meetings, Dailys, Plannings, Retros, Reviews und Eskalationsgesprächen. Meine Rolle ist je nach Projekt und dessen Bedarf ein wenig Unterschiedlich und liegt zwischen Umsetzer, Lösungsarchitekt und Teilprojektleiter.

Grundsätzlich nehme ich aus der Diskussion mit, dass es keine (einfache) Lösung gibt, ich mit dem Problem aber aktuell nicht alleine bin.

[Whiz-zarD]

vor 9 Stunden schrieb skylake:

@allesweg genau das ist das Problem. Nur weil Scrum irgendwo draufsteht, muss es nicht drin sein. Es gibt viele Studien die das bereits eindrucksvoll belegt haben, wie durch eine ungünstige Implementierung von Scrum viel Chaos und Unzufriedenheit verursacht worden ist.

In diesem Zusammenhang kann ich nur den Youtuber Jayme Edwards aka Healthy Software Developer empfehlen, der genau über diese Themen spricht.

Die meisten haben agile Softwareentwicklung nämlich nicht verstanden und das ist ein sehr großes Problem. Bei uns versucht man auch diese New Work bzw. die agile Softwareentwicklung einzuführen aber es ist im Grunde krachend gescheitert aber es will keiner so richtig wahr haben. Man dachte, man könnte schneller releasen, wenn die Entwickler nach Scrum arbeiten aber das zyklische Releasen ist ja kein Mittel, um den Kunden zu beweisen, dass man schnell releasen kann, sondern dient dazu, um schnell Feedback zu sammeln. Gibt es kein Feedback und plant Änderungen (auf Basis des Feedbacks und der Retro) auch nicht in sein Regelprozess ein, ist es einfach Wasserfall. Wer agile Softwareentwicklung einführen möchte aber beim Wasserfall bleibt, der verursacht Chaos. Ich denke, die meisten Firmen können überhaupt keine agile Softwareentwicklung einführen und sollten dies auch so anerkennen. Dave Thomas, einer der das Agile Manifesto mitgeschrieben hat, berichtete auf einer Konferenz, dass z.B. das Beschätzen von Zeiten bei der agilen Softwareentwicklung nicht vorgesehen ist. Was soll man denn auch beschätzen, wenn die Software im nächsten Zyklus evtl. ganz anders aussehen muss? Wenn der Kunde oder das Management weiterhin darauf pocht, ist es Wasserfall, weil dann eine Deadline bestimmt wird.

Es bedarf ein komplett anderes Mindset, wenn man sowas einführen möchte. Nicht nur bei den Entwicklern, sondern in der gesamten Firma und auch bei den Kunden. Es müssen Mittel und Wege gefunden werden, wie man Kunden aktiv in den Entwicklungsprozess einbindet. Sei es durch Umfragen, Betatester, direkter Ansprechpartner bei fachlichen Fragen oder weiß der Geier noch was. Außerdem müssen ggf. sogar die Kundenverträge umgeschrieben werden. Diese Mühen machen aber gefühlt nur sehr wenige bis gar keiner. Gefühlt versucht man, wie hier schon angedeutet, die Entscheidungen nach unten zu drücken und daher kommen auch die ganzen Meetings, weil man als Entwickler plötzlich zusätzlich das Projekt managen muss.

Das Daily Meeting ist auch nicht dafür gedacht, dem Product Owner oder anderen Managern einen Bericht zu erstatten, wie weit man gerade ist, sondern dient einzig für das Team, um sich zu koordinieren und Probleme anzusprechen und sowas wie Burn-Down-Charts halte ich auch für kontraproduktiv, weil es ein Druck auf die Entwickler ausübt und Druck ist für die Softwarequalität immer schlecht.

Ich bin mir sicher, dass man in vielen Firmen den Scrum-Kram in die Tonne treten könnte und es würde niemanden auffallen.

[skylake]

@Whiz-zarD Das ist der Punkt, den ich an dem ganzen agilen Kram so kritisch sehe. Die gesamte Kette muss mitziehen und wenn nur ein Teil dieses neue Mindset nicht akzeptiert und lebt, bricht totales Chaos aus. In meinen alten Scrumprojekten ist mir auch schmerzlichst aufgefallen, dass ein PO oder SM wesentlich mehr Chaos stiften kann als im klassischen Wasserfallmodell der PL. Vor allem wenn der PO/SM sich nicht gewusst sind, was ihre Aufgaben sind und dann im jeweils anderen Territorium fischen ODER einer der Beteiligten keinen Plan hat wie es richtig funktioniert ODER sich die Position so umbaut, dass sie den Spirit davon zerstören ODER meinen sie 'tweaken' ein paar Events und co. und verringern damit ordentlich die Effizienz oder oder oder.

Mein Lieblingsbeispiel aus eigener Erfahrung: PO-Noob gibt das Backlog komplett frei, da Developer rummaulen. 2 Wochen später ist es derart zugemüllt das keiner mehr wirklich arbeiten kann. SM (Geschäftsführung nebenbei) ist derart genervt, dass er bei dem Daily auftaucht und den Developer vorgibt was sie wann zu tun haben ...

der TE spricht ja nicht nur Scrum an, allerdings ist Scrum so ein Garant dafür, so richtig was an die Wand zu fahren, wenn nicht alle Rädchen wirklich ineinandergreifen. Deswegen bin ich mittlerweile eher negativ eingestellt, wenn es darum geht.
Bevor ich so etwas ernsthaft in einem kleinen Team einführen wollen würde, würde ich jeden einzelnen Teilnehmer zumindest dazu verdonnern die jeweilige Einstiegszertifizierung der Scrum Alliance oder Konkurrenz zu belegen, damit der jeweiligen Gruppe zumindest klar ist, wo ihr Gebiet anfängt und wo es aufhört.

[mlwhoami]

vor einer Stunde schrieb Whiz-zarD:

Wer agile Softwareentwicklung einführen möchte aber beim Wasserfall bleibt, der verursacht Chaos.

 

vor einer Stunde schrieb Whiz-zarD:

Dave Thomas, einer der das Agile Manifesto mitgeschrieben hat, berichtete auf einer Konferenz, dass z.B. das Beschätzen von Zeiten bei der agilen Softwareentwicklung nicht vorgesehen ist.

 

vor einer Stunde schrieb Whiz-zarD:

Wenn der Kunde oder das Management weiterhin darauf pocht, ist es Wasserfall, weil dann eine Deadline bestimmt wird.

 

vor einer Stunde schrieb Whiz-zarD:

Gefühlt versucht man, wie hier schon angedeutet, die Entscheidungen nach unten zu drücken und daher kommen auch die ganzen Meetings, weil man als Entwickler plötzlich zusätzlich das Projekt managen muss.

 

vor einer Stunde schrieb Whiz-zarD:

Das Daily Meeting ist auch nicht dafür gedacht, dem Product Owner oder anderen Managern einen Bericht zu erstatten, wie weit man gerade ist,

 

 

--> All diese Punkte fühle ich sehr  Danke für diesen Beitrag!

 

Zum Kontext unserer Situation:

 

- International tätiger Mittelstand

- langjährige Projektdurchführung nach Wasserfall

- Irgendwann neue Arbeitsmethodik nach Scrum

- Top-Down Skalierung des Unternehmens nach SAFe

- Methodenänderung von Scrum auf Kanban

- Absägen des PMO aus dem sonst auch Projektmanager abgestellt wurden

- Überall den Stempel "agil" aufdrücken und dabei weiter nach Wasserfall handeln

 

Spätestens zu dem Zeitpunkt, als bei uns die "Meetings zu Meetings" begonnen haben, bin ich gedanklich ausgestiegen 😄

Wir arbeiten augenscheinlich agil, bekommen harte Deadlines vorgegeben und können keine zeitlichen Vorhersagen treffen weil die Aufwandsschätzung der Arbeitspakete bei Kanban erst im Rahmen der Analyse und Umsetzung erfolgt und nicht im Backlog.

 

👍