Unleash the creative human power

Kategorie: agile Entwicklung

Milestones sind Gift!

Nach all den wissenschaftlichen Erkenntnissen und der schon lange anhaltenden Modewelle der Agilität gibt es immer noch Unternehmen, die komplexe Aufgaben auf akademischem Niveau mit Milestones oder Meilensteinen versehen.

agile Arbeitsweise

Mit einem Milestone wird ein Projektverlauf in vorher festgelegte, überprüfbare Teilziele aufgeteilt. Das bedeutet die gesamte Aufgabe muss vor Beginn genauestens geplant werden. So eine Planung würde einen Spezialisten mit tiefem Wissen über die Aufgabe und ihrer Rahmenbedingungen voraussetzen. Er müsste aber auch hochqualifiziert in der Technologie der Umsetzung sein. Jeder kleineste Schritt müsste vorhergesehen und geplant werden. Außerdem müsste er vorausahnen, wie der Auftraggeber seine Wünsche genau umgesetzt haben möchte. Es gibt nur sehr selten solche hoch kompetenten Mitarbeiter. Aber auch dann würde er idealerweise seine Planung an eine Maschine übergeben, die die einzelnen Entwicklungsstufen motorisch umsetzt.

Die Übertragung von determinierten Aufgaben an ein Team von intelligenten Menschen ist in der Vergangenheit üblicherweise gescheitert. Selbst bei einfachen Tätigkeiten ist man davon abgekommen, manche erinnern sich noch an den Begriff „Taylorismus“.

Motivation

Menschen entwickeln eine Eigendynamik und die ideale Vorgehensweise prägt sich erst im Verlauf der Produktentstehung heraus. Aus den vielen Forschungen wurde als bestes Arbeitsumfeld für geistige Tätigkeiten die eine hohe Kompetenz voraussetzen „soziale Eingebundenheit/Sicherheit“ und „Autonomie“ herausgearbeitet (z.B. Selbstbestimmungstheorie). Es entsteht Motivation und damit verbessert sich die Arbeitsqualität deutlich. Autonomie ist die freie Gestaltungsmöglichkeit von Zeit, Ort und Ressourcen.

Bei Vorgaben durch Milestones versucht das Team sie nur noch abzuarbeiten, unabhängig davon, ob dadurch die Qualität leidet oder die Aufgabe auf diesem Weg gar nicht zu lösen ist. Zwei Drittel der Projekt sind in den 90zigern Jahren daran gescheitert.

devops

Mir gefällt der Begriff agil nicht, weil er mittlerweile mit vielen falschen Vorstellungen verbunden ist. Es wäre besser es als „normal“ oder „menschengerecht“ zu bezeichnen.

Vertrauen

Als seinerzeit die IT als Erste die Umstellung von Wasserfallprojekten zu agiler Arbeitsweise vollzog, hatten die Auftraggeber zunächst Bedenken bezüglich der Qualität, Investitionssicherheit und Kostenkontrolle.

Das Geheimnis aber lag in dem Vertrauen, das durch autonome Arbeit aufgebaut werden konnte und das Konzept der zyklischen Arbeit. Nach jedem Intervall (zw. 2 u. 4 Wo.) kann der Auftraggeber den aktuellen Stand seines Produktes begutachten und bekommt eine lauffähig Fassung des aktuellen Programmstandes. So kann er unmittelbar die weitere Entwicklung beeinflussen oder wenn ihm der Fortschritt nicht ausreicht das Projekt auch jederzeit stoppen.

Auf der anderen Seite kann ein Team die notwendigen Ressourcen, Ort und Zeit frei auswählen, dadurch den effektivsten Weg einschlagen und bekommt in kurzen Abständen ein Feedback vom Kunden. Bei einer positiven Rückmeldungen wird das Selbstwertgefühl jedes Einzelnen gestärkt. Die bisherigen Methoden sind zwar noch nicht perfekt, haben aber die Erfolgsquote um ein Drittel erhöht und die Ergebnisqualitäten sind deutlich gestiegen.

Es bleibt noch zu erwähnen, dass die Änderung der Arbeitsbedingungen für komplexe geistige Arbeit auch die Umstellung von Werk- zu Dienstverträgen für freiberufliche, geistige Tätigkeiten zur Folge hatte.

SCRUM ist nicht agil!

Es begann mit einer guten Idee Anfang der neunziger Jahren des letzten Jahrhunderts. Der herkömmliche Software-Entwicklungsprozess erwies sich als wenig effektiv. Neue flexiblere (agil) Methoden versprachen da Abhilfe. Deshalb erschuf man unterschiedliche Lernwerkzeuge, mit denen klassisch arbeitende Teams in kleinen Schritten zu hoch produktiven, selbst organisierten Gruppen transformiert werden sollten. Wie schon in vielen anderen Kontexten, wurden einige dieser Verfahrensweisen im Lauf der Zeit in eine Art Dogma überführt. Damit konnte mit Schulungen und Zertifizierungen viel Geld verdient werden. In Deutschland hat sich vor allem SCRUM durchgesetzt.

devops

Entstehung

Dieses agile Framework entstand in einer Zeit, in der das Wissensmanagement in japanischen Universitäten entwickelt wurde. Zu den Produktionsfaktoren KapitalArbeit und Material kam Wissen (innerhalb des Unternehmens) hinzu.

In japanischen Fabriken zeigte sich, dass dort wo mit explizitem, menschlichem Wissen gearbeitet wurde, ein hohes Optimierungs- oder Automatisierungspotential bestand. Deshalb bemühte man sich, explizites Wissen in Prozessdokumentationen festzuhalten. Implizites Wissen dagegen verlangte nach mehr Selbstorganisation. Eine konsequente, zeitgemäße Umsetzung fand im Toyota Production System (TPS) statt. Weltweit wurde versucht, es zu kopieren. Selbstorganisation bekam zum ersten Mal einen Stellenwert.

Der Begriff „Wissen“ wurde unterteilt in „explizit“ (kann beschrieben und in Dokumenten oder Datenbanken festgehalten werden) und „implizit“ (nicht speicherfähig, hoch komplexes Expertenwissen mit geringer Gültigkeitsdauer).

Etwas zur selben Zeit schaute man bewundernd auf die Erfolge einiger jungen, hoch qualifizierten Teams, die scheinbar ohne formales Vorgehen in kurzer Zeit qualitativ hochwertige Software lieferten. Dem Kunden lieferte das Team frühzeitig ein nutzbares Produkt, das nach kurzen Zeitintervallen weitere nützliche Funktionen hinzugefügt bekam. Der Kunde konnte so den Gegenwert seiner Investition ständig wachsen sehen. Diese Arbeitsform wurde bekannt als „extreme programming“ (XP).

Die Entwickler dieser Methodik hatten erkannt, dass Software-Entwicklung ein Team mit spezialisiertem „impliziten“ Expertenwissen voraussetzt. Teamarbeit, Offenheit und stete Kommunikation zwischen allen Beteiligten rückte in den Vordergrund.

Die bekanntesten Software-Experten ihrer Zeit bekannten sich auf einem Zusammentreffen zu einer gemeinsamen Veröffentlichung von Richtlinien zu diesem Thema. Es entstand das „Agile Manifesto“, dass Formalismus durch Kommunikation und Selbstorganisation ersetzen sollte.  

Zwei der Unterzeichner des Manifests entwickelten dann mit der Methode SCRUM das heute bekannte, pragmatisches Framework, das Teams zu Selbstorganisation hinführen sollte. Dazu adaptierten sie die Zyklen aus XP und nannten sie SPRINT. Das SCRUM-Product-Backlog ist die Zusammenfassung der User-Stories aus XP. Zur Visualisierung der Aufgaben während des SPRINT wurden Elemente aus dem KANBAN-Board (Lean-Management, TPS) weiterentwickelt.

Agil

Die höchste Produktivität, Zufriedenheit und Agilität erreicht ein Team, wenn die Mitglieder einen mentalen Zustandes völliger Vertiefung (Konzentration) und restlosen Aufgehens in ihrer Tätigkeit (Absorption) erreichen. Man nennt diesen Schaffensrausch „Flow“ (Mihály Csíkszentmihályi).

agile person

In diesem Zustand erreicht ein Mensch ein Maximum an Kreativität, Problemlöseverhalten und Durchhaltevermögen. Er braucht dafür keine zusätzliche Energie aufzuwenden, fühlt sich wohl und stressfrei.

