Die Bereitschaft zu experimentieren

Die grundlegende Voraussetzung, um in einer Organisation erfolgreich agil entwickeln zu können, sehe ich in der Bereitschaft der Stakeholder, zusammen zu experimentieren.
Mit experimentieren meine ich:

  • Hypothesen aufstellen,
  • in kontrolliertem Rahmen etwas ausprobieren,
  • Hypothesen überprüfen,
  • aus dem Ergebnis Schlüsse ziehen.

Übertragen auf die Produktentwicklung heißt dies unter anderem, folgende Hypothesen zu überprüfen und daraus während der laufenden Entwicklung Schlüsse zu ziehen:

  1. Ob das, was man sich vorgenommen hat, auch unter gegebenen Voraussetzungen entwickelt werden kann (Scope).
  2. Ob man wirklich das entwickelt, was die Stakeholder haben wollen (Validierung).
  3. Ob man die Art und Weise verbessern kann, wie entwickelt wird (Vorgehen).

Experimente in Scrum

Agile Frameworks wie Scrum können bei der Überprüfung der Hypothesen behilflich sein:

  1. Im Sprint Review Meeting, am Ende einer Entwicklung von maximal einem Monat,
    werden die Entwicklungsergebnisse mit der Planung verglichen (Scope).
  2. In diesem Meeting werden auch Stakeholder eingeladen, die
    Entwicklungsergebnisse werden präsentiert und besprochen (Validierung).
  3. Im Sprint Retrospective Meeting wird die Art und Weise der Entwicklung hinterfragt (Vorgehen).

Jedes Daily Scrum ist ein weiterer Prüfpunkt. Der kontrollierte Rahmen dieses „Inspect & Adapt“ genannten Verfahrens ist der kurze Entwicklungszyklus, der das Risiko von Fehlentwicklungen auf einen Monat oder weniger begrenzt, bevor diese offensichtlich werden. Fundiert ist Scrum im Empirical Process Control Model, das im Gegensatz zu definierten Prozessen nicht auf Wiederholbarkeit und Vorhersehbarkeit ausgelegt ist.

Aus den Ergebnissen der Überprüfung können dann schon während der Entwicklung Schlüsse gezogen werden:

  • Der Scope wird neu verhandelt, d.h. Backlog Items werden neu priorisiert.
  • Die Wünsche der Stakeholder, die sich auch während der Entwicklung ändern können, werden berücksichtigt.
  • Es werden Maßnahmen getroffen, um das Vorgehen zu verbessern.

Experimente als Erfolgsmodell

Die Naturwissenschaft macht seit Jahrhunderten vor, welche unglaublichen geistigen und kulturellen Fortschritte man mit Hilfe von Experimenten machen kann. Im Vergleich dazu stecken die agilen Vorgehensweisen von heute noch in den Kinderschuhen – aber auch wenn nicht immer methodische Strenge herrscht und harte Kriterien geprüft werden, kann man mit Experimenten beeindruckende Ergebnisse erzielen.

Experimentierunlust als Erfolgsmodell der Fertigung

Die 3 Aspekte – Scope, Validierung und Vorgehen – spielen natürlich auch in der
nicht-agilen Entwicklung eine Rolle, allerdings werden sie häufig nicht als Hypothesen behandelt, sondern als Gegebenheiten: der Scope und das Vorgehen gelten als fix,
und die Stakeholder werden schon das haben wollen, was man entwickelt.

Was also der nicht-agilen Entwicklung oft fehlt ist die Bereitschaft zu experimentieren. Dieser Mangel an Experimentierfreude war lange Zeit ein wirtschaftliches Erfolgsmodell, umgesetzt in der industriellen Fertigung in Fabriken, und wurde zunächst in die nicht-agile Entwicklung von Software übernommen.

Ziel der industriellen Fertigung in Fabriken ist es, Herstellungsprozesse zu standardisieren und durch Automatisierung oder möglichst geistlose, repetetive Tätigkeiten (zum Beispiel am Fließband) von einzelnen Menschen effizient und ohne Abweichung vom Plan durchführen zu lassen. Das spart Kosten und sorgt – bei gleichbleibender Qualität der Einzelteile – für eine gleichbleibende Qualität der Produkte.

Die neue Welt und die Konsequenzen

Für die Produkte, die heute am Markt gefragt sind, existiert oft kein standardisiertes Herstellungsverfahren, und die Prinzipien der Fertigung lassen sich daher schlecht übertragen. Es ist Zusammenarbeit in der Lösungsfindung erforderlich, und wenn man miteinander und nicht gegeneinander arbeiten will, ist die beste Basis dafür Vertrauen.

Anders und zugespitzt gesagt: ein einzelner guter Gedanke kann für den Erfolg eines Projektes maßgeblicher sein als monatelange Arbeit, und gute Gedanken zu haben kann das Management weder sich selbst noch anderen verordnen. Ob ein Gedanke gut war, erweist sich erst nach einer Weile.

In einem solchen Entwicklungsumfeld sind Änderungen und Kurskorrekturen die Regel, nicht die Ausnahme.

Change Requests sind (vielleicht) auch keine Lösung

Wenn in einer nicht-agilen Organisation ein Prozess für Änderungsmanagement (z.B. über Change Requests) etabliert ist, gibt es zwar prinzipiell die Möglichkeit, mit unvorhergesehenen Situationen umzugehen, allerdings werden Änderungen oft trotzdem als Anomalie, nicht als Normalität behandelt. Das spiegelt sich zum Beispiel in Festpreisverträgen wieder, in denen Scope und Bezahlung fixiert sind.

Als Konsequenz ist meiner Erfahrung nach mindestens einer der Verlierer: der Auftraggeber, der verschobene Releases oder Produkte mit reduzierter Qualität in Kauf nehmen muss, oder die entwickelnde Organisation, die erhöhte Kosten in der Entwicklung tragen muss. Nicht umsonst heißt es daher im agilen Manifest:

„We have come to value [..] Customer Collaboration over Contract Negotiation“

Sind Sie selbst in einer Organisation, die agil werden will, und brauchen Sie Unterstützung ? Dann kontaktieren Sie uns.
Series Navigation<< Warum überhaupt agiler werden ?Verinnerlichung >>