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.
Entstehung
Dieses agile Framework entstand in einer Zeit, in der das Wissensmanagement in japanischen Universitäten entwickelt wurde. Zu den Produktionsfaktoren Kapital, Arbeit 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).
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“.
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.