Um das zu erreichen, muss ein Mensch hoch „motiviert“ sein. Die Motivation hängt zunächst davon ab, ob man sich mit dem gemeinsamen Ziel identifizieren kann. Dann müssen die drei psychologischen Grundbedürfnisse nach Kompetenz (Wissen, Fähigkeiten), sozialer Eingebundenheit (anerkannte Stimme im Team) und Autonomie (selbstbestimmt bei Art der Arbeit, gewähltem Ort, Umgebung und Zeit) befriedigt worden sein (Selbstbestimmungstheorie von Deci/Ryan).

Die heutigen innovativen Projekte bzw. Produkte sind aufgrund ihrer Komplexität und der schnellen technologischen Entwicklung grundsätzlich nicht mehr mit einer rationalen Struktur beherrschbar. Deshalb wird es zunehmend erforderlich auf das Konzept der „spontanen Ordnung“ (Friedrich August von Hayek) zu setzen:

Wenn sich kompetente Menschen, die in gegenseitiger Wertschätzung miteinander verbunden sind mit einem gegebenen Projekt-Ziel, -Zweck identifizieren können, finden sie autonom Wege iterativ zu einem strukturierten Projekterfolg zu kommen (evolutionäres Management).

Wieviel SCRUM braucht der Mensch?

Wenn „Agilität“ ein hohes Maß an Autonomie und Selbstorganisation voraussetzt, dann bedeutet jede Art von vorgegebener Rahmenbedingungen (z.B. SCRUM) eine Einschränkung der Eigenständigkeit der Gruppe. Auf Dauer werden dadurch hochwertige Entwicklungspotentiale unterdrückt.

Um produktiv in einem selbst organisierten Team agil zu arbeiten und seine Team-Member wertschätzen zu können, ist die Mentalität „aufgeschlossen“ oder „open minded“ erforderlich. Es beschreibt die Eigenschaft, gerne etwas neues Lernen zu wollen, „wissbegierig“ zu sein, bereit sein mental zu wachsen, neue Blickwinkel einnehmen zu können und andere Ansichten zu respektieren. Nicht zu verwechseln mit „extrovertiert“.

agile human

Menschen aus organisatorisch geführten Arbeitsverhältnissen haben diese Eigenschaft häufig verlernt und benötigen deshalb ein Guiding in Richtung „open mind“ und zu autonomen Verhalten.

Für diese Aufgabe und zur Überführung in die Selbstorganisation sind die Frameworks durchaus ein probates Hilfsmittel. Für eine Weile kann es deshalb durchaus Sinn machen, das ein versierter SCRUM-Master die Gruppe trainiert. Bei falscher Anwendung besteht die Gefahr, dass einfach nur eine alte Struktur ersetzt wird mit dem neuen Framework. Damit werden die Vorteile agilen Arbeitens verschenkt. Sobald sich die Selbstorganisation beginnt einzustellen, sollte es der Gruppe überlassen werden, wie sie sich organisieren möchte. Das bedeutet angelehnt an SCRUM, Rollen wie Product-Owner oder SCRUM-Master sollten an eine Person innerhalb des Teams vergeben werden. Das Team vergibt diese Rollen möglichst demokratisch und iterativ.

Ob jemand ein guter Integrator ist, hängt sicher nicht von einer Zertifizierung ab. Alle notwendigen Dokumentationen für Arbeiten mit SCRUM, sei es als SCRUM-Master oder Product-Owner, kann man kostenlos nachlesen auf deren Website.

Ein guter Mentor, Moderator, Coach, Manager schafft Vertrauen. Das erreicht er durch Wertschätzung, Aufrichtigkeit, Transparenz und der Bereitschaft, sich in den Dienst seiner Gruppe zu stellen und deren Entscheidungen zu akzeptieren. Man könnte auch sagen er ist eine freundliche, authentische Person. Es erübrigt sich zu erwähnen, dass dazu ein gewisses Intellekt notwendig ist.

Kreativitätsmethoden?

Pencil_team

In der Literatur findet man unzählige Kreativitätstechniken die als Heilsbringer zur Förderung von Innovationen beworben werden.

In den vergangenen Jahren habe ich den Einsatz dieser klassischen Methoden zurück gefahren, weil sich die Rahmenbedingungen von Innovations-Projekten verändert haben.

Man kann davon ausgehen, dass gute Ideen selten spontan entstehen, sondern sich erst entwickeln müssen. Damit Zielvorgaben schöpferisch oder gestalterisch erreicht werden können, ist eine Gruppe von offen denkenden Menschen mit Begabungen, Wissen und Fertigkeiten, idealerweise mit unterschiedlichen Spezialisierungen oder Fachgebieten, erforderlich.

