Unleash the creative human power

Kategorie: Autonomie

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.

Dream-Team

Dreamteam

Wie lassen sich geeignete Kandidaten zusammenstellen, die zu einem Dream-Team zusammenwachsen und scheinbar unlösbare Aufgaben bewältigen?

Zur Entwicklung eines Luxusautos mit Elektroantrieb wurden Kandidaten für ein Innovationsteam rekrutiert. Wie gewohnt stellte die HR-Abteilung gemeinsam mit Fachabteilungen eine Liste mit den erforderlichen Qualifikationen zusammen und begann wie gewohnt zunächst in den eigenen Reihen nach den geeigneten Fachkräften zu suchen.

Doch weil sich der Markt stark im Umbruch befindet, empfahl das Management das Hinzuziehen eines Innovationsspezialisten. Beginnend mit der Frage „wie erreicht ein Team die maximale Innovationsfähgikeit?“ zäumte er das Pferd von hinten auf.

Ziel

unmöglich

Die groben Rahmenbedingungen für das fertige Produkt wurden deshalb als spannende Herausforderung zugespitzt. Damit konnte sich jeder potentielle Kandidat auseinandersetzen und einschätzen, ob er sich die Aufgabe zutraut und sich dafür begeistern kann.

Im konkreten Fall war es die unmögliche Forderung nach einem emissionsfreien Fahrzeug mit mindestens 500km Reichweite und einem Gewicht von nicht viel mehr als einer Tonne. Trotzdem sollte es den modernen Komfort eines Luxus-PKW enthalten wie z.B. zeitgemäße autonome Fahreigenschaften, großzügige und bequeme Sitze, ausgewogenes Klima, ausreichend Stauraum, hochmoderne Medien- und Entertainmentausstattung etc.

Flow

Wie formt man also unterschiedliche Menschen zu einem effektivem Team? Das Stichwort hieß „intrinsische Motivation“ und die Antwort schien zunächst sehr einfach:

  • Jeder im Team sollte in seinem persönlichen „Flow“ (Schaffens- bzw. Tätigkeitsrausch) arbeiten können, jeder sollte restlos in seiner Tätigkeit aufgehen können.

Intrinsische Motivation entsteht bei der Verfolgung eines gemeinsam angestrebten Zieles durch Kompetenz (Wissen, Fähigkeiten), Zugehörigkeit und Autonomie. (Selbstbestimmungstheorie)

Skills

Fähigkeiten

Das zur Erreichung technologisch komplexer Ergebnisse spezialisiertes Wissen und Fähigkeiten erforderlich sind, versteht sich von selbst. Das lässt sich durch die Dokumentation der universitären Ausbildung einfach ermitteln. Hier gilt der Grundsatz „the B’s rules the A‘s“, das bedeutet es sind nicht die als Beste bewerteten Spezialisten zu bevorzugen, sondern die „Guten“ mit einer breiteren Lebensausrichtung. Sie sind in aller Regel „aufgeschlossen“ und „zielstrebig“.

In der Meta-Analyse von Frank Schmidt und Jack Hunter vor einem halben Jahrhundert haben sich klassische Interviews als nutzlos erwiesen, deshalb werden sie heute vielfach ersetzt durch ein gegenseitiges Kennenlernen. Es ist sehr interessant zu erfahren über welches Thema der Anwärter gerne philosophiert, wie er Energie tankt, wodurch er sich inspirieren lässt, welche Bücher er gerne liest, welche Pläne er für sein weiteres Leben hat, wie er zur Natur steht etc.

Die Anforderung einer hohen „Domänenkompetenz“ (Spezial-Wissen für ein gegebenes Ziel) wird ersetzt durch lediglich eine „Domänenaffinität“ (großes Interesse an dem gegebenen Ziel). Menschen, die zulange in einem Spezialgebiet gearbeitet haben, verlieren häufig den Blick auf die sich ändernden Umgebungsbedingungen. Trotzdem bleibt die Erfordernis, sich für das gemeinsame Ziel begeistern zu können!

