Share ZU:
21 August 2012 @ Uwe Valentini

Optimal und doch schlecht

„Vor 6 Monaten haben wir SCRUM eingeführt, uns Berater und Coaches ins Haus geholt und alle geben ihr Bestes. Und trotzdem sind wir nicht schneller in der Entwicklung geworden und die Qualität läßt immer noch zu wünschen übrig. Wie kann das sein?“

Da kann man nur eines mit Sicherheit sagen: SCRUM ist nicht schuld daran. Möglicherweise sind auch die Berater nicht schuld daran, auch wenn Einkäufer dazu tendieren, die billigsten Angebote anzunehmen. Hinter dem ausbleibenden Erfolg steckt typischerweise ein ganzes Bündel von Ursachen, zu denen die Angst vor Neuem, Missverständnisse, Ignoranz, ungenügende Information, Karrieredenken und Silo-Mentalität gehören. Ich möchte heute auf ein Problem näher eingehen, das in den genannten Ursachenkategorien verankert und überall anzutreffen ist. Wer Entscheidungen trifft, glaubt häufig, die bestmögliche Entscheidung zu treffen – aber sehr häufig ist dieses „bestmöglich“ nur das beste für diese Person selbst oder ihre Abteilung, nicht aber für die Gesamtorganisation. Es ist eine lokale Optimierung.

Agile Vorhensweisen haben das Ziel, dem Kunden möglichst schnell etwas zu liefern, was er braucht, was einen Wert für ihn darstellt. Maximiert werden soll also der Durchsatz von Wert für den Kunden und das Beseitigen von Hindernissen auf diesem Weg. Meist wird stattdessen aber versucht, die Auslastung des einzelnen Mitarbeiters zu maximieren. Anforderungsexperten schreiben z.B. umfangreiche Spezifikationen (damit sie beschäftigt sind und nicht etwa testen können), auch wenn 70 % der Anforderungen erst in einem Jahr oder später umgesetzt werden sollen – das ist Verschwendung, die Halbwertszeit von Anforderungen ist deutlich kürzer. Alle sind unglaublich beschäftigt, da muss ja etwas Wertvolles dabei herauskommen. Eine typische lokale Optimierung.

Wenn Arbeitspakte geplant werden, geschieht dies meist entlang der Spezialisierung einzelner Mitarbeiter. Eine Aufgabe wird demjenigen zugeteilt, der sie am besten und schnellsten erledigen kann. Tendenziell maximiert dies dann die Menge auf Halde liegender Zwischenergebnisse, die nie den Weg zum Kunden finden oder von diesem nie gebraucht werden. Es wird das optimiert, was am schnellsten und einfachsten geht, und nicht das, was für den Kunden den größten Wert darstellt. Wenn Arbeit basierend auf Spezialistentum statt auf Kundenwert erledigt wird, ist das meist suboptimal – eben eine lokale Optimierung.

Das Verharren in alten Denkweisen und das Ignorieren von neuen Wegen zu arbeiten führt ebenfalls zu lokalen Optimierungen – etwa die klassische Arbeit eines Integration Managers, der gemäß eines „optimierten“ Integrationsplans festlegt, wie die gesamte Software integriert werden soll, obwohl die Einführung von Continuous Integration kombiniert mit einem CI-System diese Rolle überflüssig macht.

„Wir testen sehr spät, da dann die Software ausgereifter ist und weniger Fehler hat; das senkt die Testkosten.“ Da erübrigt sich jeder weitere Kommentar.

Auch die Auswahl von Software Tools ist anfällig für lokale Optimierungen – oft wird ein möglichst billiges Tool gewählt (eigenartigerweise aber relativ selten Open Source), oder eines, das am besten für eine bestimmte Rolle passt, obwohl viele Rollen es benutzen sollen.

Der eingangs schon erwähnte Einkauf der „billigsten“ statt der für eine Aufgabe geeignetsten Berater ist ebenfalls eine lokale Optimierung.

Es macht sehr viel Sinn, Entscheidungen dahingehend zu hinterfragen, ob sie darauf fokussieren, dem Kunden schnell einen Wert zu liefern, oder auf die Interessen einer Abteilung, einer Person oder einer internen Richtlinie.

Lokale Optimierungen sind sehr weit verbreitet und führen dadurch, daß sie nicht auf den Kundenwert fokussieren, zu Verschwendung von Resourcen. Sie sind auch unabhängig von der Art des etablierten Entwicklungsprozesses. Wir sind damit trotz vernünftiger Entwicklungsprozesse durchaus fähig, systematisch schlechte Software zu produzieren. Agile Verfahren haben dagegen den Vorteil, daß sie es uns erlauben, Probleme viel früher zu erkennen – wenn man sie denn erkennen will. In den meisten Unternehmen sind dafür jedoch radikale Veränderungen in der Organisationsstruktur und im Management notwendig.

Uwe Valentini

Kontaktieren Sie Uwe Valentini

Uwe Valentini arbeitet bei Agile-by-HOOD als Berater und Coach mit viel persönlichem Engagement mit Menschen, Teams und Organisationen auf ihrem Weg zu mehr Agilität. Uwe ist leidenschaftlicher Agilist, er lernt jeden Tag etwas Neues und hat viel Spaß daran. Sein Motto: Agilität beginnt im Kopf.