NBA76: Nachhaltiges Tempo: Agil und gesund ohne Burnout

00:00:00: Hallo und herzlich willkommen bei No Bullshit Agile. Mein Name ist Thomas. Jede Woche spreche

00:00:07: ich hier kurz und knapp über Themen rund um agiles Arbeiten. In der letzten Folge habe

00:00:11: ich mich mal gefragt, verändert Vibecoding agiles Arbeiten? Und ich kann sagen, dass ich glaube,

00:00:18: ein Teil davon kann sicherlich helfen, aber ein ganz großer Teil, wenn man ihn durchzieht,

00:00:24: sage ich mal, führt eher zu einem Wasserfallmodell. Wenn dich das interessiert und wenn dich meine

00:00:29: Meinung dazu interessiert, den Link zu der Folge und alle weiteren Links, die ich erwähne,

00:00:33: findest du wie immer in den Shownotes. Heute in Folge 76 geht es mir darum,

00:00:38: dass agiles Arbeiten eigentlich nachhaltiges Arbeitstempo fördern sollte. Und ja,

00:00:44: immer wieder auch darüber diskutiert wird, dass es zum Burnout führt. Und ich würde ganz gerne

00:00:49: mal so eine Antiposition einnehmen, ein bisschen erzählen, was ihr vielleicht tun könnt,

00:00:54: damit ihr nicht in so eine Situation kommt. Gut, steigen wir mal ein. Das erste, wo ich

00:01:00: hingucke, ist natürlich das Agile Manifest und davor vor allem die zwölf agilen Prinzipien.

00:01:04: Denn wir finden tatsächlich im Prinzip 8 genau einen Satz dazu. Der Satz lautet,

00:01:10: agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten

00:01:16: ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können. Sprich, selbst an dieser Stelle

00:01:23: war allen Beteiligten eigentlich schon klar, dass das ein Thema sein kann. Und sie haben da schon

00:01:30: formuliert, es kann nur funktionieren, wenn man ein Tempo auf unbegrenzte Zeit halten kann. Und

00:01:38: das bedeutet automatisch, das Tempo darf nicht zu hoch sein. Wir wollen eben sinnvoll arbeiten

00:01:45: und wir wollen ein gewisses Tempo halten können. Wir suchen also nach einem konstanten Arbeitstempo,

00:01:51: damit weder Qualität leidet, noch wir unter Überarbeitung leiden. Wir wollen eben kontinuierlich

00:02:01: liefern können und wir wollen dazu nicht irgendwie extreme Überstunden aufbauen. Es zeigt sich,

00:02:08: komme ich gleich auch noch drauf, wenn man das zu lange macht, wird man einfach nur noch schlechter.

00:02:13: Die Fehlerquote steigt, die Leute sind nicht mehr konzentriert. Sprich, das ist eben komplett

00:02:19: kontraproduktiv zu nachhaltig und unbegrenzte Zeit ein gewisses Tempo halten können. Trotzdem ist es

00:02:27: so, dass viele Teams eben ja genau unter so einer Situation leiden. Oft ist es so, man kann ja mal

00:02:34: so eine Crunchphase haben, dass man mal sagt, wir müssen eine Woche durchziehen. Das Management

00:02:39: entdeckt dann im Zweifelsfall, oh, die können ja auch einen höheren Durchsatz und versuchen dann

00:02:44: eben diesen höheren Durchsatz durchzusetzen. Was nicht gesehen wird, ist das Problem, dass man so

00:02:50: einen höheren Durchsatz eben nicht lange halten kann, ohne nicht später andere Probleme zu bekommen.

00:02:55: Wichtig ist tatsächlich immer wieder auch in eine Verschnaufpause zu kommen. Also, dass man eben

00:03:03: vielleicht eine Phase mal hat, wie gesagt, vielleicht eine Woche, wo es einfach nicht

00:03:06: anders geht, aber dann eben auch dagegen gearbeitet wird, wieder in einen normalen Modus zu kommen,

00:03:12: um eben den Gesamtdurchsatz hochzuhalten. Im State of Agile Report 2024 ist es auch ein Thema. Da

00:03:20: wird klar hervorgehoben, dass eben Entwicklerburnout ein großes Thema ist. Dazu kommen sicherlich KI

00:03:26: und ja, hybride Arbeitsformen, die jetzt nicht besonders förderlich an der Stelle sind, aber es

00:03:34: taucht immer wieder explizit eben auf. Burnout ist ein großes Thema. In der Studie geben tatsächlich

