Mein Scrum ist kaputt | Agilität, Scrum, Kanban und mehr

"Es gibt kein Recht auf Gehorsam." Als Hannah Arendt diesen Satz sagte, meinte sie damit nicht Anarchie, sie meinte Verantwortung. Wer gehorcht, gibt Verantwortung ab. Wer Verantwortung abgibt, hört auf zu denken. Und wer aufhört zu denken, schadet nicht nur sich selbst, sondern auch dem System, dem er dient.

Das, was so ein bisschen seltsam für die Beschreibung einer Podcast-Episode klingt, sind die ersten Sätze aus dem neuesten Buch von Boris Gloger, um das es in dieser Folge geht.

Wie viele Produktentscheidungen trefft ihr eigentlich auf Basis von Daten und wie viele nach dem Motto, das fühlt sich richtig an? Wir reden ständig über Kundennutzen, Produktziele und Wertschöpfung, aber wenn es konkret wird, verlassen wir uns oft auf Erfahrung, Meinung oder das lauteste Bauchgefühl im Raum. Genau darüber sprechen wir heute mit Simon Flossmann. Simon beschäftigt sich intensiv mit evidenzbasiertem Management und der Frage, wie Teams und Organisationen bessere Entscheidungen treffen können, weniger Annahmen und mehr Transparenz, weniger Diskussionen darüber, wer Recht hat und mehr Erkenntnisse darüber, was tatsächlich funktioniert. Wir sprechen darüber, wie man sinnvolle Ziele formuliert, Hypothesen aufstellt, die richtigen Metriken auswählt und wie man Produktentwicklung stärker auf Fakten statt auf Vermutungen stützt.

Systeme sind heute keine statischen Gebäude mehr, die man einmal entwirft und dann einfach bezieht. Sie ähneln eher lebendigen Organismen, die sich ständig anpassen müssen. Die Architektur bildet dabei das Fundament, dass diese Flexibilität entweder ermöglicht oder zu massiven Hindernis wird. Denn ohne eine tragfähige, mitwachsende Struktur wird jede Agilität früher oder später von technischen Schulden ausgebremst.

Continuous Architecture bricht mit dem Dogma des großen Entwurfs vorab. Sie ersetzt den Big Design upfront durch einen fließenden Übergang von Design und Implementierung.

Aber wie behält man dabei den Überblick und wie vermeidet man, dass am Ende bloße Zufallsarchitekturen entstehen?

In manchen Organisationen ist Scrum gar nicht so kaputt. Die Rollen sind klar, Events sind im Kalender, Artefakte werden gepflegt. Aber die Zusammenarbeit fühlt sich trotz agiler Methoden immer noch ziemlich zäh an. Verantwortung wird weitergereicht, Entscheidungen dauern und Teams warten. Irgendwas passt strukturell nicht.

In diesem Zusammenhang taucht seit einiger Zeit immer häufiger ein Begriff auf: unFIX. Was steckt eigentlich dahinter? Wofür ist unFIX gedacht? Und was könnte es für unsere Scrum-Teams bedeuten?

Jeder kennt es: Ihr bereitet eure nächste Retrospektive oder euren nächsten Workshop vor, und ihr sucht noch nach dem passenden Icebreaker.

Ihr stöbert durch irgendwelche Online-Archive, irgendwelche Online-Blogs und -Artikel, fragt vielleicht ChatGPT oder Gemini oder sonstwas nach tollen Ideen für Icebreaker, und die Hälfte davon legt ihr zur Seite, weil ihr euch denkt: "Dat kann ich mit dem Team nicht machen".

Diese Icebreaker, die probieren wir heute aus!