Der Wecker klingelt. Alles ist dunkel. Ich schaue auf die Uhr und sehe eine unchristliche Zahl vorne stehen. Nun ist mir schlagartig klar: Ich muss aufstehen und in Bewegung kommen. Der Zug fährt bald. Heute gehts nämlich los. Wir von der agilen Gilde bei SPF Consulting sind den ganzen Tag unterwegs. Warum wir unterwegs sind und was wir erlebt haben, stelle ich dir in diesem Insight vor.

Begonnen hat alles vor ca. zwei Jahren. Wir in der agilen Gilde waren nicht zufrieden mit unserer Zielerreichung. Das bisherige System konnte nicht recht Wirkung entfalten. Was tut man also mit einem agilen Mindset im Kopf: Inspect & Adapt. Genau. In unseren regelmässigen Retrospektiven haben wir die Situation kritisch betrachtet und uns dann für ein neues System entschieden:

Objectives and Key Results (OKR)

Das Thema war uns bereits bekannt, doch selber hatten wir es noch nicht umgesetzt. Also haben wir uns vertieft mit dem Thema befasst und sogleich ein Experiment gestartet. Wir wollten uns nach OKR in den nächsten 3 Monaten ausrichten und die Wirkung prüfen. Mit jeder Retrospektive haben wir das OKR-System so adaptiert und angepasst, dass es für uns eine immer bessere Wirkung hatte.

Mittlerweile sind wir bei OKR-Zyklen von 4 Monaten und beschränken uns auf 2 Objectives. Wir haben festgestellt, dass mehr Objectives für uns zu einer Verzettelung führen. Haben wir ein Trimester erfolgreich auf unsere Ziele hin gearbeitet, dürfen wir uns mit einem “Chriesi-on-Top” belohnen 😀 .

Das “Chriesi-on-Top” ist etwas, wo wir als agile Gilde alle dahinter stehen können und für uns erstrebenswert ist. Am Ende eines Trimesters wird dann per Zufallsprinzip aus unserem “Chriesi-Topf” ein Element ausgewählt. Und hier kommt nun der Wecker ins Spiel…

Das “Chriesi-on-Top” vom letzten Trimester war ein Ausflug mit der Gilde. Aber kein gewöhnlicher Ausflug. Es sollte innerhalb eines Tages möglichst viele Fortbewegungsmittel benützt werden. So haben wir schon “frühmorgens” um 8:00 am Bahnhof Luzern mit dem Velo gestartet.

Das Wetter war noch hochneblig, zum Glück jedoch ohne Regen. Nach ca. 1 Stunde Fahrt sind wir in Hergiswil angekommen. Von dort gings dann zu Fuss hinauf zur Talstation “Alpschwänd”.

Die 300 Höhenmeter so früh am Morgen sind schon eine Herausforderung für uns “Büromuffel” . Doch nach der kurzen Gondelfahrt mit der Panoramabahn hinauf zur Bergwirtschaft Alpschwänd, wurden wir mit einem fantastischen Blick über die Bergwelt entlohnt.

Nach einer kleinen Stärkung gings schon wieder zu Fuss weiter zur nächsten Überraschung. Es wartet die Sommerrodelbahn Fräkigaudi. Das war in der Tat eine Gaudi. In vollem Karacho den Berg runter sausen liess in uns Kindheitserinnerungen erwachen. Wir waren alle happy.

Danach gings weiter mit der Panorama-Gondelbahn hinauf zum Pilatus. Der Blick vom Pilatus fasziniert jedes Mal erneut. Die Bergwelt rund um Luzern ist tatsächlich Postkarten-tauglich. Wer das noch nicht erlebt hat, dem empfehle ich dringend, dies nachzuholen. Mittagessen und obligates Selfie gehörte natürlich auch dazu.

Schon bald erklang der Ruf des “Reiseleiters”: “Witer gohts, am Halbi bim Gondeli.” Wie ein Kameltreiber wurden wir von einer Bahn zur nächsten “befördert”. Bei der Talfahrt wurde im Gondeli lautstark mitgesungen Tacchi – Gondeli . Dieser Ohrwurm kriegten wir danach nicht mehr aus dem Kopf 🤪.