Zur Team-Kompetenz gehört auch die Diversifikation der Fähigkeiten und idealerweise auch der Menschen. Damit die heute sehr wichtigen umweltbezogenen Belange berücksichtigt werden können, sind vor allem auch Material-, Fertigungs- und Energiespezialisten mit einzubinden. Zur Ermittlung von statistisch relevanten Kundenwünschen wurde in diesem Fall sogar ein Psychologe hinzugezogen, der sehr außergewöhnliche Erkenntnisse beisteuern konnte.

Team-Manager

Die Entscheidung über Zeiträume und Orte an denen gearbeitet wird, sollte allein den Team-Mitgliedern überlassen werden. Im Zeitalter der „Agilität“ ist die Entkopplung des gesamten Teams von anderen Einflüssen des Unternehmens glücklicherweise mittlerweile selbstverständlich. Der Team-Manager versteht sich als Dienstleister für das Team. Er stellt sich vor das Team wenn es nicht gut läuft und tritt hinter das Team zurück, wenn die Leistung Anklang findet. Mit seiner Qualifikation sollte er die Produktentstehung durch sein Team vollständig verstehen können. Reine Reportschreiber und Datensammler haben sich als negativer Einfluss herausgestellt.

Ergebnis

In dem beschriebenen Fall konnte ein hervorragendes internationales Team zusammengestellt werden, dem es bis jetzt gelang, die scheinbar unmöglichen Anforderungen größtenteils in den Griff zu bekommen.

Dadurch das schon beim Design an die Fertigung gedacht wurde, konnten Prozesse zusammengefasst werden. Ein extra dafür entwickelter energiesparender Prozess druckt jetzt eine gut gedämmte, doppelwandige Hülle aus einem karbonähnlichen Material mit innerer Wabenstruktur. Auf der Außenseite der Schale befinden sich hochwirksame Solarzellen und im Inneren die zugehörigen kupferfreien elektrischen Verbindungen. Intelligente Scheiben isolieren im Winter gegen Kälte, im Sommer verhindern sie das Eindringen von Hitze. Motorfreie automatische Fensterheber,  extrem leichte aber sehr bequeme Sitze oder Gewichtsersparnis bei Motor und Batterien sind nur einige der vielen Resultate des zusammengewachsenen Dream-Teams.

Die Fülle von völlig neuen Ansätzen und mittlerweile eingereichten Patenten durch ein hoch motiviertes Team hat die Unternehmensleitung angenehm überrascht.

Die moderne Art der Rekrutierung, in der der Kandidat und seine Bedürfnisse in den Mittelpunkt gestellt werden, beginnt sich gerade bei innovativen Aufgabenstellungen durchzusetzen.

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.

Führungskräfte schaden!

Team

Im Zusammenhang mit der Auslagerung eines Innovation-Labs gab es erneut die Diskussion, ob man nicht doch besser eine Leitungsfunktion für diese wichtige Projektgruppe etablieren sollte. Obwohl es mittlerweile üblich ist, das sich hoch qualifizierte, innovative Gruppen selbst organisieren, stellen sich intuitiv immer noch Zweifel ein.

Um zu verstehen, warum einzelne Führungspersonen eher dazu tendieren, Mitarbeitern und Unternehmen zu schaden, lohnt es sich den Blickwinkel auf uns Menschen zu erweitern.

Entscheidungen

Das Denken des Homo-Sapiens ist leider nicht so weise und vernünftig wie er es selbst gerne sieht. Davon können Psychologen zur Genüge berichten, die sich mit kognitiven Verzerrungen beschäftigen.

Die Spezies Mensch befindet sich mitten in der evolutionären Entwicklung ihres Gehirns, nicht am Ende. Es gab sogar Zeiten, da hatten wir ein größeres Hirnvolumen, doch heute müssen wir uns mit dem zufrieden geben, was uns unsere Vorfahren vererbt haben.

Wir werden zum größten Teil von unserem Unterbewusstsein gesteuert, bewerten Entscheidungsgrundlagen emotional verzerrt und haben keinen eigenen Willen. Es besteht lediglich die Möglichkeit die vom Unterbewusstsein erzeugten Gedanken zu kontrollieren oder zu steuern. Diese Fähigkeit korreliert jedoch mit dem Trainingszustand des Gehirns.

