Agiles Arbeiten wirkte in vielen Unternehmen als Wunderwaffe gegen schlechte Qualität, illusorische Deadlines und vom Wasserfall geschundene Teams. Erfährt die Businessseite nun von agilen Teams eine Abfuhr, erscheint Qualität plötzlich in einem anderen Licht. Wir lassen mal beide Seiten gegeneinander antreten:
Zu Beginn der agilen Bewegung mussten agile Coaches vielen Teams in monatelanger Arbeit erst mal beibringen, was Qualität und nachhaltiges Arbeiten überhaupt ist. Auch wenn das immer noch eine stete und manchmal gar nicht wahrgenommene Herausforderung ist, wandelte sich die Qualität in vielen agilen Teams langsam zusehends von einer Variablen zur Konstanten – sie wird ein fix gesetzter Standard, den man nicht mehr in Frage stellen muss und will.
Eines der Versprechungen von agilem Vorgehen ist eine kürzere time-to-market – von der Idee bis zum fertigen Produkt soll es durch agiles Arbeiten schneller gehen. Im Prinzip stimmt das auch. Ja, auch in der Praxis. Zumindest in gut funktionierenden agilen Organisationen. In weniger gut eingespielten tritt zunehmend ein Problem auf:
Agile Methoden – allen voran Scrum – bieten den Entwicklerteams aus gutem Grund die Freiheit, ihre Aufgaben selbst auszuwählen und die Umsetzungsgeschwindigkeit entsprechend zu bestimmen. Das ist positiv, denn es hat vielerorts überhaupt wieder dazu geführt, dass Ergebnisse geliefert werden konnten. Weg von einem blinden Anspruch auf Vollständigkeit, hin zur pragmatischen Schlichtheit. Und damit zur Fokussierung auf einen messbaren Kundennutzen. Nachhaltigkeit war das Gebot der Stunde, Qualität nichts, über das verhandelt werden musste. Doch opfert man für diese zur Not auch die Deadline? Was passiert bei Sonderwünschen? Warum bekomme ich von meinem Team eine Abfuhr?
Das Business hat den Anspruch der agilen Teams an ihre eigene Qualität über die Jahre überwiegend akzeptiert. Einerseits eher gezwungenermaßen: Scrum beispielsweise hat durch die Selbstbestimmungsregeln für das Team schließlich eine Art „Notwehrmechanismus“: Das Team bestimmt die Geschwindigkeit und das „wie“. Und ist – mit Recht – stolz auf das Ergebnis. Andererseits liebt das Business gute Zahlen. Die halbgar entwickelten Features verschwanden, die über Jahre eingegangenen aufgetürmten technischen Schulden werden nach und nach abgebaut und gute Ergebnisse durch Agilität erzielt. Doch was hat sich geändert? Von Businessseite stellt sich die Situation nach dem initialen Enthusiasmus manchmal nicht so erfreulich dar: Die Teams beginnen, es sich in ihrer agilen Komfortzone einzurichten. Die selbstbestimmte abgeschlossene Ritterburg des Sprints ist inzwischen mancherorts mit Hängematten und Cocktailbars ausgestattet – das Business steht draußen vor dem Tor. Fragt das Business am Burgtor ein zusätzliches Feature an, wird so ziemlich jedes Anliegen zumindest hinsichtlich Liefertermin ausweichend beantwortet bis abschlägig beschieden. Das Guckloch im Burgtor knallt wieder zu, die Party geht weiter. Was lernen wir auf Businessseite daraus? Termine sind scheinbar in der Agilität nicht vorgesehen. Nach einigen Abfuhren registriert das Business die schmerzhafte Erfahrung, dass Terminhalten nicht möglich und damit Planbarkeit nicht gegeben ist. Kurzschlussreaktion mancher Organisationen: Wenn Termine wichtig sind, dann bitte less agile und wir machen einen Fallback in den Wasserfall. Mit Salto. Doch ist das ein „Bauchklatscher“?
Aus der Teamperspektive stellt sich das alles naturgemäß anders dar. Jahrelang haben wir schmerzvoll gelernt, dass die Dinge meist nicht nur deutlich komplexer sind, als zunächst vermutet, sondern auch, dass sich pfuschen nicht lohnt: Jedes einzelne Versprechen, das um einer Deadline willen hingehackte technische Provisorium aufzuräumen zu können, wurde gebrochen. Keine Zeit, kein Budget – aus dem Augen, aus dem Sinn des Business’. Funktioniert ja. Aus „das muss nur eine Woche halten“ wurde ein riesiger und unwartbarer Hefeteig an Provisorien. Auszuhalten vom Entwicklerteam, nicht dem Business. Geplant war das nicht und der Kickback immens. Das tut richtig weh. Pfusch muss im Nachhinein nicht doppelt sondern oft zehnfach bezahlt werden. In den Währungen Bugs, Geld, Zeit und Schmerzen. Und wehe, wenn’s dann quietscht oder hängt: die Dresche vom Business gibt’s gratis obendrauf. Willkommen im Hamsterrad.
Nachhaltigkeit und Qualität als Grundsatz ist also kein theoretisches Dogma, sondern erlernte Selbstverteidigung der Teams. Ganz agil und mit einigen blauen Flecken haben wir das gelernt. Und den Anspruch an uns selbst wollen wir nicht aufgeben. Nachhaltig zu arbeiten beweist nämlich Verantwortung - sowohl gegenüber dem Kunden als auch gegenüber der eigenen Organisation.
Beide Standpunkte scheinen ihre Berechtigung zu haben. Soll es nun aber weder möglich sein, einen schnellen und billigen Prototypen herzustellen, noch eine verlässliche Planung eines Produktreleases mit einem definierten Featureset zu bekommen? In voragilen Zeiten war dies doch ohne Probleme an der Tagesordnung. Wie kann das sein? Entwickeln wir uns also mit Agilität zurück? Nein. Der flächendeckende Wechsel hin zu agilem Vorgehen erfolgte ja nicht aus Jux und Dollerei. Zuvor wurde ausschließlich die Businessseite in den Fokus gestellt (was nicht gleichbedeutend ist, dass dies zu Gunsten des Kunden geschah). Jedoch zu Lasten der Ausführenden. Mit der ersten agilen Welle verschob sich der Fokus auf die Technik. Aus gutem Grund und notgedrungen und auch, weil Businessmodelle heute immer techniklastiger werden. Doch jetzt ist es Zeit für die nächste Stufe: Alignment.
Unsere Gegenüberstellung zeigt, dass Probleme auftreten, wenn Business und Technik nicht nahe genug zusammenarbeiten. Dabei geht es um die gemeinschaftliche Co-Kreation in einer dynamischen Umwelt, nicht um das Abarbeiten von Anforderungslisten. Nur gemeinsam sind sie gewappnet für die Herausforderungen dessen, was gemeinhin mit „Digitalisierung“ beschrieben wird. Mit dieser nächsten Stufe kommen wir dahin, dass Qualität weder Dogma noch Selbstverteidigung sein muss, sondern pragmatisch sein kann. Und dass Pragmatismus, das Fundament jeden agilen Vorgehens, auch eine Frage von Vertrauen und Verständnis zwischen Business und Technik ist.
Denn Agilität ist eben mehr als Mechanik. Es ist eine Kulturfrage! Keine Methode. Ein Mindset! In der Agilität ist ein gemeinsames Team wichtiger, als das Produkt. Unsere Happiness ist uns wichtiger, als wirtschaftlicher Erfolg. Klingt dumm, kann aber schlau sein. Weil es nachhaltig ist und weil miteinander und voneinander Lernen der Schlüssel zum Erfolg ist. Denn am Ende steht ein hochqualitatives Produkt und ein gemeinsames Team aus Business und (!) Technik, das für das nächste Projekt gewappnet, ja sogar noch besser geworden ist. Auch wenn manchmal nach draußen Musik dringt.
Um das ewige Ying und Yang zwischen Geschwindigkeit und Qualität besser ausbalancieren zu können, gibt es natürlich auch ein passendes agiles Vorgehen: ESP. Ein „Stabilitätsprogramm“, das die Herausforderungen der Organisation holistisch orchestriert, dabei Risikomanagement, Kennzahlen und die Auswertbarkeit ganz groß schreibt und so dafür sorgt, dass die Organisation sich dabei weder unter- noch überfordert. Das Ziel: Fitness for Purpose! Probiert es aus in unseren Schulungen im September.
Rufen Sie uns an: 030 – 555 74 70 0