In Kriens angekommen gings auch schon weiter mit der “Sonnenbergbahn” (eine Standseil-Pendelbahn) auf den Sonnenberg für einen kurzen Apéro. Bald schon erschallte wieder der Ruf des “Kameltreibers” und wir mussten wieder runter nach Kriens. Natürlich wieder mit der Sonnenbergbahn.

Nach einer kurzen Fahrt mit dem Bus zum Bahnhof Luzern bestiegen wir das Schiff nach Kehrsiten. Der April machte sich ein wenig bemerkbar. Ohne Sonne und mit Fahrtwind im Gesicht wurde es jedoch relativ kühl. Da hilft nur gute Kleidung.

Oder man sitzt in der Mitte wo es nicht windet 🤣.

In Kehrsiten angekommen, hiess es umsteigen zur Bürgenstock-Bahn. Dann hoch zum Bürgenstock und mit etwas Fussweg haben wir als Zieldestination das Gasthaus Trogen erreicht. Ein wunderbares Essen in heimeliger Atmosphäre entlohnte uns von den Strapazen des Tages.

Sogar Petrus meinte es nochmals gut und belohnte uns mit einem schönen Sonnenuntergang in idyllischer Umgebung. Das war ein gelungener Ausflug. Wir durften neue Transportmittel und Orte erleben. Zusammengezählt haben wir 17 unterschiedliche Transportmittel verwendet, inklusive An- und Abreise. Haben viel gelacht und über Gott und die Welt geplaudert. Dabei sind unser Kernthema, nämlich die Weiterentwicklung und Stärkung von agilen Teams natürlich nicht zu kurz gekommen.

Wir freuen uns schon auf unser nächstes “Chriesi” und geben Vollgas, damit wir es auch tatsächlich erreichen.

Wenn du wissen willst, wie wir das Thema OKR im Detail bei uns einsetzen, so nimm mit uns Kontakt auf und wir werden dir die Systematik und die Umsetzung erläutern. Wir freuen uns über dein Feedback.

Zooiingg! Schon wieder ist jemand in die Falle geraten. Immer wieder schnappt die Falle zu. Unerbittlich. Gnadenlos. Schon viele mutige Ritter wollten die Falle entschärfen. Nur wenigen ist es bisher gelungen. Dieser Blog handelt von einem Ritter, der auszog, die DoR/DoD-Falle zu finden und erfolgreich zu entschärfen.

Doch zuerst müssen wir erläutern, wieso es im fernen Land Agilistan denn überhaupt dazu kam, dass solche Fallen en masse entstanden sind.

Geschichte von DoR/DoD

Blättern wir in der Zeit zurück und gehen ins Jahr 2009. Damals existierte ein mysteriöses Buch “Scrum Guide” [Ken Schwaber, 2009, Scrum Alliance]. Dieses Buch (oder eher Büchlein mit 14 Seiten) beschrieb, wie das Framework Scrum funktioniert und wann ein “increment”, also ein Stück Arbeit, fertig ist. Der Fokus war klar auf dem Verständnis des Teams zur Bedeutung des Wortes “fertig/done”. Jeder im Team musste verstehen, wann tatsächlich ein Stück Arbeit (oder eine Software) fertig war (das Wort “done” kam sage und schreibe 47-mal vor im Büchlein).

Also es musste klar sein, ob das nun nach dem Testen, nach der Integration, nach dem Update der Dokumentation war. Denn ein Team verpflichtet sich gegenüber dem Product Owner, nur “fertige/done” Produkte zu liefern. So kann sich der Product Owner darauf verlassen, dass die Produkte, die er seinen Kunden zur Verfügung stellt, auch tatsächlich (fehlerfrei) funktionieren. So ist die “definition of done (DoD)” entstanden.

Das Büchlein wurde von Ritter zu Ritter (Scrum Master) weitergegeben. Und so entwickelte sich auch das Büchlein weiter. Die Bedeutung von “fertig/done” wurde stetig grösser, bis 2020 sogar von Ken Schwaber & Jeff Sutherland ein “commitment” eingeführt wurde: Die “definition of done” ist eine Verpflichtung (commitment) und muss formal beschrieben sein.

