Wie wir das Daily abschafften und besser wurden

Die Kanbanritter beim Rätselraten

Neulich habe ich mich in meiner Kanbanveranstaltung so gefühlt, als wenn ich mich gemeinsam mit sieben Rittern auf der Rätselburg von Fürst Bertram befinde. In dem Buch meines Sohnes hat Fürst Bertram unheimlich viel Freude daran, Rätsel zu ersinnen, die dann von seinen Gefährten oder Untertanen gelöst werden sollen. Eines Tages gab er seinen sieben Rittern folgendes Rätsel mit auf den Weg: „Findet einen edlen Schatz, der sich auf dem Weg zur roten Burg befindet!“ Die Ritter blickten sich verwundert aber erfreut an und sagten: „Ach, so ein einfaches Rätsel. Das ist doch sowas von vorhersehbar und einfach! Ist doch klar wo der Schatz versteckt ist!“ Na klar, dass die Ritter sofort auf ihre Pferde sprangen und schnellstmöglich zur roten Burg ritten! Denn wo sonst verstecken Fürsten ihre Schätze, wenn nicht auf Burgen?

In unserer Kanbanveranstaltung startete unser erstes Rätsel mit einer Frage eines Teilnehmers: „Muss ein Daily täglich sein?“ Die Antworten waren ebenfalls eindeutig:

„Natürlich, sonst hieße es doch nicht Daily“ und
„In der Scrum Guide steht, dass es täglich stattfindet.“ oder
„Nur durch ein tägliches Daily können Schwierigkeiten schnell behoben werden.“

Zurück zu Fürst Bertram: Fast alle Ritter hatten gemeinsam impulsiv auf die Rätselfrage des Fürsten gehandelt. Doch sie kehrten am Abend müde und erschöpft mit leeren Händen ohne den Schatz zu Fürst Bertram zurück. Nur ein einziger Ritter war nicht gleich impulsiv der vermeintlich naheliegendsten oder offensichtlichsten Annahme gefolgt. Und dieser Ritter hatte den Schatz gefunden!

Was dieser Ritter anders gemacht hat und wie du mit der gleichen Lösung eine Antwort auf das Rätsel „Muss ein Daily täglich sein?“ findest, das kannst du in diesem Blog-Artikel lesen.

Anders beobachten, anders denken, anders handeln – in 4 Phasen

Kommen wir also zur Geschichte meines Sohnes zurück. Als sechs Ritter verschwunden waren kam der siebte Ritter Fuß zu Fürst Bertram. Er hatte sich nicht von der allgemeinen simplifizierten Annahme verleiten lassen, dass Schätze immer auf Burgen zu finden sind. Der Fürst war erstaunt: „Ein Ritter der nicht reitet, was soll das für ein Ritter sein?“ Ähnlich hätten auch Antworten auf meiner Kanbanveranstaltung formuliert werden können:

„Ein Agile Coach der ein Daily nicht täglich macht, was soll das für ein Agile Coach sein?“ und
„Was seid ihr für ein agiler Ritter so ganz ohne Scrum Guide und Reifegradmodul unter dem Arm? Sind wir nicht erst reif für den Ritterschlag, wenn wir ein tägliches Daily haben?“

Alfred von Rabenstein antworte: „Was ich für ein Ritter bin? Hoffentlich einer, der nachdenkt.“ „Ihr liebt es bei der Lösung des Rätsels zuzusehen und schaut ihr nicht gerade zu diesem Baum herüber, der so ganz allein auf der Wiese steht?“ Der Fürst wurde blass! Alfred von Rabenstein pfiff sein Pferd heran und stieg behände auf seinen Rücken so, dass er die ersten Äste zu fassen bekam. Und siehe da, als Alfred von Rabenstein durch das Blätterwerk schaute, sah er den Schatz in einer kleinen Schatztruhe!

Alfred von Rabenstein hatte anders beobachtet, anders gedacht und anders gehandelt! Er hatte sich den Fürst erst einmal angeschaut, daraus eine eigene Hypothese gebildet und schließlich ohne Rüstung und Lanze den Baum bestiegen, um seine Hypothese zu validieren. Alles, was einen üblichen Ritter ausmacht hatte er beiseite gelegt: Den Impuls einem allgemeinem Ritterrezept zu folgen und mit Ross und Rüstung zu einer Burg in gewaltigen Sätzen zu stürmen, um dort den Schatz zu erbeuten! „Ihr überrascht mich“, sagte da der Fürst. „Ihr denkt nach, bevor Ihr Schritte setzt.“ Doch wie kommen wir zu diesem ersten Schritt? Diese 4 Phasen können uns dabei helfen:

1) Das Anliegen: Wo schmerzt es uns?

Ich selbst stand nun auf der Kanbanveranstaltung und suchte fieberhaft nach einer eigenen Antwort auf das gestellte Rätsel. Ganz plötzlich erinnerte ich mich an einen meiner Coachees. Er war Scrum Master gewesen und berichtete in einer unserer Coachinggespräche von einem ähnlichen Rätsel. Wie häufig sollte ein Daily sein? Dies war sein Anliegen – sein Schmerz. Und auch in seinem Fall waren die Teilnehmer mit Lösungsoptionen vorgeprescht. Die einen in seinem Team zitierten die Scrum Guide und befürworteten deshalb ein tägliches Daily. Die anderen störten sich an der Zeit, die sie durch das tägliche Daily für ihre operativen Aufgaben verloren und wollten sich gar nicht mehr regelmäßig treffen! Meinem Coachee war die Unsicherheit sichtlich anzumerken. Was könnte das Team nun tun? Ich wartete einen Moment und fragte dann: „Welchen Schatz will das Team denn eigentlich finden?“

2) Das Problem: Warum kann der Kunde nachts nicht schlafen?

Die Frage nach dem Schatz nennen wir die Klärung des Problems. Was wollen wir eigentlich erreichen? Bereits hier ist Vorsicht geboten. Die Einführung eines täglichen Dailys ist eine interne Referenz, die dem Kunden offenkundig erst einmal nichts nützt. Ein Unternehmen aber lebt letztendlich davon, dass es Mehrwerte für seine Kunden schafft. Wir schaffen Mehrwerte, wenn wir seine Probleme lösen. Das nennen wir Wertschöpfung und die Probleme externen Referenzen. Genau diese externen Referenzen sollten das Team steuern. Was also war das Problem des Kunden? Mein Coachee und ich grübelten eine Weile. Doch letztendlich war die Antwort klar: Unser Kunde benötigte Liefertreue.

3) Die Lösungsoptionen: Und nun?

Mein Coachee begann mit meiner Begleitung sich nun über mögliche Lösungsoptionen Gedanken zu machen. Ich merkte wie seine anfängliche Unsicherheit in Aufbruchstimmung umschlug. Ich spürte förmlich, wie ihn die Klarheit eines Ziels motivierte!

Wir begannen zu analysieren: Um die Vorhersagbarkeit eines Systems zu erhöhen müssen wir wie bei einer Waage die eingehende Arbeit des Systems an die Kapazität des Systems anpassen, sonst läuft das System voll und es entstehen unkalkulierbare Verspätungen. Schon einmal Bahn gefahren? Dann kennst du sicher diesen Effekt… Aus 10 min Verspätung werden schnell 20 min und wenn man Glück hat fällt der Zug nicht aus. Anhand eines kumulativen Flowdiagrams konnten wir erkennen, dass sich das System bereits in einem Flow befand, denn die eingehende Arbeit und abgeschlossene Arbeit hielten sich die Waage. Tja, das war schon einmal ein Grund zur Freude!

Nun riefen wir uns noch einmal die Wirkweise eines Dailys ins Gedächtnis: In einem Daily blickt ein Team auf die Arbeit, um

Arbeit durch das System zu ziehen
Auf Überraschungen zu reagieren

Wir dachten weiter: Verweilt Arbeit länger als ein Tag in einer Aktivität und treten keine täglichen Überraschungen auf brauchen wir kein Daily! Ansonsten würden wir Verschwendung betreiben!

Wir schauten uns also die Fließgeschwindigkeit durch das System an. Diese lag bei durchschnittlich 3 Tagen pro Aktivität, d. h. nach drei Tagen zog ein Arbeitspaket weiter zur nächsten Aktivität. Es gab aktuell auch keine nennenswerte Anzahl von Überraschungen bzw. ungeplanter Arbeit. Das Team hatte also mit dem Daily Verschwendung betrieben. Dies hatten Teile des Teams instinktiv gespürt. Mein Coachee atmete förmlich durch. Wir hatten den Eindruck endlich einer vielversprechenden Fährte zu folgen…

