Breakpoint Wilson: Agiles Arbeiten ist erst der Anfang

Agile als Ausgangspunkt
Kommentare

Agiles Arbeiten in der Softwareentwicklung kann nur als Ausgangspunkt für weitere Verbesserungen dienen.

Die Einführung agiler und iterativer Arbeitsweisen in den letzten Jahren gelten als lang ersehnte Antwort um den Missstand aus dem Ruder laufender IT-Projekte zufriedenstellend entgegentreten zu können. Wobei sich hier für manches Unternehmen neue Herausforderungen auf organisatorischen und sozialen Ebenen ergeben.

Denn mit weit entwickelten agilen Ansätzen finden sich nun nämlich gegebenenfalls weniger die Entwicklungsabteilungen als der Rest des Unternehmens in einer unangenehmen Situation wieder: Plötzlich geht es um Dinge wie die Umstrukturierung des Angebots-Modus, Vertrauen schaffen und das Auflösen rivalisierender Unternehmensstrukturen.

Agile Hängematte

Ich durfte vor einiger Zeit, dem Gespräch zweier weit herum gekommener und gesetzter IT-Berater lauschen. Sie sprachen sogar davon, dass agile Softwareentwicklung „Bauernfängerei“ sei. Mitarbeiter würden mit dem Versprechen einer „agilen Hängematte“ vergiftet. Ausschließlich, damit sich einzelne Sophisten mit Trainings und Zertifizierungen bereichern können; Unternehmen brächte es hingegen nur den Ärger. Der Gipfel des gesamten Trends sei ihrer Meinung nach die „No-Estimation“-Bewegung gewesen, in der es darum geht, gar keine Estimation-Commitments mehr zu tätigen.

Plötzlich fand ich mich emotional und gedanklich zwischen zwei Stühlen sitzend wieder: Der technikfokussierte Entwickler in mir wollte sich empören und widersprechen. Mein innerer, wirtschaftlich orientierter Berater hingegen, verstand die betrieblichen Herausforderungen.

Wenn ich in einem Markt/System wirtschafte, der fast ausnahmslos linear skalierbar und hierarchisch agiert, ist es unheimlich risikoreich und schwierig, ein non-linear produzierendes Unternehmen zu führen. Noch komplizierter wird es dann natürlich, wenn man intern lineare Gehaltsversprechen anbietet, ohne einen gleichfalls linearen oder zumindest geschätzten Output erwarten zu können.

So lange ein Unternehmen also keine Möglichkeit findet, die Regeln interner Produktionsgeschwindigkeit in Einklang mit dem externen System (der Marktwirtschaft, Kunden) zu finden, wird hier ein dauerhaftes Spannungsfeld bestehen.

In einer Branche vor unserer Zeit

In einer Branche vor unserer Zeit, in der Computer zurecht als Neuland galten, war man es gewohnt, mit industrieller Effizienz arbeiten und rechnen zu können. Die Arbeitsgegenstände waren überwiegend physisch, Arbeitsprozesse konnten linear skaliert werden, und die berufliche Mindestqualifikation für die meisten Tätigkeiten waren verhältnismäßig niedrig. Man konnte also relativ einfach errechnen, in welcher Zeit man wie viele Produkte herstellen konnte und wie teuer das Ganze werden würde.

Auch hier gab es einige Gewerbe, die in einer anderen Risiko-Klasse stattfanden. Ein Arzt beispielsweise garantiert einem keine Erfolgsergebnisse, und jeder akzeptiert das. Im Gegensatz dazu gilt es in den meisten Branchen als gesetzt, Erfolg vertraglich zu garantieren. Beim Terminbau hat schon so mancher Unternehmer Kopf und Kragen verloren, weil er nicht liefern konnte. Fern ab davon war die industrielle Welt allerdings linear, konstant und für alle in Ordnung. Blieben doch gewisse Risiken, konnte man sie in der Regel gegenversichern.

Anders als bei der industriellen Produktion handelt es sich bei Versicherungen zwar um virtuelle Produkte, aber dafür braucht man auch nicht wirklich etwas produzieren. Versicherungsverträge haben keine Deadline und viele Policen treten gar nicht erst in Kraft. Wenn dem so wäre, hätte diese Branche ein großes Problem. Es sind Versprechen, die man lediglich vertraglich niedergeschrieben hat.

Ein weiterer Vorteil der Versicherer ist, dass sie die Last im Zweifelsfall auf den Versicherungsnehmer umgelegt werden kann. Tritt ein Versicherungsfall ein, wird das Produkt aktiv und der Kunde bekommt kurzfristig mehr Geld. Langfristig hingegen wird der Kunde dieses aber durch eine Beitragserhöhung wieder los. Das erinnert übrigens ein wenig an das gängige Claim-Management vieler Software-Dienstleister, um sich trotz Wettbewerb und Terminverträgen langfristig wirtschaftlich zu halten.

Times, They are a-changing

Als der Mensch damit begann, Software im industriellen Stil zu produzieren, trafen also zwei unterschiedliche Systeme aufeinander. Eines dachte und produzierte sehr linear, das andere funktionierte vor allem non-linear. Entwicklungsgeschwindigkeit skaliert in den seltensten Fällen proportional zu der Anzahl eingesetzter Entwickler. Grund dafür scheint mutmaßlich vor allem der Initialaufwand in Koordinierung und Kommunikation aller Beteiligten eines Entwicklungs-Kontexts zu sein.