Mit so vielen Defiziten belastet, sind wir mehr schlecht als recht in der Lage unsere persönlichen Entscheidungen zu fällen. Aber auch hier versagen wir klärglich, wenn die Rahmenbedingungen zu komplex werden. Unser Unterbewusstsein ist jedoch sehr gut darin, schlechte Entscheidungen schön zu reden, deshalb bemerken wir nur selten unser Dilemma.

In der Gruppe stark

Unter bestimmten Umständen ist die Entscheidungsfähigkeit einer Gruppe deutlich besser als die von Einzelnen. Werfen wir einen Blick auf die Voraussetzungen, die ein Team benötigt, um gut zu funktionieren.

Seit Erscheinen der Selbstbestimmungstheorie wurde sie durch viele weitere Studien bestätigt. Menschen können hoch produktiv zusammenarbeiten wenn sie als Gruppe vollständig autonom handeln dürfen, eine hohe Kompetenz (Wissen, Fähigkeiten) besitzen und wertgeschätzt werden. Zusätzlich benötigen sie noch einen Zweck oder ein Ziel mit der Bereitschaft, es gerne zu verfolgen. Das nennt man intrinsisch motiviert, die Zutaten um in einen Flow zu kommen.

In vielen Unternehmen agieren Personen auf ähnlichem akademischen Level, lediglich die Fachrichtungen unterscheiden sich. Viele der heute benutzten Verfahren zur Rekrutierung von hoch qualifizierten Kräften haben sich als wenig nützlich erwiesen. Persönliche Interviews sind besonders schädlich, wie u.a. in Kahneman’s Buch „Thinking, fast and slow“ nachzulesen. Eine Auswahl wird häufig ungewollt durch Seilschaften oder einem Sympathiefaktor getroffen, nicht durch objektive Qualifikation (the B’s rules the A’s). Langjährige Erfahrung auf einem Gebiet blockiert innovatives Denken und kann aufgrund der kurzen Halbwertzeiten von Fachwissen eher ein Nachteil sein.

Einzelpersonen können sich nicht vollständig von ihren Eigeninteressen befreien und sind unbewusst Spielball ihrer persönlichen emotionalen Umstände. Ihre Entscheidungen leiden viel zu häufig unter Einseitigkeit, Kurzsichtigkeit und Egoismus. Gerade in Bezug auf Mitarbeiter oder Vorgesetzte sind sie selten unvoreingenommen. Sie übernehmen auch nicht wirklich Verantwortung, sonst müssten sie bei schuldhaftem Verhalten ihr verdientes Geld zurück zahlen. 

Dagegen werden in einer interdisziplinären Gruppe vor einem Konsens deutlich mehr Rahmenbedingungen durchleuchtet und persönliche Emotionen Emotionen sowie kognitive Verzerrungen weitestgehend kompensiert oder sogar neutralisiert. Eine besonders positive Rolle spielt dabei der Interessensausgleich durch unterschiedliche Gender, verschiedene Arten von Leistungsträgern (B’s equal to A’s) bzw. Erfahrungslevel oder andere Kulturen.

Menschen sind bei Gruppenentscheidungen grundsätzlich weniger egoistisch.  

Ideale Welt

Beautiful World

Stellen wir uns eine Welt vor, in der jeder Mensch über tiefe naturwissenschaftliche und technische Kenntnisse verfügt: von der genauen Funktionsweise der Proteinfabriken in biologischen Zellen über die Fähigkeit elektromagnetische Felder mit Hilfe der Quantenelektrodynamik zu berechnen bis hin zum Vorhersagen von Materialien des Periodensystems der Elemente nur aus der Masse einer Supernova sowie identifizieren der Komponenten eines Quantencomputers oder Entwickeln eines Reinforcement-Learning-Algorithmus für eine bestimmte Aufgabe.

Aufgrund der außergewöhnlichen Fitness seines Bewusstseins wird dieser Homo-Fictus in der Lage sein, seine Emotionen zu kontrollieren und seine biologisch gegebenen Denkschwächen durch eigenes Reflektieren und mit Hilfe von Werkzeugen zu kompensieren.

Diese Welt lebt in Einklang mit der Natur, sie ist frei von großen gesellschaftlichen Unterschieden und frei von aggressiven Auseinandersetzungen.

Diese Welt wird gänzlich ohne Führungskräfte auskommen!

 

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.

© 2024 Innovation Driver

Theme von Anders NorénHoch ↑