Blog

“Wann seid ihr fertig?” Eine einfache Frage. Und in vielen Organisationen der Beginn von Stress, Rechtfertigungen und ziemlich schlechten Prognosen.

Liefertermine werden gerissen, Zusagen immer vorsichtiger formuliert, das Vertrauen leidet. Und fast reflexartig folgt dann die naheliegende Maßnahme: “Dann müssen wir eben besser schätzen.” Mehr Refinement. Genauere Story Points. Längere Diskussionen im Planning.

Das Ergebnis? Viel Zeit investiert - und die Vorhersagbarkeit bleibt trotzdem schlecht.

Warum ist das so?

Im Refinement und im Sprint Planning war sich das Team noch einig, dass das Backlog Item klein genug und gut in einem Sprint machbar ist. Die Aufgabe wurde auch gleich am Sprintanfang angegangen und trotzdem kann das Team das Ergebnis im Sprint Review nicht präsentieren.

So oder so ähnlich haben wir es oft genug gesehen und vielleicht kennst Du die Situation auch: Irgendwie war die Entwicklung dann doch überraschend zäh und es hat am Ende nicht gereicht. Aber was ist der Grund dafür, dass eine eigentlich überschaubare Aufgabe sich so lange hinzieht?

Die drei schwersten Dinge im Leben eines Entwicklers sind ja bekanntermaßen

1. Naming Things und
2. Off-By-One Errors.

In unserer Arbeit als Trainer und Coaches ist Timeboxing ein wichtiger Bestandteil.

Falls ihr den Begriff Timebox noch nicht kennt: Damit bezeichnen wir eine feste Zeitspanne, die wir uns für eine Aufgabe reservieren. Wichtig ist,

Hier stellen wir lesenswerte Bücher zum Themenbereich DevOps vor

Schon die alten Römer wussten es: “errare humanum est” - “Irren ist menschlich”. Und spätestens in der Schule haben wir gelernt, dass diese Irrtümer und Fehler etwas Schlechtes sind, das es zu vermeiden gilt. Dazu wurden Belohnungen und Strafen verwendet. Jeder von uns hat sich dann auch gefreut, wenn der Lehrer einen Fehler nicht gefunden hat und es doch noch zur besseren Note gereicht hat.

Software developers are mostly guys, happy to work by themselves at night in dark rooms. And they turn coffee, cola and pizza into code. Right?

Manchmal verwenden wir Entwickler die Begriffe ‘Logging’ und ‘Monitoring’ synonym. Es lohnt sich, hier explizit zu unterscheiden.

Betrachtet Eure Aktionen als Experimente. Ihr könnt nicht vorher wissen, was funktioniert. Deshalb dürfen Fehler nicht bestraft werden. Wichtig ist der Erkenntnisgewinn. Um so arbeiten zu können, müsst Ihr ein Umfeld schaffen, in dem ein fehlgeschlagenes Experiment keine Katastrophe zur Folge hat.

Schaut, welche Feedbackzyklen Euch fehlen. Denkt dabei auch über Eure Team- und Abteilungsgrenzen hinweg. Baut diese Schleifen auf. Beschleunigt Eure Feedbackzyklen. Nutzt Information Radiators.

Schaut Euch Eure gesamte Wertschöpfungskette an und identifiziert das schwächste Glied. Dieses hat höchste Priorität. Entlastet und verbessert es. Messt, welche Effekte Eure Veränderungen haben. Fangt wieder von vorne an.