Wie das Aufeinandertreffen unterschiedlicher Wetter-Schichten sorgt das für gewisse Turbulenzen im Betrieb. Eine Idee diese Turbulenzen kontrollierbar zu gestalten, sind beispielsweise Ansätze wie das Wasserfall-Modell aus der frühen Zeit oder die agile Softwareentwicklung aus der heutigen Zeit.

Softwareentwicklung, das unbekannte Wesen

Was macht Softwareentwicklung eigentlich so unvorhersehbar? Zwar spricht man davon, dass moderne Software seit etwa den 70er Jahren entwickelt wird, aber dennoch wissen wir – außer, dass Freitag-Deployments eigentlich immer schiefgehen – vergleichsweise wenig über unsere Branche.

Wie auch? Bis auf wenige Theorien, wie die Turing-Vollständigkeit oder das Mooresche Gesetz, ist die Softwareentwicklung als Teil der Informatik eine der sich am schnellsten verändernden Disziplinen unserer Zeit. Erfahrungswerte dieser Branche gehen vielleicht maximal 40 Jahre zurück. Doch damals waren wirtschaftliche Herausforderungen und die Systemkomplexität ganz andere.

Geht man davon aus, dass der Rest der Wirtschafts-Methoden bereits seit dem 19. Jahrhundert wachsen und besser werden konnten, ist die Zeit, in der wir Erfahrung mit dieser neuen, nicht stofflichen Industrie machen konnten, nicht besonders lang.

Fortschritt

Zwar bauen unsere Arbeitsmittel irgendwie immer wieder aufeinander auf, aber es verändert sich gefühlt (!) alle drei bis fünf Jahre alles grundlegend. Das ist irgendwo auch gut so; es signalisiert Fortschritt.

Auf der anderen Seite bringt uns diese Geschwindigkeit gleichermaßen in die unangenehme Situation, dass wir eigentlich nie guten Gewissens eine zuverlässige Einschätzung über große Aufgaben abgeben können. Software und Systeme nehmen stetig an Komplexität zu, neue Technologien und Ideen kommen hinzu. Langjährig gesetzte Standards existieren nur wenige.

Was Ingenieure uns bei weitem voraushaben ist, dass Sie aus einem riesigen Lego-Kasten an auf einander genormte Bauteile wählen können – das macht das Konstruieren von Maschinen wesentlich geschmeidiger. Wir haben zwar Frameworks und Libraries, doch so richtig linear klappt das alles bei uns noch nicht.

Klein halten

Das Einzige was wir also tun können ist, die großen Dinge möglichst klein zu halten und überschaubar zu trennen. Für diese überschaubaren Pakete können wir leichter entsprechende Aufwände schätzen. Wird hier aufrichtig geschätzt, steigt pro Paket die theoretische Wahrscheinlichkeit, dass der Gesamt-Plan reibungslos zu navigieren bleibt. Am besten pokert man noch gemeinschaftlich die Aufwände aus; was natürlich nur effizient werden kann, wenn man möglichst lange in der gleichen Konstellation zusammenarbeitet. Erinnert alles ein wenig an die „Intelligenz der Masse“ von Francis Galton.

Je mehr ernsthafte Schätzungen zu einem konkreten, überschaubaren Thema abgegeben werden, desto höher ist die Annäherung an den tatsächlichen Wert. Kurze Iterationen ergänzen diesen Vorteil noch um ein Steuerungs-Instrument auf der Ebene der Projekt-Navigation.

Es scheint also ein wenig so, als dass wir prinzipiell immer noch relativ hilflos sind, wenn es darum geht, Softwareentwicklung risikoarm und den Erwartungen der Marktwirtschaft gerecht zu gestalten. Dafür gehen wir damit aber viel besser um als noch in den 90er Jahren, als wir noch keine agilen Methoden einsetzten.

Cherry Picking

Agile Softwareentwicklung scheint mir persönlich die bisher Beste der schlechten Vorgehensweisen zu sein. Allerdings bezweifle ich, dass dies der Wahrheit letzter Schluss gewesen sein wird.

Wie bereits erwähnt, stellt die Liebäugelei mit der kontrollierten Ungenauigkeit Unternehmen weltweit vor besondere Herausforderungen. Verständlicherweise stellt das insbesondere Unternehmen die einen geringen Spielraum für Fehlversuche haben vor existentielle Risiken. Wie weit und wie stark Unternehmen sich auf alternative Organisationskonzepte und Projektplanung einlassen können, sollte eine individuelle Entscheidung bleiben.

Man kann sich allerdings sicher sein, dass sich die unternehmerischen Betriebssysteme, in denen wir arbeiten, in den kommenden Jahren viele weitere male wesentlich von der Arbeitsweise traditioneller Industrien entfernen werden. … wenn der allgemein herrschende Digitalisierungstrend der Weltwirtschaft nicht sogar dafür sorgt, dass alle anderen sich bereits an den in der Software-Branche erprobten Arbeitsweisen orientieren werden.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -