NBA59: Deadlines im agilen Arbeiten

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 ging es

00:00:12: um Meetings und deren Sinnhaftigkeit. Wenn dich das interessiert, hör da gerne rein. Den Link und

00:00:18: alle weiteren Links findest du wie immer in den Shownotes. Heute in der Folge 59 möchte ich über

00:00:23: Deadlines sprechen. Ja, ich glaube für uns alle ein ganz ganz tolles Thema. Das ist ein bisschen

00:00:29: ironisch und ein bisschen nicht ironisch. Ich vermute ihr kennt das auch bei ganz vielen

00:00:34: Unternehmen in Projekten. Ich vermute auch in internen Projekten wird immer und immer wieder

00:00:41: über Deadlines gesprochen und die sind zum Teil im agilen Kontext ja fast sogar toxisch. Und ich

00:00:50: würde ganz gerne mal durchgehen so gibt es vielleicht sinnvolle Arten von Deadlines? Wie

00:00:55: kann man mit Deadlines umgehen? Und ich will mal anfangen mit der Frage warum gibt es überhaupt

00:01:01: Deadlines? Was treibt uns und was treibt uns als Menschen eigentlich dazu gerade auch in Projekten,

00:01:07: auch vielleicht im privaten Umfeld, ja Deadlines haben zu wollen? Ich glaube das erste Fundament

00:01:14: ist und ich glaube es ist wichtig das zu verstehen. Menschen müssen planen. Also in meinem Fall,

00:01:21: wir machen ja Software für Kunden. Ist das so, dass auch mein Kunde natürlich planen muss. Die

00:01:26: müssen im Zweifelsfall andere informieren, wenn irgendwas live geht. Wenn sie Customer Feedback

00:01:33: geben sollen, geben sie es vielleicht nicht selber, sondern es sind auch wieder andere. Sprich

00:01:37: vollkommen natürlich geht diese Planung dann bei denen auch nicht einfach so von einem Tag auf

00:01:44: dem anderen. Das heißt sie brauchen einen gewissen Vorlauf. Und wie kann man das dann koordinieren?

00:01:50: Klar, man sagt ich brauche jetzt einen Plan, wann diese Funktionalität testbar ist oder live

00:01:56: geht oder was auch immer gerade der Fall ist. Ja, ganz natürliche Zukunft, Zukunft, Zukunft. Leute

00:02:04: müssen planen. Bisschen damit verknüpft ist, dass wir Menschen gerne Sicherheit haben wollen. Und

00:02:12: diese Planung, eine Deadline gibt Leuten eine Sicherheit. Wenn die Deadline nicht erfüllt wird,

00:02:19: ist es natürlich eine Unsicherheit. Kommen wir gleich auch nochmal drauf. Aber zuallererst mal

00:02:24: wollen Menschen gerne Sicherheit haben. Und Menschen wollen gerne Ziele haben. Woraufhin

00:02:31: arbeiten wir und bis wann soll was fertig sein? Auch das ist ganz natürlich. Und ein Teil von

00:02:39: Zielen ist nicht nur die Funktionalität, die da vielleicht geliefert wird. Ein Teil von diesen

00:02:44: Zielen ist auch, wann wird es geliefert? Und die dritte Komponente, viele Menschen, also vor

00:02:50: allen Dingen natürlich agile Teams, aber auch andere, wollen ganz gerne Fazit ziehen. Und

00:02:57: nichts ist besser als nach einer Deadline ein Fazit zu ziehen. Das sind immer so Stopp- und

00:03:06: Reflexionspunkte in einem Projekt. Das heißt, eigentlich ist es ziemlich natürlich, finde ich

00:03:15: zumindest, dass Leute sagen, da hätte ich gerne einen Termin für, eine Planung für, eine Deadline

00:03:22: für. Jetzt kommen wir zu einem Punkt. Warum macht man denn dann nicht überall Deadlines? Naja,

00:03:31: warum arbeiten wir denn agil? Warum machen wir keinen Wasserfall? Das Fundament dazu,

00:03:37: die offensichtliche Wahrheit ist ja eben, wir machen Dinge, die wir im Zweifelsfall das erste

00:03:45: Mal machen, weil wir so die Anforderungen noch nicht hatten, weil wir Teile der Technologie so

00:03:51: noch nicht benutzt haben, weil wir wissen, dass bestimmte Anforderungen noch gar nicht definiert

00:03:58: sind. Die können erst später definiert werden. Wir bewegen uns einfach auf einem unbekannten

00:04:04: Terrain. Und wenn man das weiß, ist ziemlich klar, dass man unter diesen Bedingungen zumindest

00:04:12: sehr schlecht planen kann, was jetzt Deadlines anbelangt. Wenn wir einfach mal so ein paar

00:04:19: Beispiele nehmen und wir sagen mal, wir stellen Hammer her. Dann ist es, glaube ich, ziemlich klar,

00:04:26: wie so ein Hammer hergestellt wird. Das muss ich einmal rausfinden und den Produktionsprozess

