Der goldene Mittelweg im ALM

Eine Analyse

Was ich in den letzten Jahren persönlich erlebt habe und was man darüber hinaus in der Geschichte der Softwareentwicklung immer wieder beobachtet, ist die „Flucht ins Extreme“. Damit meine ich, dass immer wieder gerne versucht wird, entweder schwarz oder weiß zu sein. An dieser Stelle will ich darauf hinweisen, dass es für solche Extreme durchaus notwendige Anwendungsfälle gibt. Aber die Erfahrung zeigt, ein Optimum vieler Entwicklungsprojekte wird mit dem goldenen Mittelweg erreicht.

Sehen wir uns beispielsweise mal Vorgehensmodelle in der Softwareentwicklung an. Da ist aus meiner Sicht ein Extrem, die Umsetzung des Wasserfallmodells in den Entwicklungsprojekten. Der Gegenpol ist die Anwendung von Scrum als agiles Vorgehensmodell. Damit man das Schwarze und das Weiße besser erkennt, ignorieren wir die, in vielen Aspekten (Scope, Terminologien, Methoden) sehr unterschiedlich gestalteten Vorgehensmodelle. Vielmehr ist die Anwendung der Grundideen (Konstruktionsprinzipien) relevant, welche sich hinter den Vorgehensmodellen verbergen.

