Agile Entwicklungsprozesse sind in aller Munde. Im Anwendungs- und Web-Umfeld mausert sich Scrum zum de-facto Standard. Ein Standard der von der Embedded- und Systemwelt interessiert beobachtet wird, dessen Umsetzung jedoch in der Systementwicklung viele Fragen aufwirft.
Wie kann ein agiler System-Entwicklungsprozess aussehen? Was außer Scrum sollte dabei in die Betrachtung einfließen? Was kommt nach den agilen Methoden?
Compliance – Die erste Kontaktaufnahme der Systementwicklung mit der agilen Welt erfolgt meist nicht auf „der grünen Wiese“, sondern aus einem mehr oder minder etablierten Prozess heraus, dessen Rahmenbedingungen nicht selten compliance-getriebene Themen wie CMMI, SPICE oder Funktionale Sicherheit sind. Diese Themen sind wichtig, weil sie oft von Markt oder Gesetz vorgegeben werden. Den Prozess scheinen sie jedoch, ausgehend vom Status Quo, nicht mehr wesentlich voranzubringen, das verbleibende Verbesserungspotential wird überschaubar sobald die Compliance-Themen durch den Prozess bedient werden.
Ab hier rücken neue Themen in den Fokus des Prozessgestalters: Durchsatz, Flexibilität und Kosten. Aus naheliegenden Gründen soll eine Optimierung mit möglichst wenig Aufwand, also mit möglichst wenigen Änderungen am Prozess geschehen, idealerweise aber mit großer Wirkung.
Produktion – Verlässt man die aktuelle Umlaufbahn „Entwicklung“ und begibt sich auf die Ebene „Produkt“, werden Denkmodelle und Werkzeuge sichtbar, die eine Lösung für die eben gestellte Aufgabe zu bieten scheinen: Verbesserungsmethoden in der Produktion. Sind Lean, Six Sigma, Kaizen und Co. wirklich für den Entwicklungsbereich einsetzbar? Zumindest das Kanban-Prinzip hat diesen Sprung geschafft. 1947 bei Toyota entwickelt, ist es 65 Jahre später neu entdeckter Problemlöser in der Softwareentwicklung.
Lean und Kanban bieten inkrementelle evolutionäre Prozessverbesserung auf Basis eines bestehenden Prozesses. Abläufe, Schnittstellen, Verantwortlichkeiten und Rollen werden zunächst nicht angefasst. Dies gilt sowohl für die Produktion, wie auch für die Entwicklung. Also lohnt es sich auch andere bewährte Produktionsthemen dahingehend näher zu betrachten: Könnte nicht der Six Sigma Methodenkoffer unser Verständnis für Prozess-Metriken, Ursachen und Maßnahmen verändern? Ein weiteres Highlight aus der Produktionswelt ist die „Theory of Constraints“ (TOC) des Physikers Eliyahu Goldratt. In Europa eher unbekannt, hat sie in Nordamerika in vielen Unternehmen bewiesen, dass sie die Prozesssteuerung einfacher und effizienter verbessert als das Kanban-Prinzip. Die TOC geht jedoch über die bisher diskutierten evolutionären Ansätze hinaus, die von ihr vorgeschlagenen Denkweisen zu Projektmanagement und Kostenrechnung gleichen eher einem revolutionären Denkansatz. Innerhalb der Produktionsverbesserungen eröffnet sich also ein gewisses Spektrum von evolutionären hin zu revolutionären Ansätzen.
Agilität – Eine Prozess-Revolution die sich in der Software-Welt einen Namen gemacht hat ist das agile Framework Scrum. Scrum vereint einzelne agile Praktiken zu einem Modell das mehr bietet als die Summe der einzelnen Teile und neben dem eigentlichen Entwicklungsprozess auch Rollen für den agilen Prozess festlegt. Eine Verschmelzung von Scrum und bestehenden compliance-getriebenen Prozessen stellt oft eine große Herausforderung dar und lässt nicht selten entweder Compliance oder Agilität als Verlierer zurück. Eine wirksame und damit sinnvolle Adaption von Scrum erfordert, mehr noch als eine Scrum-Einführung nach dem Lehrbuch, eine intensive Auseinandersetzung mit den Wirkungsweisen und somit Denkweisen hinter den einzelnen agilen Praktiken. Betrachtet man Scrum als ein Werkzeug wird schnell klar: Die Anpassung eines vorgegebenen Werkzeugs auf eigene Bedürfnisse erfordert deutlich mehr Wissen und Erfahrungen als der reine Einsatz eines solchen Werkzeugs.
Im agilen Kontext bedingen Wissen und Erfahrung vor allem aber auch ein Umdenken über Wirkungsketten, ja oftmals sogar einen deutlichen Kulturwandel. Dies gilt auch schon für ein schlichtes Scrum nach Lehrbuch. Nicht wenige gescheiterte Scrum-Einführungen gehen auf das Konto dieser Problematik. Ein Einsatz von agilen Praktiken in einer von „command an control“ geprägten Organisationskultur wird in den meisten Fällen nicht die gewünschten Effekte erzielen. Damit Agilität ihre Wirkung entfalten kann, muss die Organisation investieren, in erster Linie Vertrauen und Zeit. Es geht primär nicht darum Verfahren zu ändern, sondern Denkweisen. Der Mensch rückt mehr und mehr in den Fokus der Prozessverbesserung.
Mensch – Es spricht vieles dafür, dass der Mensch an sich agil ist, er diese Agilität aber verloren hat. Genauer gesagt, nicht der einzelne Mensch hat sie verloren, sondern die Organisationskulturen die sich in den letzten 100 Jahren gebildet haben, bzw. die wir geschaffen haben. Die Manufaktur war eine sehr agile Arbeits- und Organisationsform, der Übergang in den Taylorismus hat diese Agilität deutlich zurückgedrängt. Frederick Winslow Taylor hat Können in Wissen und Prozesse zerlegt. Dadurch konnten weniger qualifizierte Arbeitskräfte eingesetzt werden, und die Qualität war weniger von einzelnen Personen abhängig. Dies war ein sehr erfolgreiches Konzept, der Schlüssel zur Massenproduktion. Erfolgreich war der Taylorismus aber nur in den damaligen Marktbedingungen – nahezu unendliche Märkte, in denen die mit dem Taylorismus erkauften Nachteile nicht von Bedeutung waren. Kundenorientierung, Flexibilität, Kreativität und Reaktionszeiten waren nicht marktentscheidend.
Die oben beschriebenen Produktionsoptimierungen wie auch agile Entwicklungsmethoden sind lediglich verschiedene Sichtweisen auf dieselben Themen. Und beide Bereiche verfolgen mit verschiedener Intensität dasselbe Ziel: die Abkehr vom Taylorismus und die Fokussierung auf den Menschen und sein Können.
Der Mensch ist jedoch nicht nur ein Faktor als Prozessbestandteil, sondern auch als Persönlichkeit. Der persönliche Wirkungsgrad eines Menschen hängt entscheidend von dessen Motivation ab. Verschiedenste Forschungsarbeiten zeigen explizit, dass die bisher vorherrschenden extrinsischen Motivationssysteme nicht funktionieren, häufig sogar die gegenteilige der beabsichtigten Wirkung entfalten. Die Wissenschaft sagt uns, dass intrinsische Motivation auf drei Faktoren beruht: Können, Selbstbestimmung und Sinn. In agilen Prozessen wird nicht nur verhindert, dass Herr Taylor an ersterem die Säge ansetzt, auch die beiden anderen Faktoren werden ebenfalls gezielt angegangen: Team-Empowerment ermöglicht mehr selbstbestimmtes Arbeiten als in starren Prozesswelten und der enge Kundenkontakt verbessert die Qualität von Requirements durch Vermittlung des Business-Case des Kunden. Dies ist jedoch nicht aus Menschenliebe in die agile Denkweise eingeflossen, sondern rational aus Gründen der Effizienz- und Qualitätssteigerung.
Ein Aspekt, den Menschen betreffend, wird von agilen Konzepten oft ausgespart: Was macht ein performantes Team aus? In agilen Umgebungen findet ein Entwicklungsteam im Normalfall Rahmenbedingungen die eine Leistungsentfaltung des Teams ermöglichen, doch oft ist zu beobachten, wie das Team mit der nicht-technischen Aufgabe des Team-Building überfordert ist und sich selbst überlassen wird. Eine nachhaltige Unterstützung von Teams zahlt sich aus: Entweder durch klassisches Coaching oder durch Team-Resource-Management-Trainings nach den Konzepten die die Luftfahrtindustrie die letzten 20 Jahre entwickelt hat, um aus gut ausgebildeten Profis hoch-performante Teams zu formen.
Community – Auch beim Thema Motivation darf die Frage gestellt werden: Wie ist das eigentliche Wesen des Menschen? Wie verhält und organisiert sich der Mensch ohne äußere Zwänge? Einen Hinweis gibt die Open Source Bewegung: gut bezahlte Software-Entwickler organisieren sich in Communities und verbringen Ihre Freizeit damit Software zu entwickeln, die sie vielleicht selbst gar nicht benötigen und für deren Entwicklung sie nicht bezahlt werden. Auch hier sind die drei Faktoren der intrinsischen Motivation vorhanden: Können einbringen und weiterentwickeln, selbstbestimmtes Arbeiten, sowie den Sinn der eigenen Arbeit erfahren. Geld ist kein Motivationsfaktor! Der Bezug von Communities zur Systementwicklung ist erst auf den zweiten Blick zu erkennen: Firmen die miteinander im Wettbewerb stehen, entwickeln in Communities gemeinsam Tool-Ketten auf der Basis von Open Source Produkten. Als Beispiel seien hier die Eclipse Automotive Working Group oder das von Airbus initiierte Polarsys-Projekt genannt. Das Umfeld für eine solche Zusammenarbeit sind Entwicklungsbereiche die für die Wettbewerber nicht marktentscheidend sind, sondern lediglich bestimmte „Basics“ zur Verfügung stellen.
Sind nicht die eingangs erwähnten Compliance-Themen ebenso wenig marktentscheidend? Könnte sich nicht eine in Communities organisierte Zusammenarbeit zum Thema „Funktionale Sicherheit“ zwischen Firmen entwickeln, die ansonsten miteinander im Wettbewerb stehen?
Mit diesen Fragen über die Zukunft schließt sich der Kreis unserer Betrachtungen, wir sind wieder bei der Compliance angekommen.
Fazit – Die hier gebotene Darstellung der Themen Compliance, Produktion, Agilität, Mensch und Community soll nicht verschiedene Entwicklungsstufen oder einen zeitlichen Ablauf darstellen. Die Reihenfolge bzw. die Anordnung ergibt sich aus den Überschneidungen der Themenbereiche.
Es gibt keinen definierten Weg von der klassischen hin zur agilen Entwicklung und es gibt auch keine Kochrezepte. Abhängig vom eigenen Startpunkt, der eigenen Organisationskultur und den eigenen Zielen lohnt es sich über den Tellerrand der Agilität im engeren Sinne hinauszublicken um seinen eigenen Weg zu finden. Die Praxis zeigt, dass die Besonderheiten der Systementwicklung gegenüber einer reinen Softwareentwicklung sehr gut mit Fluss-Methoden wie z.B. Kanban aufgenommen werden können. Kanban bietet bei vorläufiger Beibehaltung von Prozess, Schnittstellen und Rollen eine Plattform für eine sanfte Agilität und sanfte Veränderungen. Obwohl Kanban nicht agil im engeren Sinne ist, kann es doch agil eingesetzt werden, bietet es doch schon zwei wesentliche agile Aspekte: Transparenz und Reduzierung des Work in Process (WIP). Wird der Kanban-Prozess auf kleine Inkremente, Kundenfeedback und eigenständige Teams erweitert, ist die Prozessevolution hin zur Agilität gelungen.
Trotz der hier vorgestellten Methoden und Konzepte und deren augenscheinlicher Einfachheit: Der Schlüssel zur agilen Entwicklung ist ein Umdenken des Einzelnen wie auch der Organisation. Und dies erfordert Zeit, Vertrauen und Geduld. Im Ausgleich dafür rückt die Organisation näher an den Kunden, näher an den Mitarbeiter und wird dabei schneller, flexibler und effizienter. Die Märkte der Zukunft erwarten dies.