00:04:31: vielleicht auch ab und zu anpassen. Aber grundsätzlich, wenn ich mal ein paar Hammer

00:04:35: hergestellt habe, kann ich eine Stoppuhr stellen und weiß dann, ein Hammer dauert so und so lange.

00:04:42: Ein Hammer herzustellen dauert zehn Minuten oder so. Und dann kann ich halt einfach ganz

00:04:47: grundsätzlich fundamental sehr einfach planen und sagen, 100 Hammer dauern so lange. Wenn ein

00:04:54: Kunde sagt, ich bestelle jetzt 1000 Hammer. Wann können Sie die liefern? Muss ich ja nur

00:04:58: nachgucken, wie viele Lieferungen habe ich noch? Und kann dann ganz einfach ausrechnen,

00:05:02: Sie kriegen Ihre Hammer in drei Wochen. Und wenn jetzt nicht irgendwas Katastrophales passiert,

00:05:08: keine Ahnung Stromausfall oder so oder keine Ahnung Lieferengpässe bei Hammerstielen,

00:05:14: werde ich diese Deadline, diesen Termin auch einhalten. Wenn wir das nächste Beispiel mal

00:05:20: nehmen, wir wollen ein Schiff bauen, ein großes Schiff. Da wird es schon ein bisschen schwieriger.

00:05:25: Aber das ist so ja das Fundament damals ganz, ganz früher Schiffsbau, wo ja diese klassische

00:05:33: Planung von Projekten entstanden ist. Also die Berechnung zum Beispiel alles klassische Welt

00:05:38: jetzt von einem kritischen Pfad im PSP, im Projektstrukturplan. Das stammt eigentlich

00:05:44: alles aus dem Schiffsbau. Und damals passte das auch noch einigermaßen, weil die Leute sich gesagt

00:05:49: haben, okay, wenn wir eine Planung machen, wir wissen ja, keine Ahnung, so und so groß ist das

00:05:54: Schiff und das besteht dann aus so viel Stahlplatten. Das heißt, wir brauchen so viele Leute, die diese

00:05:59: Stahlplatten aneinanderschweißen. Und wenn wir dann feststellen, oh, wir hängen auf dem kritischen

00:06:04: Pfad, dann stellen wir noch mal zehn Leute ein, die diese Stahlplatten schweißen können und

00:06:09: gehen davon aus, dass die alle in gleicher Qualität und Geschwindigkeit schweißen. Und

00:06:13: deswegen kann ich eigentlich zum Start von dem Schiffsbau schon sagen, dieses Schiff ist in

00:06:18: zweieinhalb Jahren fertig. Es ist deswegen was anderes als der Hammer, weil es deutlich komplexer

00:06:23: ist. Aber trotzdem in der klassischen Projektwelt ist es so das typische Beispiel, wo man noch,

00:06:30: ja, ich sag mal, wasserfallmäßig planen kann und wo es Methodiken gibt zu berechnen. Kritischer

00:06:37: Pfad hatte ich jetzt schon das dritte Mal gesagt. Ja, was man denn jetzt tunen muss, um bestimmte

00:06:44: Termine halten zu können oder grundsätzlich überhaupt eine Fertigstellung zu berechnen.

00:06:48: Jetzt kommen wir aber zu dieser verdammten Softwareentwicklung. Zuallererst mal ist es so,

00:06:53: es ist eben nicht so. Alle Entwickler sind gleich. Jeder hat so seine Schwerpunkte,

00:06:58: seine Stärken und seine Schwächen. Das heißt, ich kann die auch nicht beliebig austauschen oder

00:07:01: ergänzen, so wie man das mit diesen Schweißern im Schiffsbau eventuell tun kann. Da bin ich auch

00:07:08: nicht ganz überzeugt von. Und unsere Anforderungen sind eben nicht klar. Es gibt keine Zeichnung über

00:07:14: das Schiff, sondern die Software entsteht. Jeder hat so ein Gefühl dafür, was wohl rauskommen soll.

00:07:19: Aber normalerweise verdichtet sich das. Und diese nicht repetitive Tätigkeit, die macht das halt so

00:07:28: unheimlich schwer, das zu planen. Jetzt bleibt nur die Frage offen, wie kann man trotzdem diese

00:07:34: Deadlines vorgeben? Wir haben ja gelernt, es ist für Menschen schon unheimlich wichtig, so ein

00:07:42: planerisches Vorgehen und auch solche Deadlines. Und die Antwort in meinen Augen ist, liegt in den

00:07:48: Inkrementen. Denn auf dieser Ebene kann man eigentlich schon planen. Also wir haben ein

00:07:55: Gesamtprojekt. Wir machen zum Beispiel mit Dimensional Planning uns einen Plan darüber,

00:08:00: was ist wohl das erste und das wichtigste Inkrement. Wir versuchen, das so gut es geht zu

00:08:07: spezifizieren und gehen jetzt erstmal davon aus, dass mit einer sehr geringen Wahrscheinlichkeit

