Von Kant und Coden
Bei Immanuel Kant war der kategorische Imperativ das grundlegende Prinzip der Ethik. Grob gesagt soll jeder Einzelne nur nach solchen Regeln handeln, bei denen es in Ordnung wäre, wenn sie ein allgemeines Gesetz werden. D.h. Was du nicht willst, dass man dir tu', das füg auch keinem andern zu. So weit, so irrelevant für die Softwareentwicklung. Könnte man meinen.
Folgen Sie uns über die nächsten Zeilen - dieser Beitrag soll zeigen, dass vor allem für Softwareentwickler unerwartet viel in diesem Leitsatz steckt.
Von der Idee zur Lösung
In unseren Beratungsprojekten dürfen wir oft Teams kennenlernen, die gut ausgebildet und motiviert sind, ausgestattet mit den neuesten Werkzeugen. Und doch können diese Teams oft nur wenig bewegen. Woran liegt das?
Jeder Kunde und jedes Projekt sind für sich genommen einzigartig. Es gibt jedoch zwei Grundmuster, die wir Ihnen gern vorstellen möchten.
Muster 1: „Exegese“
Dieses Muster tritt häufig dann auf, wenn nicht projektgetrieben gearbeitet wird. Entwicklungs- oder Testaufwände sind in solchen Kontexten häufig Gemeinkosten (wie Wasser, Gas, Strom...) und kaum messbar. Wir finden diese Dynamik überwiegend in kleineren Unternehmen mit weniger als 50 Mitarbeitern, aber auch größere Unternehmen sind davor nicht gefeit.
Aufgrund der fehlenden Sichtbarkeit von Aufwänden entwickeln die verschiedenen Stakeholder lokale Optima, etwa...
- Das Business möchte mehr mit dem Kunden arbeiten und investiert deswegen nur minimale Zeit in Spezifikationen oder Anforderungserhebung. Dies erhöht die Aufwände in der Softwareentwicklung.
- Product Owner drängen Entwickler und Tester, vorzeitig zu releasen, etwa um einen prestigeträchtigen Messetermin halten zu können. Dies verursacht erhöhte Aufwände beim Kundendienst.
Wie bei einem Fluss „fließen“ die Aufwände für das Ermitteln und Abstimmen von Anforderungen talwärts, im Englischen spricht man bei solchen Prozessketten tatsächlich auch von downstream. Bitte beachten Sie: Die Menge der zu leistenden Arbeit ist immer gleich, sie wird nur verlagert!
Diese Verlagerung führt nicht zu einer Effizienzsteigerung - sie erhöht die Gesamtaufwände nur. Der Grund dafür ist die Arbeit mit unfertigen Inputs – im Bereich der Softwareentwicklung also die Arbeit mit unfertigen Anforderungen.
Erinnern Sie sich an die Einleitung: Wir gehen in Übereinstimmung mit den Prinzipien aus dem Agilen Manifest davon aus, dass wir „Motivated Individuals“ in unseren Teams beschäftigen. Diese "Motivated Individuals" können und wollen ihren Kopf nicht einfach ausschalten – schließlich werden sie in der Regel für das Denken bezahlt. Sie füllen also alle Unklarheiten in Anforderungen mit Annahmen auf. Dies geschieht bei jeder sprachlichen Ungenauigkeit, bei jeder Fortlassung von Informationen oder Festlegungen.
Diese Reihe von Annahmen ist der Grund, warum wir dieses Muster „Exegese“ nennen. Die Teams betreiben eine Art Auslegung oder Reverse-Engineering. Sie müssen mühsam deuten, was stromaufwärts gedacht und gemeint war.
Deshalb greift beim Verschieben von Aufwänden zu nachgelagerten Prozessschritten die Zehnerregel - illustriert von der untenstehende Abbildung. (Buchtipp: Software Engineering Economics von Barry W. Boehm, 1981).
Quelle: https://www.sixsigmablackbelt.de/
Wie hoch ist bei diesem Muster wohl die Wahrscheinlichkeit, dass das fertige Produkt die ursprüngliche Idee umsetzt und die Business-Anforderungen erfüllt?
Muster 2: „Stille Post“
Dieses Muster finden wir bei größeren Kunden. Aus Sorge vor Chaos, Unsicherheiten und Unklarheit wurden stabile Prozesse eingeführt und ein detailliertes Organigramm mit klaren Verantwortlichkeiten erarbeitet. Das Prinzip lautet „Teile und Herrsche“, und was bei produzierenden Industrieunternehmen gut funktioniert kann in der Softwareentwicklung ja nicht schlecht sein, oder?
Auf dem Weg von der Idee zur Lösung entstehen dann allerdings folgende Schnittstellen (die sich oft auch 1:1 im Phasen-Meilensteinplan finden):
- (Beim Kunden) Anwender → Key-User → Process Owner → ...
- Kunde → Account Manager/Projektmanager
- Account Manager/Projektmanager ↔ Analyst/Lead Developer
- Mehrere Schleifen, bis Aufwände klar sind
- Oft Festpreis, Fester Umfang, Liefertermin vereinbart!
- Account Manager/Projektmanager → Softwareentwicklung
- Softwareentwicklung → Testing/QA
- Testing/QA → IT Operations + Support
Fällt Ihnen auf, dass ab Schritt 3 niemand mehr mit dem Kunden spricht?
Sie sehen also, es gibt sehr viele Übergaben – in manchen Kundenprojekten sind hier 10 oder mehr Schritte festgelegt. Durch sprachliche Transformationsprozesse verzerrt dies die ursprüngliche Idee, denn wie bei Muster 1 wird jede Unklarheit mit Annahmen gefüllt. Jedes Teammitglied trifft in jedem Prozessschritt über jede Anforderung Annahmen, die Unschärfe wächst dabei exponentiell (siehe dazu die untenstehende Abbildung, die den Cone of Uncertainty zeigt).
Auch hier wieder die Frage: Wie hoch ist die Wahrscheinlichkeit, dass das fertige Produkt die ursprüngliche Idee umsetzt?
Diese beiden Muster sind natürlich eine vereinfachte Darstellung. In der Praxis treten oft Mischformen dieser beiden Muster auf, doch für alle Ausprägungen gilt: Was kostet es Sie, bereits entwickelte und getestete Features nachträglich zu ändern, weil jemand etwas vergessen hat mitzuteilen?
Fazit
Zweifeln Sie! Fragen Sie aktiv nach! Ist Ihnen klar, welches das Problem ist, das konkret gelöst werden soll? Warum schafft diese User Story einen Mehrwert für den Kunden? Was ist der Kontext?
Deshalb die Referenz zu Kant im Titel – wir nennen dieses Hinterfragen den Kategorischen Konjunktiv: Arbeiten Sie nur mit solchen Anfragen/Stories, die nicht nur als persönliche Gefallen gelten können, sondern zum Beispiel einer Definition of Ready entsprechen.
Wie wäre es, wenn wir gemeinsam lokale Optima durch ein Miteinander ersetzen könnten - um mehr Kapazitäten für die Entwicklung großartiger Produkte zur Verfügung zu haben?
Auf dem Weg helfen Workshops zum Requirements Engineering oder fundierte Kenntnisse im Bereich der agilen Methoden.
Sprechen Sie uns gern an, wenn Sie mehr erfahren möchten!