In einem agilen Innovations-Team entsteht genügend Kreativität sowohl zur Ideenfindung als auch zur Strukturierung und Bewertung ihrer Lösungsalternativen.

Um die Wichtigkeit des Teams gegenüber den Kreativitätsmethoden aufzuzeigen, benutze ich eine sehr grobe Beschreibung des Innovations-Entstehungsprozess.

Teambildung

Hat man den Auswahlprozess der Mitarbeiter erfolgreich gemeistert gilt es intrinsische Motivation aufzubauen.

In meinem Projekt-Initiierungs-Workshop trifft das Team zum ersten Mal aufeinander. Bevor wir uns gegenseitig vorstellen wird kurz der Zielkorridor vorgestellt. Die Ziele sind natürlich vorher mit dem Auftraggeber abgestimmt und dokumentiert worden.

Anschließend begeben wir uns in die Natur und laufen ohne elektronische Geräte durch einen Park, Wald, an einem See entlang oder über Felder. Solange es sich gut unterhalten lässt, ist die Laufgeschwindigkeit angemessen. Zu langsames Laufen, Stehen oder Sitzen reduziert die Sauerstoffaufnahme. Geht man zu schnell, geht zu viel Energie für die Bewegung verloren (siehe Kahneman’s Anekdote über das Laufen über den Weinberg mit Twersky in „Think fast, think slow“). 

Jeder Teilnehmer bekommt die Aufgabe, sich die Namen der Anderen zu merken und etwas voneinander zu erfahren. Ein oder zwei Stunden wird auf diese Art unbeschwert über beliebige Themen miteinander diskutiert.

Im Anschluss daran teilen wir uns aufgrund der Tischsituation in einem Café oder Restaurant in kleine Gruppen auf. Die Diskussionen gehen bei einer Erfrischung oder Imbiss weiter.

Analyse

Nach einer Pause begeben wir uns wieder in das Meeting und bilden Gruppen, meist finden die Personen der Tische im Café wieder zusammen. Sie beschäftigen sich dann zum ersten Mal analytisch mit der Problemstellung und der gegebenen Zieldefinition.

Wenn wir uns dann zum Austausch über die bisherigen Erkenntnisse zusammen setzen, hat sich bereits ein kleiner Team-Spirit gebildet. Die Team-Member beginnen langsam, sich intrinsisch für das Projekt zu motivieren.

In seltenen Fällen kann kaum jemand für die Ziele begeistern. Selbstverständlich ist es dann die Aufgabe des Innovations-Managers, neue Ziele mit dem Auftraggeber abzustimmen oder nötigenfalls das Projekt abzubrechen. Hier gilt wie gehabt: Projekte, für die sich keiner motivieren kann, gehören automatisiert oder verworfen!

Kreativphase

Creative tree

Im nächsten Schritt gilt es, das Team von der intrinsischen Motivation in den Flow zu bringen. Das benötigt etwas Zeit, aber entwickelt sich kontinuierlich. Das Team entscheidet die Auswahl der Umgebung, in der sich getroffen wird. In unregelmäßigen Abständen laufen wir aber auch wieder gemeinsam durch die Natur.

Wenn sich der Manager als agiler Coach versteht, entwickelt das Team selbstständig Struktur und Methodik, sich dem Ziel zu nähern. Meiner Erfahrung nach gilt: je freier das Team, desto kreativer die Ergebnisse. Obwohl ich oft verschiedene Kreativitätstechniken vorgestellt und angeboten habe, scheint es effektiver zu sein, dass sie das Team aus der Problemstellung eigenständig entwickelt.

Diese Phase findet iterativ statt, nach fest gelegten Zeiträumen bewerten wir die aktuellen Lösungsalternativen und erweitern oder verfeinern sie in der nächsten Runde. Wenn die Mehrheit keine neuen Alternativen mehr finden möchte, dann gehen wir in die Selektionsphase über.

Selektionsphase

In dieser Phase bedienen sich Teams gerne den gängigen Entscheidungswerkzeugen. Zur Strukturierung der Lösungen wird häufig der Entscheidungsbaum oder die Entscheidungs-Mindmap ausgewählt.

