Die Bedeutung von Continuous Improvement

Continuous Improvement, kurz CI, ist einer dieser englischen Begriffe, die Einzug in unseren Berufsalltag gehalten haben und mehr bedeuten als ihre reine Übersetzung ins Deutsche. Continuous Improvement bedeutet stetige Verbesserung – und das ist natürlich etwas, wonach die meisten streben, die Karriere machen möchten. Selbst Menschen, die keine Beförderung im Blick haben, sehen eine kontinuierliche Verbesserung als erstrebenswert an, denn schließlich kann eine Verbesserung zu einer Erleichterung der Arbeit, zu mehr Effizienz und damit zu einem befriedigenderen Berufsalltag führen. Aber wer hängt wo die Messlatte wie hoch und was kann eine Führungskraft in Bezug auf Weiterentwicklung überhaupt in der agilen Welt tun? Wir fassen im Folgenden einen Beitrag von Gerri Poling zu diesem Thema zusammen.

Was also bedeutet Continuous Improvement im Kontext der Entwicklung für Führungskräfte? Der Frage ist Gerri Poling nachgegangen. Bis vor einiger Zeit sprachen alle davon, den Maßstab höher zu legen. „Raising the bar“ war in aller Munde. Kaum ein Business-Fachwort wurde im englischen wie auch im Deutschen so gerne missverstanden. „Raising the bar“ bedeutete eigentlich nicht, dass von außerhalb stetig nur aus Prinzip die Latte höher gehängt wird, sondern dass es jemanden gibt, der das Wissen und die Erfahrung hat, um gängige Methoden zu hinterfragen und die Abläufe tatsächlich besser machen kann. Damit hängt er nicht nur die Latte höher, sondern versetzt auch dem gesamten Team einen Schub nach oben. Niemand bleibt außen vor und kann die Latte nicht mehr erreichen. Alle ziehen am selben Strang und verbessern sich.

Ganz im Sinne der höheren Latten ist Continuous Improvement zu sehen. Niemand sollte sich innerhalb eines Unternehmens mit der aktuellen Leistung einfach abfinden und zurücklehnen. Als Gerri Poling vor einigen Jahren bei seinem letzten Arbeitgeber begann, wurde er abrupt in eine auf Business-Literatur ausgerichtete Welt hineingeworfen. Literatur wurde nicht nur gefördert, sondern auf sie wurde auch voll und ganz vertraut, sei es in der Organisation und Planung oder in der Führung des Unternehmens. Es gab Bestrebungen, das Google SRE Modell und die No-Ops Kultur zu übernehmen. Alle Utopien der modernen IT waren erklärte Ziele, denn schließlich wollte man tun, was die „Coolen“ am Markt auch taten. Es wurden umfangreiche Investitionen angestoßen und Training für agile Methoden durchgeführt. Bald schon hatten alle ihre DevOps Titel, aber irgendetwas fehlte noch.

Durch die DevOps Methoden sind alle Teams für ihre Arbeit selbst verantwortlich, einschließlich der Qualität ihrer Produkte sowie der Lieferdaten. Dank DevOps wird niemand mehr benötigt, um die Arbeit eines Teams zu prüfen, zumindest niemand von außerhalb des Teams. Dasselbe gilt auch für die Sicherheitsaspekte und Compliance. Wenn aber Qualität und Sicherheit ebenso wie Zugänglichkeit, Belastbarkeit, Nutzerfreundlichkeit und weitere Aspekte nicht von außen gesteuert und hinterfragt werden, was kann dann ein Team noch zu einer immer neuen Höchstleistung antreiben? Gerri Polings Antwort darauf lautet: Jemand, der den Maßstab etwas höher hängt.
 
Stellen wir die Frage einmal anders: Wer will nicht eine kontinuierliche Verbesserung beim Thema Sicherheit? Wer gibt sich mit „sicher genug“ noch zufrieden? Zumindest niemand, der sich am Markt behaupten will. Und natürlich will auch jeder eine kontinuierliche Verbesserung in der Verfügbarkeit, in der Qualität und der Nutzerfreundlichkeit. Kaum jemand arbeitet noch nach dem Konzept der Error Budgets von Google. Ja-oder-Nein-Parameter waren noch sinnvoll, als wir Anforderungen noch im Voraus abschließend definieren konnten. Aber in einer agilen Welt, in der Continuous Improvement zum alltäglichen Business gehört, brauchen wir andere Ansätze. Wir sollten stets nach Verbesserung streben.

Gleichzeitig streben wir danach, möglichst viel Arbeit nicht mehr machen zu müssen. Die Architektur, die wir zugrunde legen, soll so einfach wie möglich sein und es soll nur das strikte Minimum an Features entwickelt werden. Genauso viel eben, wie benötigt wird. Die Entwickler werden angehalten, mit der Arbeit aufzuhören, während die automatisierten Tests laufen, obwohl sie oft noch nach diesem Punkt einige Vereinfachungen im Code vornehmen. Vor diesem Hintergrund ist auch Googles Konzept der Error Budgets zu sehen. Wie ist aber das Prinzip der Minimierung der Arbeitsschritte mit Continuous Improvement in Einklang zu bringen?

Gerri Poling glaubte, dass das Prinzip des Bar-Raisers, desjenigen, der den Maßstab höher hängt, hier die Antwort sein kann. Er fragt sich, wie es wäre, wenn die unabhängige Qualitätssicherung mit qualitativen Bar-Raisern arbeiten würde, die aber nicht gleichzeitig Gatekeeper sind? Es darf natürlich nicht heißen: „Eure Qualität ist nicht ausreichend“. Es muss heißen: „Wir sehen in diesem oder jedem Aspekt noch die Möglichkeit einer Verbesserung, einer Erhöhung der Messlatte und wir haben auch ein paar Ideen, wie Ihr vielleicht noch mehr aus eurem Projekt herausholen könnt“. Auch bei der Sicherheit ist ein solcher Ansatz denkbar. So könnte das Ergebnis lauten: „Ja, Ihr erfüllt die Sicherheitsstandards. Aber vielleicht sollten wir gemeinsam etwas genauer hinschauen und möglicherweise mit ein paar einfachen, schnellen Handgriffen eine deutliche Verbesserung herbeiführen“.
 
Poling hebt am Ende seines Artikels hervor, dass das Erhöhen von Standards und Messlatten oft mit Kosten verbunden ist, oft aber auch nicht. Er ist davon überzeugt, dass Bar-Raiser nur der nächste Schritt in der digitalen Welt sind, um ganz unauffällig und sanft für unzählige Verbesserungen zu sorgen.