Agile Missverständnisse: Schneller mit Agil

„Twice the work in half the time“, so heisst es an manchen Stellen. „Agil skalieren!“, hört man häufiger von Vertretern der unterschiedlichsten Skalierungs-Frameworks. Skalieren, das klingt so schön nach Fahrt aufnehmen. Nächste Haltestelle Hyperloop. Ich kann schon das Leuchten in den Augen der Unternehmen sehen, die Geschwindigkeit nun auf die gesamte Organisation ausrollen wollen.

Doch Ihr ahnt schon, dass da erneut ein Missverständnis lauert …

Agile to the Rescue

Ein schlauer Mensch hat einmal sinngemäß gesagt: „Unternehmen designen Systeme, die ihrer Kommunikationsstruktur entsprechen.“ (Conway‘s Law)

Nun ist es außerdem so, dass viele (bisher) erfolgreiche Unternehmen IT-Systeme haben, die schon seit Jahrzehnten bestehen. Aufgrund des Alters, des Wandels in den Märkten sowie unterschiedlichster Kommunikations- und Organisations-Strukturen kennen viele Unternehmen etwas, was man als (schwer) wartbare Monolithen bezeichnen würde.

Was liegt da also näher, als sich „agil aufzustellen“, denn schließlich hat man gehört, dass man damit die doppelte Arbeit in der Hälfte der Zeit erledigen kann?

Wunsch versus Wirklichkeit

Menschen, die nicht in der Softwareentwicklung tätig sind oder eine Historie darin haben, verstehen oftmals nur schwer bis gar nicht, was es bedeutet, einen Monolithen bzw. ein Softwaresystem mit neuen Funktionen zu versorgen oder (die schönere Variante) zu modernisieren.

Manch einer möchte auch gleichzeitig Modernisierung und neue Funktionen haben. Und wundert sich dann, warum „nichts voran geht“.

Dabei wurde jetzt doch eine agile Teamstruktur eingeführt, ein Scrum Master bereitgestellt, das Team zu 100 Prozent auf das eine Softwaresystem fokussiert, und ein 100-Prozent-Product-Owner abgestellt. Immerhin wurde mit Blick auf die Technik die Parole „Microservices!“ ausgegeben.

… und es bewegt sich immer noch nichts

Oder nicht viel. Ganz besonders dann, wenn die Organisation über ein eigenes Prozessmodell verfügt, wie „Projekte“ umzusetzen sind. Und das agile Framework, das man nutzt, sich da irgendwie einfügen muss. Das ja nicht nur Prozess-Elemente enthält, sondern auch Werte und Prinzipien.

Dann denken wir schnell: „Da müsste doch noch was voran gehen!“ Oder „Scrum/Framework-der-Wahl ist Schuld, dass das nicht voran geht!“.

— Herausforderungen diskutieren —

Diskutiere mit uns deine Herausforderungen in Euren Szenarien. Vereinbare jetzt einen kostenfreien Beratungstermin, damit wir uns Dein Szenario einmal mit unserer Brille ansehen.

Was also tun?

Die Kunst besteht darin, den aufkommenden Reflex – mal wieder – zu unterdrücken.

Und sich dann eine neue Perspektive zu eröffnen, die gar nicht so einfach zu handhaben ist. Wenn wir daran glauben, dass Kommunikationsstrukturen und Softwaresysteme miteinander zusammenhängen (siehe oben, Conway‘s Law), dann reicht es nicht aus, jeweils nur eine der beiden Seiten zu betrachten.

Wir müssen uns also beide Seiten anschauen und gemeinsam in Einklang bringen. Das ist für PMOs, Management/Teamleiter/Abteilungsleiter ohne Softwarekompetenz eine gewisse Hürde.

Wenn wir jedoch den Denkrahmen an dieser Stelle erweitern, fällt es uns leichter, Lösungsstrategien für die oben genannten Problemstellen zu entwickeln. Das kann nur gemeinsam gehen, zusammen mit der Technikkompetenz.

Denn was nützt die beste agile Teamstruktur, wenn wir immer noch einen Software-Monolithen aus den 90ern des letzten Jahrhunderts unten drunter haben?

Das Team, also die Personen, ist ja noch immer gleich „schnell“. Aber wir machen weniger Dinge, die wir in Wahrheit nicht benötigen – weil wir es frühzeitiger merken. Wir produzieren also weniger Waste, d. h. Verschwendung.

Unsere Serie Agile Missverständnisse


Für neue Blogupdates anmelden:


2 Gedanken zu “Agile Missverständnisse: Schneller mit Agil

  1. Geschwindigkeit ist nicht das Ziel von agiler Vorgehensweise. Es ist ein Nebenprodukt davon, wenn man Agilität verstanden hat und richtig anwendet. Der Titel von Jeff Sutherlands Buch „Doing Twice the Work in Half the Time“ ist diesbezüglich ein Management Brainfuck und schürt falsche Erwartungen. (Sie klären sich aber auf, wenn man das Buch tatsächlich liest.)
    Ein Scrum Team existiert nicht im luftleeren Raum. Es gibt Interaktionen mit allen möglichen Stellen in der Organisation, die einen Einfluss auf die Performance des Teams haben. Lediglich ein Scrum Team aufzustellen und den Rest der Organisations- und Interaktionsstruktur unverändert zu lassen, wird zu eher enttäuschenden (unter den Erwartung bleibenden) Ergebnissen führen.

    • Danke für deinen Kommentar, Christoph.

      Genau so ist es. Neben der Organisations- und Interaktionsstruktur kommt natürlich noch die Technologie-Sicht hinzu, Stichwort Legacy / Monolithen. Diesen Dreiklang zu verstehen, und dann versuchen ihn zu betrachten und daraus graduelle Verbesserungsmaßnahmen abzuleiten, sollte eine der Kernaufgaben sein, wenn man sich ernsthaft verbessern möchte.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.