(a)  Ein Konstruktionsprinzip im Wasserfallmodell ist, dass erst ein vollständiger „freigegebener“ Input vorhanden sein muss, bevor eine weitere wertschöpfende Bearbeitung erfolgt. Eine sehr vereinfachtes Beispiel soll dieses Prinzip veranschaulichen: Zuerst müssen alle Anforderungen vollständig spezifiziert sein, bevor das System und das Systemdesign beschrieben werden kann. Erst wenn das System und das Systemdesign vollständig spezifiziert sind, werden die Komponenten implementiert usw. [http://de.wikipedia.org/wiki/Wasserfallmodell#Probleme_und_Nachteile]

(b)  Ein Konstruktionsprinzip im Scrum ist, dass nur die Inhalte detailliert beschrieben werden, die zuverlässig planbar geliefert werden können. Ein sehr vereinfachtes Beispiel soll dieses Prinzip veranschaulichen: Es werden nur die Inhalte konkretisiert und definiert, die nach den folgenden 10 bis 20 Tagen (Sprint) geliefert werden können. [http://de.wikipedia.org/wiki/Scrum#Product_Backlog]

Das Extrem entsteht nun durch die Anwendung dieser Prinzipien. In Beispiel (a) erleben wir häufig, dass sich Menschen zurückziehen, wenig kommunizieren, ein Sicherheitsdenken entwickeln – erst wenn ich etwas als vollständig freigebe, stehe ich dazu oder nur wenn etwas vollständig geliefert wurde, fange ich an damit zu arbeiten. Es entwickeln sich Mauern in den Köpfen der Menschen, über diese dann Ergebnisse geworfen werden. Was das für die meisten Entwicklungsprojekte für Folgen hat, ist im Chaos Report von 1995, der Standish Group, gut zu sehen. [http://www.projectsmart.co.uk/docs/chaos-report.pdf]

In Beispiel (b) erleben wir aktuell, dass Menschen viel kommunizieren, wenig dokumentieren, die schwierigen Themen wie Architektur und Systemtests leicht ausgeblendet werden, schnell neue Begriffe ohne semantisches Verständnis eingeführt werden und Organisationen Schwierigkeiten haben mit ihren Entwicklungsprojekten Erwartungen und Budgets für die nächsten Quartale und Geschäftsjahre festzulegen. Was das für die meisten Entwicklungsprojekte für Folgen hat, ist in der aktuellen Studie „Softwaretest in der Praxis“ zu sehen. [http://www.softwaretest-umfrage.de/]

Warum wir Menschen dazu neigen Schwarz und Weiß zu denken, und letztlich damit unser Handeln bestimmen, liegt auch an dem Bedürfnis nach einem positiven Selbstbild und dem Bedürfnis nach einem realistischen Weltbild. [http://de.wikipedia.org/wiki/Denken#Sozialpsychologie]

Um diesen Bedürfnissen nachzukommen, versuchen wir unter anderem:

1. Widersprüche zwischen Verhalten und Einstellung herunterzuspielen
2. Unser Verhalten als erzwungen darzustellen
3. Unser Unwohlsein auf andere Ursachen zurückzuführen

[http://de.wikipedia.org/wiki/Kognitive_Dissonanz#Dissonanzaufl.C3.B6sung].

Dadurch werden die persönlichen Bedürfnisse befriedigt und wir finden unser seelisches Gleichgewicht. Die durch diese sozialpsychologischen Prozesse beeinflussten Arbeitsergebnisse in der Softwareentwicklung widersprechen aber oft den Arbeitsergebnissen, die durch die Konstruktionsprinzipien der benannten Vorgehensmodelle beabsichtigt sind. Deshalb fällt es uns so schwer eben den goldenen Mittelweg zu finden und auf ihm zu gehen.

Eine Lösung

Was also tun? Wir brauchen also Konstruktionsprinzipien für Vorgehensmodelle, die auf solche sozialpsychologische Prozesse Rücksicht nehmen. Prinzipien, die bei den Menschen wenige Widersprüche zwischen Verhalten und Einstellung auslösen, die die soziale Integrität der Mitarbeiter weitgehend erhalten und die dennoch eine höhere Qualität der Arbeitsergebnisse ermöglichen. Ein auf solchen Prinzipien basierendes Vorgehensmodell sind die „Value-oriented Practices“.
[http://www.sigs.de/publications/newsletter/2010/10/donig_kuenzle_OS_06_10_m_pw.pdf]

Es werden bei diesem Vorgehen die fachlichen Ergebnisse und deren Reifestufen in den Mittelpunkt gestellt. Vorgaben für beispielsweise anzuwendende Arbeitsweisen, Methoden, Rollen, Aufbau der Entwicklungsorganisation etc. sind sekundär und werden in passenden Practices optional referenziert. Dadurch werden kognitive Dissonanzen bei den Menschen reduziert bis vermieden.

Ein Erfolgsfaktor und Konstruktionsprinzip der „Value-oriented Practices“ sind die essentiellen Reifestufen der Engineering-Ergebnisse (Artefakte), die in einem Lebenszyklusmodell (Lifecycles) modelliert sind. Damit werden die Reifestufen beschrieben, die eine Wertschöpfung erfordern und damit eine detaillierte Beschreibung des Artefaktes sind. Eine Reifestufe definiert sich aus der Wertschöpfung, die am Artefakt erreicht wird. Es werden damit nur wertschöpfungsrelevante Reifestufen beschrieben. Reifestufen, in denen beispielsweise formale Kriterien wie ein Qualitäts-Audit und/oder eine Freigabe erreicht werden, sind nicht essentiell für die Wertschöpfung, die hier schon im Voraus erfolgt ist. Eine Bibliothek von „Value-oriented Practices“ – Anwender nutzen passende Prozessbausteine nach ihren Bedürfnissen.

Mit den Value-oriented Practices konnten wir in der Vergangenheit viele gute Erfahrungen sammeln. Vor allem mit der Semantik, die hinter dem Konzept der Reifestufen steht, wurde ein schnelles Verständnis mit verschiedenen Rollen-Vertretern erreicht. Die Diskussionen hatten fast immer ein sachliches und konstruktives Niveau. Die Erwartungen an die Ergebnisqualität ist durch dieses Konzept nachvollziehbar.

Gleichzeitig lassen sich die Lebenszyklen der Artefakte gleichermaßen auf unterschiedliche Vorgehensmodelle und Rahmenbedingungen für die Produktentwicklung übertragen. Damit entsteht kein Zwang die bisherigen Paradigmen revolutionär zu wechseln – wie es bei Scrum-Einführungen in einigen Bereichen (etablieren von Product Owner und Scrum Master) oft notwendig ist.

Die Value-oriented Practices machen eine Veränderung in kleinen Schritten möglich. Sie lassen den Menschen genügend Raum, ihr Bedürfnis nach einem positiven Selbstbild und dem Bedürfnis nach einem realistischen Weltbild langsam an die neuen Herausforderungen anzupassen. Damit wird meist ein goldener Mittelweg gefunden.

Jens Donig

Kontaktieren Sie Jens Donig

Jens Donig ist systemischer Coach (dvct) und Principal Consultant für Software- und Systems- Engineering. Die Schwerpunkte seiner Coaching- und Beratungstätigkeit liegen in den Bereichen Organisationsentwicklung, Teamentwicklung und der persönlichen Entwicklung seiner Kunden. Seit mehreren Jahren beschäftigt er sich mich intensiv mit der nachhaltigen Verankerung von Veränderungsprozessen in Organisationen verschiedener Branchen. Auf Basis des systemischen Coachings, von Transformationsprozessen und agiler Werte und Prinzipien, begleitet er seine Kunden erfolgreich auf ihrem persönlichen Weg der Weiterentwicklung und Veränderung.