00:03:41: über Hälfte der Entwickler Burnout als einen Hauptgrund an, warum Kolleginnen und Kollegen

00:03:48: kündigen. Das ist natürlich auch eine dramatische Zahl und natürlich will man das auch nicht. Und

00:03:53: das wäre so ein zweiter Grund zu sagen, ein erhöhter Durchsatz ist eine schöne Sache,

00:03:59: aber zu welchen Kosten? Wie ich am Anfang schon gesagt habe, das widerspricht jeglicher Idee

00:04:04: hinter agilen Arbeiten und wenn man agiles Arbeiten ernst nimmt und daran glaubt,

00:04:10: dass einem das hilft im Unternehmen und ich spreche jetzt mal so eine reine wirtschaftliche

00:04:15: Sicht an, dann steht das im starken Widerspruch, wenn man gleichzeitig Druck ausübt und auf

00:04:22: Überstunden besteht. Das passt dann einfach nicht zusammen. Da ist dann kulturell einfach

00:04:27: was kaputt. Das hat nichts mit agilen Arbeiten zu tun, mit der Methodik dahinter oder den Methodiken,

00:04:33: sondern das ist eine Fehlinterpretation von agilen Arbeiten. Und wenn ihr so eine Situation habt,

00:04:40: würde ich auch empfehlen, das einfach ganz klar so anzusprechen und vielleicht noch mal mit diesem

00:04:45: Mythos aufzuräumen. Wer schafft mehr? Wie gesagt, es mag Situationen geben, wo man mal Gas geben muss,

00:04:51: das sehe ich, aber das darf halt eben nicht andauernd passieren und es darf auch eben nicht

00:04:56: passieren, dass andere, das Management oder irgendwelche weiteren Stellen, Stakeholder

00:05:02: darauf drängen, dass dieser erhöhte Durchsatz durchgehalten wird. Es hat sich tatsächlich

00:05:08: erwiesen bei einer Untersuchung, dass ein Team Überstunden gemacht hat in einer Woche,

00:05:14: 22 Prozent mehr gearbeitet hat und das versucht hat zu halten und bereits in drei Wochen sank

00:05:22: die Velocity dann auf 16 Prozent unter Nimal Niveau. In vier Wochen waren sie sogar 20 Prozent

00:05:27: darunter. Sprich über vier Wochen gesehen ist das Team einfach insgesamt langsamer geworden.

00:05:32: Das klingt, wenn man sich das so anguckt, natürlich auch komplett logisch. Trotzdem,

00:05:37: glaube ich, ist es in vielen Köpfen nicht drin. Bin ich anders zu erwarten. Bereits wenige

00:05:42: Überstunden in der Woche können eben dazu führen, dass die Fehlerquote steigt und das ist natürlich

00:05:49: was, was wir überhaupt nicht haben wollen. Wir wollen ja nicht einen hohen Output, sondern wir

00:05:54: wollen einen hohen Outcome und zum Outcome gehört dazu, dass das, was ich liefere, fehlerfrei ist.

00:05:58: Sprich, wenn ich liefere und mein Lieferdurchsatz jetzt erhöht ist, ich aber auf der anderen Seite

00:06:03: sofort deutlich höhere Fehlerquote habe, geht meine Gesamtrechnung da an der Stelle natürlich

00:06:08: überhaupt nicht auf und deswegen ist es so wichtig, so eine Sustainable Pace zu halten.

00:06:13: Der nächste Punkt, den man hier übersieht, ist für Innovation, also für Verbesserung der Prozesse

00:06:20: zum Beispiel, brauche ich die Luft. Ich brauche auch mal eine Ruhepause, damit ich überhaupt in

00:06:25: diesen Denkmodus komme und das nächste ist dann ganz klar, ich brauche ja auch entsprechende

00:06:30: Actionable Items auf dem Board für diese Verbesserung der Prozesse. Das vermindert im

00:06:37: Zweifel eben ja den Durchsatz dessen, was ich, ich sag mal, in Produktion bringen kann, aber solche

00:06:44: Actionable Items werden ja eigentlich nur gesetzt, um in Zukunft insgesamt den Durchsatz zu erhöhen

00:06:50: und insofern sollte die Zeit für diese Innovation, für Forschung und Entwicklung, für eine kontinuierliche

00:06:55: Verbesserung systemisch mit in meinem System mit drin sein, sei es nur Scrum kann man oder was auch