00:08:13: diese Spezifizierung falsch sind. Also wir eine hohe Wahrscheinlichkeit haben, dass die

00:08:20: Spezifizierung dieses Inkrements richtig sind. Also eine hohe Wahrscheinlichkeit dafür haben,

00:08:25: dass das, was wir dann liefern, auch dem entspricht, was Stakeholder oder Kunden sich

00:08:31: vorgestellt haben. Und dann kann ich das noch mit einer gewissen Fertigstellungswahrscheinlichkeit

00:08:36: versehen. Kann dann sagen, okay, dieses Inkrement wird mit einer Wahrscheinlichkeit von 80 Prozent

00:08:44: in zwei Wochen fertig sein. Ich denke, das ist eine machbare Sache, wenn die Eingangsbedingungen

00:08:54: korrekt sind, dann sollte man sich in dieser Wahrscheinlichkeit von 80 Prozent auch kommitten

00:09:01: können zu der Lieferung. Und dann hätte man zumindest dieses, ein Kunde muss auf seiner

00:09:06: Seite auch planen oder Stakeholder müssen informiert werden mit einem Vorlauf von vielleicht

00:09:11: zwei Wochen oder vier Wochen, je nachdem wie groß das Inkrement ist, hätte man das realisieren

00:09:18: können oder man kann das so realisieren. Das bedeutet natürlich, dieses Inkrement muss gemeinsam

00:09:23: mit den Stakeholdern geplant werden, damit die Unsicherheit, ja so weit es irgendwie geht,

00:09:29: reduziert wird. Und das kann man für mehrere Inkremente machen. Wichtig dabei ist natürlich

00:09:35: zu verstehen, je weiter weg eine Story ist, also wir sind beim siebten, beim zehnten oder beim

00:09:42: zwanzigsten Inkrement, desto unpräziser sind die Spezifikationen und desto unwahrscheinlicher ist es,

00:09:51: dass die Anforderungen wirklich so sind, wie sie die Leute brauchen. Es kann ja super gut passieren

00:09:59: und das erleben wir ja auch andauernd, dass irgendwann entschieden wird, ja diese Story

00:10:03: brauchen wir gar nicht mehr. Sie entfällt einfach komplett. Aber ich glaube mit diesem Mechanismus

00:10:09: auf dieser Inkrementsebene und mit Wahrscheinlichkeiten zu planen, schafft auf der einen

00:10:14: Seite wieder die Sicherheit für die Menschen und ist auf der anderen Seite realistisch genug,

00:10:18: dass wir so etwas im agilen Umfeld auf jeden Fall tun können. Ich sage ja immer, agiles Arbeiten ist

00:10:25: ein extrem planvolles Arbeiten. Manchmal habe ich das Gefühl, das habe ich glaube ich auch schon mal

00:10:32: ein paar Folgen erwähnt, Leute denken agiles Arbeiten würde bedeuten, Ärmel hochkrempeln

00:10:37: und los geht's und mal gucken und man müsste gar nicht planen. In meiner Auffassung ist das genau

00:10:43: andersherum. Agiles Arbeiten muss man unheimlich viel planen. In diesem Schiffsbaubeispiel, was ich

00:10:49: da vorhin hatte, da ist die theoretische Idee zumindest, dass man nur einmal plant und dann

00:10:55: im Zweifelsfall vielleicht ein bisschen was anpasst, aber dass der Plan sich so realisiert.

00:10:59: Das ist in der Softwareentwicklung einfach nicht so und deswegen denke ich, auf Inkrementebene

00:11:05: geht das sehr gut und das wäre auch tatsächlich mein Fazit hier, wenn ihr plant und macht das

00:11:12: ruhig auch, dann plant auf Inkrementebene. Ja und das soll es eigentlich schon gewesen sein, wie

00:11:20: immer, kurz und knapp, das ist ja so mein Motto hier. Mich interessiert natürlich, ja wie haltet

00:11:25: ihr das? Also wie geht ihr denn mit Deadlines um? Habt ihr überhaupt welche? Seid ihr vielleicht in

00:11:30: einer Position oder in einem Modus, wo ihr über Deadlines gar nicht mehr sprecht? Fände ich auch

00:11:37: sehr interessant das mal zu erfahren. Teilt das gern mit mir. Ihr findet alle Wege, wie ihr mich

00:11:42: erreicht in den Shownotes. Ich habe noch eine ganz große Bitte zum Abschluss. Wenn dir das hier

00:11:48: gefällt, vielleicht hat es dir sogar was gebracht, dann teil bitte den Podcast mit deinen Kolleginnen

00:11:53: und Kollegen und natürlich gerne auch auf Social Media. Je mehr Leute davon erfahren, desto größer

00:11:58: wird die Diskussion und ja, desto mehr Themen, Sichtweisen und Inspirationen kann ich hier für

00:12:05: neue Folgen aufnehmen. Dafür sage ich ganz, ganz vielen Dank. Habt noch eine ganz tolle Woche und

00:12:10: bis zur nächsten Folge bei No Bullshit Agile.