Unleash the creative human power

Schlagwort: Flow

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.

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.

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.

© 2024 Innovation Driver

Theme von Anders NorénHoch ↑