00:07:02: immer er tut. Speaking of, was heißt das denn ganz konkret und ich fange mal an für Scrum. Ihr braucht

00:07:09: eine realistische Sprintplanung. Ich weiß, dass Sprintplanung für viele super schwer ist. Ich weiß,

00:07:14: hatte ich letzte Woche erst wieder das Thema, ich glaube auf Mastodon, wenn ich mich richtig

00:07:18: erinnere, dass Velocity für viele von euch ein Grundgerüst ist, um einen Sprint zu planen. Ich

00:07:26: kann nur dazu raten, lieber vorsichtig an den Sprint ranzugehen, kein Übercommitment zu machen

00:07:33: und meiner Meinung nach kann man während des Sprints ohne Probleme nachziehen. Wir sind immer

00:07:38: gut damit gefahren, das genauso zur Hand haben. Lieber ein bisschen unterhalb einer Grenze bleiben,

00:07:44: wo auch immer ihr eure Grenze findet. Ich finde das problematisch, in Scrum eine gute Grenze zu

00:07:48: finden, aber lieber ein bisschen drunter zu bleiben und dann kann man, wie gesagt, jederzeit nachziehen.

00:07:54: Es nützt überhaupt nichts zu sagen, das muss auch noch in den Sprint, weil das wichtig ist. Ja, da

00:08:00: muss was anderes raus. So einfach ist das Spiel. Das heißt, bei Scrum seid ihr natürlich jetzt in

00:08:06: dieser blöden in meinen Augen Situation, dass ihr euch da committen müsst auf euren Zeitraum, was auch

00:08:14: immer. Euer Sprint ist zwei Wochen, vier Wochen und ihr aber deswegen zumindest auf der anderen

00:08:19: Seite die Chance habt, ein bisschen planvoller vorzugehen und zu sagen, schaffen wir das wirklich?

00:08:24: Sollten wir nicht lieber eine Story weniger nehmen, auch wenn wir denken, wir würden sie schaffen,

00:08:28: die könnten wir im Zweifelsfall noch nachziehen. Wenn es gut läuft und euer PO einen guten Job

00:08:34: macht, dann habt ihr eben auch gerne eine gute Reihenfolge der möglichen Storys für einen Sprint.

00:08:39: Sprich, wenn ihr etwas weglasst, kann es in der Priorität ja auch eigentlich gar nicht so hoch

00:08:43: sein. Und insofern müsste es eigentlich auch passend zu sagen, pass auf, das nehmen wir mit

00:08:48: dem nächsten Sprint, diesen lieber nicht. Und dann freuen sich alle, wenn es vielleicht doch

00:08:51: noch in den Sprint reinpasst, während des Sprints. Also achtet da ein bisschen auf euer Commitment.

00:08:57: Bei Kanban ist es ein bisschen anders. Ja, ich bin halt eher Fan von Kanban, zumindest für unsere

00:09:03: Situation, sage ich mal. Denn wir haben ja keinen Sprint in Kanban. Im Gegenteil, wir haben ja einen

00:09:08: kontinuierlichen Flow und den managen wir unter anderem mit VIP-Limits. Und die VIP-Limits helfen

00:09:14: uns natürlich ganz direkt daran, dass wir nicht überreißen. Denn die VIP-Limits dienen genau dazu.

00:09:20: Wir wissen aus der Flow-Theorie, dass wir Systeme beschränken müssen, sonst verstopfen sie. Und das

00:09:26: VIP-Limit hilft uns dabei. Insofern kann uns, wenn wirklich alle unsere Arbeit auch wirklich

00:09:30: auf dem Board stattfindet, eine Überspitze in diesem Sinne zum Commitment nicht passieren,

00:09:38: so wie es in Scrum passieren kann. Zu sagen, wir müssen Gas geben, kann natürlich immer noch

00:09:43: passieren. Und trotzdem gilt dann das, was ich vorhin gesagt habe. Ihr müsst ein bisschen auf

00:09:46: euch aufpassen. Es mag mal sein, dass so eine Phase da ist, aber ihr müsst auch aus dieser Phase

00:09:51: wieder rauskommen. Insofern meine Bewertung. Scrum im Sprint Planning vielleicht ein bisschen

00:09:57: schwieriger. Kanban sollte durch Flow-Management und VIP-Limits eigentlich helfen, solche Überspitzen

00:10:05: und damit den Burnout, den ich hier gerade beschreibe, zumindest einzudämpfen. Oder es

00:10:10: sollte euch leichter fallen, festzustellen, Moment mal, wo stehen wir hier gerade? Sind wir noch bei