Sind genügend Alternativen herausgefallen, dann wird gerne die Entscheidungs-Matrix bemüht. Die letzten Lösungswege werden gegeneinander bewertet und mit Hilfe einer Sensitivitäts-Analyse verfestigt. Am Ende sollten ein oder zwei Lösungen herausgearbeitet sein, daraus werden dann Prototypen entwickelt.

Nach Fertigstellung der Vorprodukte werden sie wieder gegeneinander bewertet und dem Auftraggeber präsentiert.

Wenn ein geschätztes Team durch stimulierende Umgebungen in eine gute Stimmung versetzt wurde und sich für die Zielsetzung motivieren kann, entsteht genügend Kreativität sowohl zur Ideenfindung als auch zur Strukturierung und Bewertung ihrer Lösungsalternativen. Der Innovations-Manager hat die Aufgaben das Team zusammenzubringen, Probleme die den Prozess behindern aus dem Weg zu räumen und bei Team-Nachfrage Hilfestellung zu geben.

Software-Entwicklung ist ein Innovationsprozess

Software-Entwicklung ist ein Innovationsprozess

Vor einer Weile wurde ich zu einer Entwicklung hinzugezogen, bei der eine ältere Software für eine Maschinensteuerung durch eine moderne abgelöst werden sollte. Das Team befand sich in einem Disput über die einzusetzenden Technologien, die sogenannte Tool-Chain. Um die Sache voran zu bringen, hoffte das Management mit Hilfe eines externen Experten die Richtung vorgeben zu können. Doch Software-Entwicklung ist ein Innovationsprozess,  das hatte man nicht richtig verstanden. 

Bei agilen, selbst organisierten Teams gilt es einen Eingriff von außen wenn möglich zu vermeiden, deshalb erklärte ich mich nur zur Rolle eines Moderators bereit.

Auch die Ablösung von Software entspricht einem Innovationsprozess.  Software die ohne eine Grunderneuerung oder ohne weiteren Nutzen durch andere Werkzeuge ersetzt wird, ist verbranntes Geld!

Wie sehr Innovationsprozesse und Software-Entwicklung miteinander verbunden sind, wurde bei diesem Projekt besonders deutlich.

Wer ist der Kunde?

Zu Beginn des ersten Meetings konnte die Frage, wer der Kunde der Software sei, nicht eindeutig beantwortet werden. Es fielen die Namen von unterschiedlichen Personengruppen aus dem Bereich der Stakeholder. Bei der anschließenden Diskussion blieben zwei Kunden übrig. Der Hersteller der Maschine, der auch der Auftraggeber der Software war und der Käufer der Maschine mit seinem Bedienpersonal. Bei modernen Innovationsprozessen sollte der endgültige Anwender als Kunde betrachtet werden, nie die zwischen geschalteten Auftraggeber. Ein Innovations-Team muss im Zweifelsfall Funktionalität im Sinne des Anwenders gegen den Auftraggeber verteidigen können.

Der Besteller eines Erzeugnisses denkt häufig in Kostengrenzen, Innovationen sollten aber in erster Linie der Kundenzufriedenheit und Produktivität während der Nutzung des Produktes dienen!

Grund und Zweck des Produktes

Weil alle ihren Laptop dabei hatten, bat ich jeden im Team eine kurze Zusammenfassung von dem zu entwickelnden Produkt zu machen und mir auf den vereinbarten Messanger zu senden. Interessanterweise gingen die Vorstellungen auch hier weit auseinander.

An dieser Stelle der Entwicklung ist es wichtig, dass sich jeder Beteiligte vollständig in die Rolle des späteren Anwenders hinein versetzen kann. Wir haben uns in diesem Fall zu einem Kunden an eine ältere Maschine begeben und uns intensiv mit dem Bedienpersonal ausgetauscht. Dabei kam so ganz nebenbei heraus, dass die Maschine in Zukunft ein Kandidat für ein Edge-Computing war, weil eine Kommunikation mit anderen Maschinen und eine Remoteüberwachung notwendig werden würde.

Die Analyse des Problembereiches ist sowohl aus der Vogelperspektive als auch bis ins kleinste Detail notwendig. Das zu entwickelnde Produkt sollte zunächst nur als eine Liste von Anforderungen definiert werden. War der Bedarf schon vor zehn Jahren vorhanden und ist vielleicht auch noch in zehn Jahren interessant, dann lohnt es sich die Anforderung aufzunehmen. Keine Zeit verschwenden mit „nice to have“ Funktionen.

Anforderungen strukturieren