“The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.” [Scrum Guide, 2020]

Viele Ritter haben seither das Büchlein eifrig studiert und erfolgreich angewendet. In etlichen Kämpfen mit furchtbaren Drachen (Stakeholder) haben sie festgestellt, dass die Teams teilweise nicht sehr gut mit Unsicherheit umgehen können und die Erreichung des Zustands “fertig/done” oft schwierig ist. Aus diesen Kämpfen entstand die Idee, man könnte doch das Büchlein ergänzen mit der “definition of ready (DoR)”. Die Teams könnten sich Kriterien von Items im Product Backlog überlegen, die ihnen die Arbeit im Sprint klarer und einfacher machen. Daran könnten sie erkennen, wann ein Product Backlog Item “ready” für den Sprint ist und sie dies einplanen könnten.

Wie die Falle entstand

Fortan blieb diese Idee bestehen und die folgenden Ritter haben nicht bemerkt, dass diese Ergänzung gar nicht im ursprünglichen Büchlein stand. Viele Ritter predigten von nun an, die DoR und DoD seien gefordert und müssen von den Teams definiert werden, sonst würden sie keine Drachen mehr töten können.

Dies rief sofort die Prozess-Orks auf den Plan. Sie witterten Futter für ihre gierigen Prozess-Hälse. Kurz darauf verbreiteten die Prozess-Orks die Botschaft, fortan müsse jedes Team eine DoR und DoD genau in dieser Form haben, ansonsten würden man kommen und sie den Drachen zum Frass vorwerfen. Aus lauter Angst vor den gefürchteten Prozess-Orks wurden die Ritter schwach und befehligten ihren Teams, dass sie ab sofort eine vordefinierte Liste mit Kriterien zu führen hätten, sonst kämen die Prozess-Orks.

Obwohl sich einige tapfere Ritter gegen die Prozess-Orks auflehnten, konnten sie nicht verhindern, dass sich dieses Gedankengut in die Köpfe der Teams und vieler Ritter (Scrum Master) einbrannte. Dies führt nun dazu, dass sich die Teams strikte an die Vorgaben halten, lediglich damit sie nicht den Drachen zum Opfer fallen. Dabei haben sie vergessen, wozu das Büchlein eigentlich gedacht war: Ein leichtgewichtiges Framework, welches den Teams helfen sollte, in einer komplexen Welt mit komplexen Problemen Wert herzustellen.

Was du tun kannst

Diese kleine Geschichte soll zeigen, wie sich ein guter Gedanke mit der Zeit in ein schwerfälliges Prozessgebilde verwandeln kann. In vielen Firmen werden die DoR und DoD wie Quality Gates behandelt, ohne den ursprünglichen Sinn und Zweck verstanden zu haben. Teams haben eine Liste mit Kriterien “formal” abzuhaken, damit sie weiter machen können. Dies führt teilweise zu absurden Situationen, dass Teams Kriterien in ihren DoR oder DoD haben, die sie nie erfüllen, und die dazu auch nie kontrolliert werden. Dieser “waste” wird von vielen Organisationen gefordert und Teams glauben danach, dass agile Prozesse schwerfällig und administrativ aufwändig seien.

Mein Appell an all die Ritter da draussen: Reisst die Fallen ein! Besinnt euch auf die ursprüngliche Mission und verscheucht all die Prozess-Orks. Letztlich wollen wir doch alle die Prinzessin im Schloss befreien. Dabei hilft Ballast (waste) sicher nicht, denn wir müssen und wollen auf dieser Mission agil bleiben!

Wir haben für dich ein kleines Quiz vorbereitet, damit du überprüfen kannst, ob du bereits den Prozess-Orks verfallen bist, oder noch ein wahrer agiler Ritter bist. Melde dich und du kriegst das Quiz kostenlos zugeschickt.

Willst du wissen, was Jeff Sutherland (einer der „Erfinder“ von Scrum) zum Thema „done“ sagt, dann schau dir dieses Video an: https://www.scruminc.com/definition-of-done/