00:10:16: einem kontinuierlichen Arbeiten in einer Geschwindigkeit, die wir halten können? Oder

00:10:20: sind wir gerade darüber? Konkret kann ich euch nur sagen, ihr müsst es ansprechen. Ihr müsst in

00:10:25: allen Runden, die ihr habt, Daily, Stakeholder-Management, mit eurem Scrum-Master, wenn ihr Scrum macht,

00:10:30: über solche Dinge sprechen, wenn ihr feststellt, ich glaube, wir überreißen gerade. Das können wir

00:10:35: eine Woche machen, aber länger können wir das nicht machen. Lasst uns jetzt schon mal planen,

00:10:39: wie wir da wieder rauskommen. Ich will hier auch gerne noch mal auf die Folge 68 zu LSD-Gleadership

00:10:44: verweisen, denn da ist noch mal ganz klar erwähnt, wie sich auch Führungsstile in bestimmten

00:10:50: Situationen ändern müssen. Und das passt hier zu diesem nachhaltigen Arbeitstempo eigentlich ganz

00:10:55: gut beobachtet. In welcher Phase steckt ihr als Team gerade und sorgt dafür, dass der Führungsstil

00:11:03: auch entsprechend funktioniert? Vor allen Dingen wichtig, ihr müsst unter anderem rauskommen wegen

00:11:09: Burnout, aber auch, dass ihr zurück zu so einer Learning-Phase kommt. Das nächste, was vielleicht

00:11:14: wichtig wäre als Tool oder als Tipp ist, bloß nicht Überstunden glorifizieren. Auch das habe

00:11:20: ich immer mal gehört, dass Leute auch stolz darauf sind, dass sie lange eine hohe Geschwindigkeit

00:11:27: halten können. Das ist krass, sehe ich auch so, aber es ist nicht gesund und aus wirtschaftlicher

00:11:33: Sicht eben auch nicht nachhaltig. Und deswegen würde ich gar nicht erst anfangen, das zu

00:11:39: glorifizieren, sondern eher dahin arbeiten, zu sagen, wie schaffen wir es denn, einen guten

00:11:44: Durchsatz, einen hohen Durchsatz bei verringerter Arbeitsleistung zu schaffen, denn darum geht es

00:11:49: vor allen Dingen. Dann braucht ihr eine gute Fehlerkultur und ein gutes kulturelles Umfeld

00:11:53: im Allgemeinen. Zur Fehlerkultur hatte ich tatsächlich auch mal eine Folge gemacht, das ist

00:11:58: die Folge NBR 21 Fehlerkultur, damit ihr eine offene Umgebung habt, wo Leute auch wirklich

00:12:05: sagen können, das ist too much, wir übernehmen uns hier gerade. Ja, das wäre noch so ein zweiter

00:12:12: Tipp. Der dritte Tipp, wenn ihr in so einer Phase seid, plant innerhalb der Phase schon, wie ihr da

00:12:18: rauskommt und wo ihr, ja sag ich mal, so einen Cooldown einleiten könnt, dass ihr wieder in

00:12:23: das normale Arbeiten, in das Learning kommt, in eine Phase, die ihr lange halten könnt. Ja, und das

00:12:30: soll es dann für heute auch schon gewesen sein. Wie immer, das ist ja so mein Motto, geht es darum,

00:12:35: euch ein bisschen ins Denken zu bringen, euch zu inspirieren. Ich hoffe, das hat geklappt. Wenn

00:12:40: ihr Feedback habt, meldet euch gerne. Den Link zu den Social Media Kanälen findet ihr in den

00:12:45: Shownotes. Ansonsten habe ich noch eine ganz große Bitte, wenn dir die Folge gefallen hat,

00:12:49: wenn sie dir vielleicht sogar geholfen hat, vielleicht hast du sogar mehr vom Podcast

00:12:53: gehört und du findest den Podcast insgesamt toll, dann teile das gerne. Teile das mit deinen

00:12:57: Kolleginnen und Kollegen. Teile es auch gerne auf Social Media. Je mehr Leute hier von dem Podcast

00:13:02: erfahren, desto größer wird die Diskussion und desto mehr kann ich hier wieder neue Folgen aufnehmen

00:13:08: und wenn es gut läuft, kommt dir das ja auch zugute. Ansonsten sage ich wie immer, habt noch

00:13:12: eine ganz tolle Woche und bis zur nächsten Folge bei No Bullshit Agile.