Mit diesen neuen Erfahrungen und der Kenntnisse über den genauen Zweck des Produktes konnte das Team eine Struktur mit den notwendigen Produktfunktionen aufbauen und diskutieren. Nach vielen Änderungen und Ergänzungen fand sie schließlich eine breite Zustimmung. Dadurch war eine rudimentäre Dokumentation über das finale Produkt entstanden und das Team hatte so etwas wie eine Guideline.

Auf dieser Basis ließ sich eine zu entwickelnde Software gut in granulare Funktionalitäten modularisieren und wichtige Zusammenhänge konnten isoliert werden. Es entstand eine technologisch und ökonomisch gut bewertbare Grundlage für die Auswahl von Frameworks und Tools sowie ein späteres Burn-down-Sheet. Das lief alles nicht nach einem determinierten Konzept ab, denn Software-Entwicklung ist ein Innovationsprozess!

Tools und Methodik

Entwicklungs-Team werden mittlerweile weitestgehend nach technologischen Fertigkeiten ausgewählt, nicht mehr bezogen auf die Aufgabe, Domänen-Knowhow, Innovationsfähigkeit, Diversifikation usw. Dadurch wird die Entstehung von außergewöhnlicher, kreativer Software in vielen Bereichen unterdrückt und die Entwicklung degeneriert zu Fließbandarbeitern. Damit kann sich keiner identifizieren und es kann kein „Flow“ im Team entstehen.

Die Festlegung von Entwicklungsumgebungen und Tools noch bevor ein Team zusammengestellt oder das Produkt richtig bekannt ist, verletzt die Prinzipien agiler, selbst organisierter Arbeitsweise. Eine falsche Entscheidung zu diesem Zeitpunkt kann unnötig viel Ressourcen binden, die Fertigstellung entscheidend verzögern oder folgenschwer in eine Sackgasse und dann zum Abbruch führen.

Aber selbst wenn das Team die Festlegungsphase selbst verantworten kann, ist es sehr schwierig, jeden Einzelnen bezüglich seiner technologischen Vorlieben zu neutralisieren und eine produktgerechte Auswahl zu erreichen.

Fragt man einen Entwickler nach den einzusetzenden Werkzeugen, wird er sich auf seine bisherigen Kenntnisse stützen und das Gewohnte vorschlagen. Sie hassen es zuzugeben, dass sie etwas nicht wissen oder bei etwas falsch liegen. Es ist begründet in deren Kultur. Niemand kann alles wissen, schon gar nicht in diesem Arbeitsbereich. Menschen können jedoch motiviert werden, Nichtwissen oder Fehler ohne Furcht zu äußern. Gutes Management, Coaches oder Moderatoren schaffen es durch richtige Fragen ein offenes Verhalten im Team zu fördern.

Software-Entwicklung ist ein Innovationsprozess

Holistisches, invertiertes Denken

In einem meiner Innovationsprojekte sollte ein mechatronisches Team eine neue Variante einer Bearbeitungsmaschine entwickeln. In der Kreativ-Phase begann man wie gewohnt mit der klassischen Vorgehensweise: erst die Mechanik, dann Elektrik/Elektronik und schließlich die Steuerungssoftware. Doch nach mehreren durchgespielten Varianten kam irgendwie keine Begeisterung auf. Die Nachfolgemaschine unterschied sich nicht groß von dem Vorgänger.

Daraufhin forcierte ich das holistische, kreative Denken und es entstand ein invertierter Ansatz. Die Produktfunktionen wurden über die Software des Bedienpultes definiert und zusammen mit ausgewählten Kunden solange optimiert, bis jeder von einer gewisse Euphorie erfasst wurde. Ausgehend von den entstandenen Software-Modulen wurden dann die mechanischen und elektrischen Komponenten festgelegt oder entwickelt.

Das Ergebnis war eine Maschine, die konzeptionell völlig anders war als alles auf dem Markt. Sie hat sich später als durchschlagender Verkaufserfolg herausgestellt. Wettbewerber begannen das Konzept übereilt und wenig erfolgreich zu kopieren.

Software-Entwicklung ist ein Innovationsprozess, das wurde hier besonders deutlich.

Wann ist ein Team agil?

agile Arbeitsweise

Mir wurde wiederholt die Frage gestellt, warum die agile Arbeitsweise manchmal sehr erfolgreich, häufig aber nicht so gut läuft. Worin unterscheiden sich diese Teams und deren Rahmenbedingungen?

