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!“.

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