4) Abschluss als Experiment

Wir stellten also eine Hypothese auf: Wenn wir also statt dem Daily ein Format finden, welches auf die Fließgeschwindigkeit des Systems und den Grad der Überraschungen angepasst ist, dann werden wir weiterhin kontinuierlich liefern und Verschwendung reduzieren.

Mein Coachee entschloss sich also folgende Idee als Experiment ins Team einzubringen: Daily abzuschaffen und Biweekly einzuführen! Und siehe da: Die Forecastgenauigkeit stieg sogar! Durch die freigewordene Zeit konnten die Entwickler sich unter anderem gegenseitig aushelfen. Die Kommunikation ballte sich nicht mehr um die interne Referenz des Dailys, sondern konnte sich auf die externe Referenz des Kundenproblems fokussieren. Das System hatte noch mehr Luft zum Atmen bekommen! Die Erleichterung war in den folgenden Tagen sowohl bei meinem Coachee als auch im Team sichtlich spürbar.

Werkzeuge und Könner statt Methode und Wissen

Auch Alfred von Rabenstein hatte genügend Luft zum Atmen. Keine Rüstung lag schwer auf seinen Schultern. Ein gemütliches Leben eben. Statt einen ganzen Tag auf einem Pferd zu schwitzen, konnte er sich nach seinem kleinen Kletterausflug auf einer Bank zur Ruhe legen und die Beine ausstrecken. Vielleicht trank er zur Entspannung noch einen Wein? Aber das steht in der Erstlesergeschichte meines Sohnes nicht.

Statt also etwas Neues anzulegen, wie die Ritterrüstung, hatte er sich dieser entledigt. Wirksame Organisationsentwicklung besteht also häufig daraus, Instrumente als Werkzeuge zu begreifen, die uns beim Denken im Sinne des Kundenproblems helfen, statt sie reflexartig und rezeptartig ohne Berücksichtigung des Kundennutzens im Sinne einer Methode einzuführen. Deshalb sollte nie die Methode die Referenz sein, sondern immer das zu lösende Kundenproblem.

Ein Werkzeug hilft uns beim Denken. Doch dafür braucht es einen Könner. Nur durch einen Könner entfaltet ein Werkzeug seine Wirkung! Mit ihren Pferden stürmten die anderen Ritter zur Roten Burg. So wie es in einer ritterlichen Scrum Guide stehen würde: „Das Pferd ist das Fortbewegungsmittel.“. Alfred von Rabenstein aber nutze das Pferd nicht als schnelles Fortbewegungsmittel, sondern als Leiter um den Schatz zu erreichen! Das ist die Anwendung eines Werkzeugs durch einen Könner! Und genau diese Könnerschaft brauchen wir in einem komplexen Umfeld, für die wir im Vorfeld kein Wissen haben, wie ein solches Instrument gewinnbringend angewendet werden könnte.

Das heißt…

Die ritterliche Könnerschaft von Alfred von Rabenstein könnte also wie folgt zusammengefasst werden:

Zunächst das Kundenproblem / die externe Referenz klären
Dann ein Werkzeug anwenden, um möglichst so wenig von etwas zu tun, dass es genau auf das Kundenproblem passt

Auch die Entwickler brauchten letztendlich nicht mehr im Korsett eines täglichen Dailys zu schwitzen, nur weil es so in der Scrum Guide oder in einem Reifegradmodell vorgegeben war.

Heißt das nun, die Scrum Guide oder ein Reifegradmodell sind ein Übel? Mitnichten, wir müssen sie nur als Werkzeug und nicht als Methode verstehen.

Und ihr? Wie geht ihr mit regelmäßigen Abstimmungen um?

Wenn euch diese Art der differenzierten Betrachtung gefallen hat, dann schreibe ich auch in Zukunft gerne über das eine oder andere (nur) vordergründig eindeutige Instrumente der agilen Organisationsentwicklung. Lasst es mich mit einem Daumen oder in einem Kommentar wissen! In diesem Sinne: Ich wünsche euch eine Woche voller spannender Rätsel und leuchtender Schätze!