Bevor man sich über Methoden, Frameworks oder Tools austauscht, sollte man sich über das Ziel einig sein. Beginnen wir mit der neutralen Frage, wann ein mit Spezialisten besetztes Projekt hoch effektiv, produktiv und erfolgreich verläuft.

Man hat festgestellt, dass es in einem Team dann besonders gut läuft, wenn sich alle Mitglieder im „Flow“ befinden. Jeder verliert sich völlig in seiner Tätigkeit.

Schön und gut, aber was sind die Voraussetzungen, damit Menschen in den „Flow“ kommen können?

Das zentrale Element von Flow ist die intrinsische Motivation, das bedeutet von Innen heraus motiviert zu sein, ohne äußere Einflüsse.

Intrinsische Motivation

Die Wissenschaft hat herausgefunden, welche Rahmenbedingungen vorhanden sein müssen, damit sich intrinsische Motivation überhaupt erst einstellen kann:

  • In der Selbstbestimmungstheorie von Deci und Ryan nachzulesen, muss die Aufgabe psychologische Sicherheit bieten. Darunter versteht man für jeden Beteiligten eine angemessene Bezahlung, soziale Integration in das Team, verleihen einer Stimme und Wertschätzung seiner Beiträge zum Produkt. Dadurch können Aufgaben in Angstfreiheit und Gelöstheit durchgeführt werden.
  • Für das zu entwickelnde Produkt sollten kompetente Fachkräfte ausgewählt werden, für die das Verhältnis zwischen Anforderungen und Fähigkeiten ausgewogen ist. Bei Über- oder Unterforderung entsteht keine Eigenmotivation.
  • Interessanterweise fördern Diversifikation und leichte Inhomogenitäten der Team Member die Innovationsfähigkeit. Ausgeglichenheit bei den Geschlechtern, Low- und High-Performern oder interdisziplinäre Fähigkeiten ermöglichen bei jedem Einzelnen eine hohe Konzentration auf seine Kernkompetenzen.
  • Ein Team kann sich nur motivieren, wenn es über einen hohen Grad an Autonomie verfügt und sich selbst organisieren kann. Entwickler sind smart, sie wissen welche Tools geeignet sind, welche Metriken sie verwenden oder wann sie sich untereinander austauschen. Ein Fach-Team kann bessere Entscheidungen treffen als das Management. Einflüsse und Störungen von außen sind Gift für die Performance.
  • Um sich mit den Projektzielen zu identifizieren, sind Klarheit und Dynamik der Ziele und eine zeitnahe Rückmeldung der Fortschritte erforderlich. Das wird üblicherweise durch Zeit Intervalle erreicht, nach denen nutzbare Teilergebnisse entstehen. Nach jedem Intervall erfolgt eine Feinjustierung der Ziele oder in schwierigen Fällen ein Abbruch. Stellt es sich heraus, dass die Ziele mit den gegebenen Ressourcen nicht realisierbar sind, ist ein Abbruch kein Versagen. Es ist ein valides Ergebnis.
  • Damit die äußere und innere Sicht des Projektes möglichst synchronisiert bleibt, ist eine transparente just-in-time Kommunikation in beide Richtungen wesentlich. Nur dadurch kann jeder im Team seine Aufgaben richtig einschätzen und priorisieren. Nur sehr selten versagt ein Team, viel eher scheitert die Kommunikation, insbesondere die über Schwierigkeiten.

Agile Arbeitsweise

Vielleicht ist die Auflistung nicht vollständig, doch interessanterweise ist darin weder der Begriff „agile Arbeitsweise“ zu finden, noch die Namen von Methoden, Metriken, Zertifikaten oder Frameworks. Die Gründe für gut funktionierende Projekte sind zeitlos und überall gültig. Sie hängen sicher nicht von irgendwelchen Modeworten ab. Es geht immer um das vertrauensvolle menschliche Miteinander und eine offene Kommunikation.

Die Modeerscheinungen wie Tools, Konzepte, Coaching oder Zertifikate dienen nur dazu  Geld zu verdienen. Das wird häufig durch die Unsicherheit und Unwissenheit von Managern erreicht.

Holistische Software-Entwicklung

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

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ätzungpositive 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

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

holistisch

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

software

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.

© 2023 Innovation Driver

Theme von Anders NorénHoch ↑