Bei holistischer Betrachtung von Projekten geht es darum, das große Ganze im Blick zu haben. Die Bestimmung der Einzelteile ist von der funktionalen Rolle im Ganzen abhängig. Durch eine einfache Frage eines Klienten wurde meine Aufmerksamkeit auf diesen modernen Weg der Software-Entwicklung gelenkt.
Es begann mit den Klagen eines Kunden über ein misslungenes Software Projekt. Mir wurde der Verlauf in allen Einzelheiten geschildert und wir gingen die möglichen Gründe für das Versagen durch. Viele kamen mir bekannt vor und werden in Publikationen zu diesem Thema regelmäßig erwähnt.
Dann wurde ich gefragt, ob es zentrale Zusammenhänge gäbe, die bei Berücksichtigung die Wahrscheinlichkeit für den Erfolg eines Projektes von Beginn an deutlich erhöhen könnten? Das brachte mich ich ins Grübeln. Kann man die Gründe fürs Misslingen einfach umkehren und bekommt dann das Erfolgsrezept? Wohl eher nicht. Obwohl ich selbst auf einige gute Resultate zurück blicken kann und wir Menschen dazu neigen, unsere Erfahrung als Füllhorn allen Wissens zu betrachten, wollte ich nicht mit einer spontanen Antwort herausplatzen. Stattdessen bat ich um Bedenkzeit und versprach Klärung.
Für diese Aufgabe würde ich einen wissenschaftsähnlichen Ansatz benötigen und ich musste auf eine breitere Grundlage aufbauen. Also begab ich mich in viele persönliche Gespräche mit meinen Entwickler-Kollegen. Sie sollten sich in gut gelungene Projekte hineinversetzen und die Zutaten für deren gutes Gelingen nennen. Zusätzlich verlangte ich dann noch eine Priorisierung der einzelnen Argumente. Als Ergänzung wertete ich noch zahlreiche Publikationen zu diesem Thema aus.
Auswertung
Nach Durchsicht bot sich eine übergeordnete Klassifizierung der Gründe nach „außerhalb“ oder „innerhalb“ des Teams an. Die Letzteren wurde weiter aufgeteilt in „Gruppendynamik und Kommunikation“ oder „Skills, Arbeitsplatzbedingungen, Ressourcen und Tools“.
Für sehr ähnliche oder identische Begründungen erzeugte ich in einer Tabelle die Spalte „Häufigkeit“ neben der Spalte „Priorisierung“. Bei mehrere Priorisierungen wurde ein Mittelwert errechnet, der mit der Häufigkeit gewichtet wurde.
Hier einige Beispiele der höher bewerteten Erfolgsfaktoren:
- Wenige, kurze, konstruktive Meetings mit max. 5 Teilnehmern, die weitestgehend mit einem Konsens enden.
- Sauber formulierte Ziele und Erwartungen, die jedes Team-Member auf dieselbe Art interpretieren kann.
- Gute Projektplanung, saubere, gut dokumentierte Analyse- und Design Phase. Saubere, nachvollziehbare Architektur. Richtig eingeschätzte Komplexität.
- Klare „definition of done“. Jeder Entwicklungs-Zyklus sollte mit einem fehlerfreien, ausführbaren Programm für den Kunden enden.
- Gute Kommunikationsstruktur zu allen beteiligten äußeren Strukturen, d.h. vor allem zeitnahe, transparente Mitteilungen an die Stakeholder, besonders bei schlechten Nachrichten.
- Klare Rollenverteilung.
- Kein Einfluss von außen auf die Team-Arbeit.
- Jederzeit ausreichende finanzielle Ausstattung, Ausstattung mit qualifizierten Team-Mitgliedern. Geringer Austausch von Mitgliedern.
Daraus ließ sich eine Profil-Grafik erstellen, bei der die hoch priorisierten Argumente herausstachen.
Hinweis: Die vollständige Analyse in Form einer Excel-Tabelle senden wir auf Wunsch gerne zu.
Vertrauen
Interessanterweise kann man die am höchsten bewerteten Attribute zusammenfassen unter dem Titel „dauerhaft gute Stimmung im Team“. Wenn sich jedes Team Mitglied mit den Projektzielen identifizieren konnte, sich jeder wohl fühlte, entstanden die besten Ergebnisse. Doch die Stimmung war wiederum von vielen Faktoren abhängig. Das wollte ich genau wissen und ging der Sache auf den Grund.
Ein Gewinner war der Begriff „Vertrauen“ in unterschiedlichen Abstufungen. Er wurde in Kombination mit Begriffen ähnlich zu Wertschätzung, Aufrichtigkeit und Transparenz genannt. Daraus konnte ich den nicht ganz unbekannten Zusammenhang ableiten:
Wertschätzung + Aufrichtigkeit + Transparenz => führt zu Vertrauen
- Wertschätzung: positive Bewertung eines anderen Menschen, eng verbunden mit Respekt und Wohlwollen. Attribute wie auf Augenhöhe kommunizieren, Zugewandtheit, Interesse, Aufmerksamkeit und Freundlichkeit
- Aufrichtigkeit: persönliche Integrität. Bedeutet zu seinen Werten und Idealen zu stehen und den eigenen Emotionen und der eigenen, inneren Überzeugung ohne Verstellung in Rede und Handlungen Ausdruck zu geben. (authentisch sein)
- Transparenz: frei zugängliche Informationen und stetige Rechenschaft über Abläufe, Sachverhalte, Vorhaben und Entscheidungsprozesse. Im Speziellen jederzeit sichtbare (gut dokumentierte), belastbare Entscheidungen.
- Vertrauen: Richtigkeit, Wahrheit von Handlungen, Einsichten und Aussagen. Eine Person, der man vertrauen kann sollte gerecht, aufrichtig und loyal sein.
Flow
Ein weiterer hoch bewerteter Begriff war „Motivation“. Als mir der Zusammenhang mit weiteren Begriffen klar wurde kam mir sofort die Selbstbestimmungstheorie von Deci und Ryan in den Sinn. Doch aus meiner Sicht mündet alles in einen Begriff von Mihály Csíkszentmihályi.
Vertrauen + Kompetenz + psychologische Sicherheit + Autonomie => führt zu intrinsischer Motivation => führt zu Flow, um hoch produktiv zu einem exzellenten Ziel zu kommen
- Kompetenz: kognitive Fähigkeiten und Fertigkeiten, um bestimmte Probleme zu lösen, sowie die damit verbundenen motivationalen, volitionalen und sozialen Bereitschaften und Fähigkeiten, um die Problemlösungen in variablen Situationen erfolgreich und verantwortungsvoll nutzen zu können. Einfach ausgedrückt, ein Team-Member muss durch seine Fähigkeiten und Fertigkeiten den Projektaufgaben gewachsen sein.
- Psychologische Sicherheit: Die Stimme des Team-Member muss gehört werden, die Person muss sich integriert fühlen und Wertschätzung erfahren.
- Autonomie: Jeder im Team sollte seine Aufgaben ohne Anleitung und Druck selbstständig erfüllen können, Entscheidungen selbst fällen können.
- Flow: setzt intrinsische Motivation voraus und nachvollziehbare Werte und Ziele des Projektes mit denen sich jedes Team-Member identifizieren kann. (andernfalls sollte das Projekt nicht durchgeführt werden!)
Holistische Erweiterungen
Mit meinen neuen Erkenntnissen bin ich dann wieder zurück zu den Entwicklern und habe mit ihnen darüber diskutiert. Es gab viel Zustimmung aber wir konnten die Sicht auf Software Projekte noch gemeinsam erweitern und haben uns damit weiter in Richtung holistischer Software-Entwicklung bewegt.
Projektbeginn
Die Entwickler waren sich einig, das zu Beginn jedes Projektes vorab folgende Fragen gestellt werden sollten:
- Ist die gewünschte Software wirklich erforderlich? Kann sie evtl. durch organisatorische Änderung in einer übergeordneten Ebene vermieden werden oder in ein übergeordnetes Programm integriert werden?
- Ist der Nutzen, der Wert ausreichend, um die Anstrengungen zu starten?
- Ist die Aufgabe interessant genug, damit sich ausreichend kompetente Entwickler dafür begeistern lassen?
- Welche Folgen hat die Software für das Unternehmen, für die Umwelt, für die Gesellschaft?
Erst wenn die Planung diese Hürden genommen hat, kann mit dem Projekt begonnen werden.
Skills
Es konnte herausgearbeitet werden, welches die wesentlichen Eigenschaften von geeigneten Entwicklern sein sollten:
- Akademische Qualifikation: Softwareanforderungen sind üblicherweise komplex und erfordern gute Skills. Es versteht sich von selbst, dass Erfahrungen mit der angestrebten Entwicklungsumgebung (Tech Stack) vorhanden sein müssen. Zusätzlich wird ein Verständnis für kontinuierlichen Integration und Software-Qualität vorausgesetzt. Es müssen aber keine Top-Performer sein und die Fachgebiete dürfen durchaus vielfältig sein. Interdisziplinäre Teams haben einen größeren Blickwinkel und sind dadurch innovativer.
- Open-Mind, Growth Mind-Set: Unterschiedliche Charaktere wie z.B. intro- oder extrovertiert sind sehr willkommen, sie ergänzen sich häufig. Eine Person, die in der Lage ist “invertiert” zu denken, wäre ebenfalls eine Bereicherung für das Team. Doch geeignete Menschen sollten unbedingt unvoreingenommen sein und über den Tellerrand schauen können. Sie sehen Herausforderungen und keine Probleme. Sie sind bereit zu Lernen, Hilfe anzunehmen und Hilfe zu geben.
Workflow
Der größte Teil der Entwickler scheint mittlerweile agil zu arbeiten. Das bedeutet es wird jeweils nach einem Intervall (2-4 Wochen) ein lauffähiges, stabiles Produkt an den Kunden ausgeliefert, das einen Mehrwert gegenüber der Vorgängerversion hat. Innerhalb dieses Zyklus findet ein Ablauf ähnlich der kontinuierlichen Integration (continuous integration) statt.
- Code: Code-Entwicklung und Code-Review, Werkzeuge zur Versionskontrolle, Zusammenfügen von Code (Merge)
- Build: Werkzeuge zur kontinuierlichen Integration und Erstellung eines „Build Status“
- Test: Statische und dynamische Code-Analysen und Tests,
- Package: Package Manager zum Ausliefern von komprimierten Code-Teilen
- Release: Change Management, Freigabe von Releases
- Configure: „Configuration“ oder „Systems Management“-Werkzeuge
- Monitor: Monitoring von Applikationen, Kunden-Feedback
Mittlerweile hat sich ein hoher Automatisierungsgrad innerhalb der einzelnen Phasen etabliert. Häufig stehen die Unterstützungswerkzeuge einfach als Service (SAAS) bereit.
Es existiert eine große Anzahl von bewerteten Prinzipien zur Softwareerstellung. Mich hatte auch interessiert, welche davon besonders beliebt sind, hier das Ergebnis:
Keep It Simple, Stupid: Klarer, leicht verständlicher Code zur besseren Lesbarkeit.
Separation Of Concerns: Eine Funktion oder Klasse darf nur immer einen Belang, eine Aufgabe haben, sonst können sich Probleme mit der späteren Verwendung einschleichen.
Dependency Inversion Principle: Klassen aus höheren Ebenen sollten nicht von Klassen in niedrigeren Ebenen abhängig sein, sondern beide nur von gemeinsamen Schnittstellen. Schnittstellen sollten wiederum nicht von Details abhängig sein, sondern Details von Schnittstellen.
Komponentenorientierung: Komplexere Strukturen werden zu einer Komponente mit einer gut dokumentierten Komponenten-Schnittstelle zusammengefasst.
Die Aufzeichnungen ergeben noch viele weitere interessante Aspekte, die ich hier später noch ergänzen werde.
Sicher sind die Ausführungen nicht vollständig, deshalb freuen wir uns auf neue Aspekte, Anregungen und Kommentare.
