Warum wir Zielbedingungen anstelle von Zielen haben
Um ihre Ziele zu erreichen, sehen die Mitarbeiter vieles übersehen. Das ist keine wünschenswerte Situation. Genauso wie der Stress, den all die Ziele verursachen, die Sie erreichen müssen. Haben Sie schon einmal darüber nachgedacht, stattdessen Zielbedingungen zu verwenden? Wir nutzen diese und werden Ihnen erklären, warum.
Inhaltsverzeichnis
Bleiben Sie gelassen und seien Sie stolz. Das ist es, wonach wir hier bei Easy LMS streben. Das klingt gut, aber wie erreichen wir das? Wir steuern anhand von Prozessen und nicht anhand von Ergebnissen. Wir möchten, dass sich unsere Prozesse verbessern, damit wir bessere Ergebnisse erzielen. Deshalb verwenden wir Zielbedingungen anstelle von Zielen. Auch wenn sie gleich klingen, sind sie doch völlig unterschiedlich. Wir erklären Ihnen, warum.
Zielbedingungen und Zielvorgaben erklärt
Beginnen wir mit einem konkreten Beispiel (aus „Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results“), das Ihnen wahrscheinlich bekannt vorkommen wird. Sie möchten morgens aufstehen und innerhalb einer Stunde an Ihrem Schreibtisch sitzen. Wenn dies Ihr persönliches Ziel ist und Sie in Verzug geraten, müssen Sie sich beeilen. Vielleicht fahren Sie zu schnell, lassen das Frühstück aus oder putzen sich nicht die Zähne. Sie nehmen Abkürzungen, um Ihr Ziel zu erreichen. Wenn Sie dies als Zielbedingung definieren, müssen Sie sie in Teilschritte untergliedern, die Sie messen können. Wenn Sie nicht innerhalb einer Stunde bei der Arbeit sind, ist das kein Problem, denn Sie wissen, welchen Teilschritt Sie verbessern können. Lassen Sie uns also den Zielzustand in die folgenden Schritte unterteilen:
Aufstehen und duschen | 10 Minuten |
Sich anziehen | 10 Minuten |
Frühstücken | 20 Minuten |
Zähne putzen | 3 Minuten |
Schuhe und Jacke anziehen | 2 Minuten |
Mit dem Fahrrad zur Arbeit fahren | 15 Minuten |
Das Ergebnis (das Ziel) dieses Prozesses ist es, pünktlich zur Arbeit zu kommen – gut gestärkt, angezogen, geduscht, mit sauberen Zähnen und ohne in Eile zu sein. Das liegt doch im Interesse aller, oder?
Okay, aber wie unterscheiden sich Ziele von Zielzuständen?
Eine Zielbedingung ist eine Beschreibung der Abläufe in Ihrem Arbeitsalltag, wenn alles reibungslos verläuft.
Zurück zur Theorie. Wir alle kennen das Gefühl, wenn die Arbeit nicht wie geplant verläuft. Manche Dinge dauern länger als gedacht, oder man stößt unterwegs auf Hindernisse. Es kann vieles schiefgehen. Ein Sollzustand ist eine Beschreibung der Abläufe in Ihrer täglichen Arbeit, wenn alles reibungslos verläuft. Ein Sollzustand beschreibt, wie unser Arbeitsprozess und alle seine Teilprozesse aussehen sollen. Dies ist der zukünftige Zustand eines Prozesses, den Sie anstreben. Der Sollzustand gibt uns eine Orientierung für unsere Verbesserungen. Wie? Wir messen unseren Arbeitsprozess während der Arbeit. Jedes Mal, wenn ein Prozess nicht so funktioniert, wie es in der Zielsituation definiert ist, müssen wir dem nachgehen. Wir nennen das eine „Ursachenanalyse“. Wir versuchen, eine einfache Lösung zu finden. Die schnelle Umsetzung dieser Lösung bringt uns unserem gewünschten Zustand näher.
Vergleichen Sie das mit einem Ziel. Ein Ziel soll erreicht werden. Sie müssen alles in Ihrer Macht Stehende tun, um das Ziel zu erreichen, wie im obigen Beispiel zur Routine. Das klingt nach einer heldenhaften Aufgabe, nicht wahr? Falsch. Unserer Meinung nach ist das unsinnig. Ziele führen zu Stress, Überstunden und Enttäuschung über verfehlte Ziele. Sie schaffen die Möglichkeit, Abstriche zu machen, um das Ziel zu erreichen. Dies schadet langfristig der Qualität und der Kundenzufriedenheit.
Wenn Sie ein Ziel erreichen müssen, werden Sie nicht in Prozessverbesserungen investieren.
Abgesehen davon: Wenn Sie ein Ziel erreichen müssen , werden Sie nicht in Prozessverbesserungen investieren. Prozessverbesserungen zahlen sich erst im Laufe der Zeit aus. Die Zeit, die Sie für Verbesserungen aufwenden, wird Ihre kurzfristigen Ergebnisse natürlich beeinträchtigen. Wenn Sie Ihr Ziel schließlich erreichen oder Ihre Frist verpassen, können Sie im Nachhinein auf die Dinge zurückblicken, die nicht wie geplant verlaufen sind. Doch das wird erst Tage oder Wochen später sein, nachdem der eigentliche „Fehltritt“ bereits geschehen ist. Da dies schon so lange zurückliegt, sind die Spuren bereits kalt, und Sie werden keine umsetzbaren Erkenntnisse darüber haben, wie Sie Ihr Ziel beim nächsten Mal erreichen können. Sie haben die Gelegenheit verpasst, Ihren Prozess zu verbessern.
Zusammenfassend lässt sich sagen: Ziele verschleiern Ihre Ineffizienzen und Lernmöglichkeiten, während Zielbedingungen dazu beitragen, deutlich zu machen, wo Sie sich verbessern sollten – Sie beobachten und optimieren den Prozess, anstatt sich auf das Ergebnis zu konzentrieren.
Wenn Sie eine kleine Lösung finden, die Sie sofort umsetzen können, benötigen Sie die große, teure Lösung wahrscheinlich gar nicht.
So nutzen Sie Zielbedingungen zur Verbesserung
Kehren wir zu unserem Beispiel der Morgenroutine zurück. Am ersten Morgen, an dem Sie mit der Messung beginnen, stellen Sie fest, dass das Anziehen 20 Minuten dauert. Nun müssen Sie eine Ursachenanalyse durchführen. Wenn Sie sich näher damit befassen, entdecken Sie, dass das Aussuchen Ihrer Kleidung 10 Minuten in Anspruch nimmt. Dort verlieren Sie 10 Minuten. Also entwickeln Sie zwei Lösungen:
Legen Sie Ihre Kleidung bereits am Vorabend bereit.
Kaufen Sie sich einen Porsche 911, um die Fahrzeit zu verkürzen.
Beides klingt nach vernünftigen Lösungen. Sie bringen Sie pünktlich zur Arbeit. Richtig? Nein, falsch. Lassen Sie mich das erklären:
Wenn Sie Schwierigkeiten haben, pünktlich zur Arbeit zu kommen, wurde Ihnen wahrscheinlich schon einmal geraten, Ihre Kleidung am Vortag bereit zu legen. Doch das ist keine echte Prozessverbesserung. Das Aussuchen der Kleidung dauert immer noch 10 Minuten. Warum gehen Sie nicht einfach 10 Minuten früher ins Bett, stehen 10 Minuten früher auf und nehmen sich die 10 Minuten Zeit, die dafür nötig sind? Eine echte Lösung wäre es, den Zeitaufwand zu reduzieren: Tragen Sie dasselbe Hemd oder denselben Rollkragenpullover wie Mark Zuckerberg oder wie es Steve Jobs tat. Oder tragen Sie jeden Montag dieselbe Kleidung, und wenn Sie Wäsche waschen, legen Sie diese Kleidungsstücke auf einen Stapel. Oder ordnen Sie Ihren Kleiderschrank so um, dass zusammenpassende Kleidungsstücke in Ihren Schubladen nebeneinander liegen.
Die Lösung, ein Auto zu kaufen, ist zu umfangreich. Sie haben nicht das nötige Budget dafür. Die Lieferzeit für das Auto beträgt einige Wochen. Wenn Sie eine kleine Lösung finden, die Sie sofort umsetzen können, brauchen Sie die große, teure Lösung wahrscheinlich gar nicht.
Schauen wir uns einige Beispiele von Easy LMS an
Bei Easy LMS streben wir einen „Single-Item-Flow“ an.
Bei Easy LMS streben wir einen „Single-Item-Flow“ an. Das bedeutet, dass eine User Story reibungslos durch unseren Entwicklungsprozess fließen soll, ohne irgendwo darauf warten zu müssen, dass andere Elemente fertiggestellt werden. Als wir begannen, mit diesem Ziel zu arbeiten, lief es nicht reibungslos. Der Zyklus – also die Zeit zwischen dem Beginn der Arbeit an einer neuen Funktion und deren Online-Schaltung – betrug 32 Tage. Wir begannen, die Daten zu unserem Arbeitsprozess zu analysieren, um herauszufinden, wo Verbesserungsbedarf bestand. Dabei stellten wir fest, dass Stories ins Stocken gerieten, während sie auf eine Veröffentlichung warteten. Unser Veröffentlichungsprozess war das Erste, was wir verbessern wollten.
Zwei Releases pro Woche
Wir stellten uns folgende Herausforderung: Innerhalb eines Jahres einen „Single-Item-Flow“ zu erreichen. Um dorthin zu gelangen, mussten wir verschiedene Zielvorgaben festlegen, die uns unserem Ziel näherbringen würden.
Die erste Zielvorgabe, die wir festlegten, war, von einem Release alle zwei oder drei Wochen auf zwei Releases pro Woche umzustellen. Dies erschien uns fast unerreichbar:
Wir begannen, zwei Releases pro Woche – dienstags und donnerstags – zu planen und wollten einfach sehen, welche Herausforderungen sich dabei ergeben würden. Wir setzten uns zusammen und beschrieben die für das Release erforderlichen Schritte sowie die jeweiligen Zuständigkeiten.
Das allererste Release verlief nicht wie geplant. Der für das Release verantwortliche Entwickler war an diesem Tag krank. Die übrigen Entwickler waren mit einem anderen Projekt betraut. Die Lösung bestand darin, das Release zu automatisieren und zu planen, damit es nicht von manuellen Eingriffen abhängig war. Durch die Automatisierung wurde das Release am Dienstag und Donnerstag früh morgens auf den Staging-Server bereitgestellt, bereit für den von Caroline (QA/QC) durchzuführenden Abnahmetest.
Der nächste Engpass, auf den wir stießen, war Caroline. Sie ist für den Abschluss der Veröffentlichung verantwortlich, doch an diesem Tag war sie sehr damit beschäftigt, die Übersetzer zu koordinieren, um sicherzustellen, dass alles aus der vorherigen Veröffentlichung übersetzt wurde. Wir haben unseren Übersetzungsprozess verbessert – was eine ganz andere Geschichte ist –, damit Caroline mehr Zeit hätte, sich auf das Testen zu konzentrieren. Ich höre Sie schon denken: Warum stellen wir nicht einfach einen zusätzlichen Tester ein? Zu diesem Zeitpunkt hatten wir jedoch nicht das Budget, um einen zusätzlichen Tester einzustellen. Auf den ersten Blick scheint die Einstellung von Personal eine plausible Lösung für das Problem zu sein, doch die Einstellung zusätzlicher Mitarbeiter stellt keine echte Prozessverbesserung dar.
Nach zwei Monaten und vielen kleinen Verbesserungen gelang es uns, zwei Releases pro Woche zu erreichen.
Für die nächste Zielvorgabe richteten wir unsere Aufmerksamkeit auf verschiedene Teile des Entwicklungsprozesses. Da wir unseren Arbeitsprozess kontinuierlich verbesserten, durchliefen immer mehr Stories den Entwicklungsprozess. Infolgedessen wurden die Releases umfangreicher. Umfangreichere Releases benötigen mehr Zeit. Manchmal konnten wir ein Release nicht abschließen, bevor das nächste bereits fertig war. Dadurch verfehlten wir die Zielvorgabe von zwei Releases pro Woche.
Wie wir von zwei auf vier Releases pro Woche kamen
Um dieses Problem zu lösen, mussten die Releases kleiner werden. Wir beschlossen, als nächste Zielvorgabe festzulegen, ein Release durchzuführen, sobald vier Stories zur Veröffentlichung bereit waren. Dies führte zu häufigeren, kleineren Releases. Vor kurzem haben wir die Messlatte höher gelegt und die Anzahl der Stories pro Release auf zwei gesenkt. Wir sind fast bei der Bereitstellung einzelner Elemente angelangt.
Der Weg von zwei Releases alle zwei oder drei Wochen zu vier Releases pro Woche ist ein enormer Fortschritt. Um dies zu erreichen, haben wir unzählige kleine Verbesserungen vorgenommen sowie einige größere, wie beispielsweise die Automatisierung fast aller Abnahmetests.
Zykluszeit
Als Ergebnis dieser Zielvorgaben konnten wir die Durchlaufzeit einer Story von 32 Tagen auf sechs Tage senken.
Dabei haben wir die Beschreibung der Zielvorgabe definiert und verbessert, viel gelernt und eine Menge Verschwendung reduziert. Als Ergebnis dieser Zielvorgaben haben wir die Zykluszeit einer Story von 32 Tagen auf sechs Tage gesenkt – bei besserer Codequalität, weniger Ablenkungen, fast keinen Hotfixes und zufriedeneren Mitarbeitern.
Was bedeutet das für unsere Unternehmenskultur?
Wir sagen immer, dass Scheitern nichts Schlechtes ist, solange man daraus etwas lernt. Wenn wir eine Zielbedingung festgelegt haben, wissen wir tatsächlich, wann wir scheitern und was wir lernen müssen. Scheitern führt also zum Lernen.
Wir sind eifrige Lerner. Haben wir alle Zielbedingungen erfüllt? Dann haben wir noch nicht genug gelernt und sollten eine neue, strengere und anspruchsvollere Zielbedingung festlegen, die uns erneut auf ein Scheitern vorbereitet. Dies führt zu kontinuierlichem Lernen.
Lernen ist für uns die wichtigste Zielvorgabe, um ein erfolgreiches und nachhaltiges Unternehmen zu sein. Zu lernen, wie man sich verbessert, ist der erste Schritt auf diesem Lernweg.
Sind Sie neugierig auf unsere besondere Arbeitskultur? Entdecken Sie unseren Bereich „Arbeiten bei Easy LMS“, um mehr zu erfahren!