Ich geb es ja zu, das ist kein Wald und die Sträucher sind auch keine Bäume. Aber ki-frei und unkompliziert ist das als Symbolbild gut zu gebrauchen, weil man sieht wenigstens den Parkplatz und die Bundesstraße vor lauter Bäumen nicht.
So ging es mir letzte Woche mit dem Team, das ich gerade unterstützen darf. Vor lauter Backlog Items war nicht mehr klar, was eigentlich geschafft werden solle. Aber langsam und der Reihe nach…
Heute habe ich ein eher politisches Thema, das aber dennoch Parallelen zur Arbeit an der Produktarchitektur aufweist. Auf dem Agile Castle Camp letztes Wochenende habe ich eine Session zum Thema “Digitale Souveränität” initiiert. Das Thema fand regen Anklang und ich habe mich sehr über die spannende Diskussion gefreut.
Oli und ich arbeiten jetzt seit seit einger ganzen Weile daran, unser Wert durch Fluss Modell zu entwickeln und es auch in Worte zu fassen. Wie wir Entwickler zu scherzen belieben: the three most difficult problems in software development?
Deshalb möchte ich heute mal versuchen, ein Glossar unseres Modells anzufertigen. Das wird vermutlich eine Weile lang feingeschliffen werden, deshalb schau gerne mal wieder rein.
Wir sind komplett ausgelastet.
Ein Satz, der in vielen Organisationen fast schon als Erfolgsindikator gilt. Volle Kalender, lange Backlogs, viele Initiativen parallel - es passiert ja offensichtlich viel.
Und trotzdem bleibt am Ende oft das Gefühl: Warum kommt so wenig beim Kunden an?
In vielen Teams wird Arbeit mit Fortschritt verwechselt. Solange Menschen beschäftigt sind, fühlt es sich produktiv an. Doch Beschäftigung allein sagt nichts darüber aus, ob Wert entsteht.
Letzte Woche bin ich in einer Pause meines APS-SD mit dem technischen Leiter des Kunden ins Gespräch gekommen. KI in der Softwareentwicklung ist dort kein Thema - die Ergebnisse sind einfach nicht gut genug. Wir haben dann sehr schnell Parallelen zwischen KI-Code und Technical Debt entdeckt - in beiden Fällen erreiche ich sehr kurzfristig höheren Wert, allerdings auf Kosten der Fähigkeit, zukünftig weiter Wert liefern zu können.
In meinen Trainings verwende ich oft nebenstehendes Diagramm, um die Idee zu verdeutlichen:
Die Motivation im Team ist gerade schwierig.
Das ist ein Satz, den ich in den letzten Jahren immer häufiger höre, zuletzt heute morgen im Gespräch mit Kunden. Und dabei versuchen die meisten Organisationen, ihre Situation zu verbessern: mehr Kommunikation, mehr Transparenz, neue Rituale, ein neues Tool, ein Workshop zur Motivation.
Das Problem dabei: Motivation ist selten das eigentliche Problem.
Wir kommen nicht, um Scrum, Kanban oder DevOps „besser“ zu machen. Unsere Arbeit besteht darin, Organisationen zu helfen, Produktentwicklung insgesamt wirksamer zu gestalten – und zwar so, dass Veränderungen langfristig greifen.
“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
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.