Scrum — Software-Toyotismus?

ScrumDas, was wir in der Freien Software und anderswo im Freien Feld beobachten können, gibt es tendenziell auch in der proprietären Produktion. Sonst wäre es auch keine Keimform — die historische Tendenz zeigt sich überall. In der proprietären Produktion sind allerdings die Widersprüche anders gelagert. Während im Freien Feld die Frage vordringlich ist, wo die Leute Knete fürs Leben her bekommen können, um all die netten Sachen zu tun, die sie tun, ist im proprietären Feld diese Frage »geklärt«: Die Kohle ist da, gearbeitet werden muss. Entfremdung nennt man das. Aber auch unter entfremdeten Bedingungen können manchmal sinnvolle Dinge geschehen.

In der proprietären Produktion lautet die Frage wider die Entfremdung: Wie werden die Arbeitenden dazu gebracht, das zu tun, was der Markt resp. der Kunde verlangt? Diese Frage ist deswegen virulent, weil man von den Arbeitenden nicht verlangen kann, dass sie ihren Job motiviert tun, sondern Hauptsache ist, dass sie ihren Job erledigen. Diese Haltung war für die Zeit des Fordismus noch ok, für die postfordistische Ära reicht das nicht mehr aus. Heute ist der ganze Mensch gefragt, seine Motivation, Kreativität, Engagement, Sozialität, Emotionalität. Das verträgt sich nicht mit einer entfremdeten Arbeitssituation, wo ich immer nur für Dritte (Markt, Kunden) etwas tue, aber nichts für mich.

Lösungsvorschläge zur Lösung dieses Dilemmas kamen häufig aus der Auto-Industrie: Gruppenarbeit, Kaizen, Kanban, Toyotismus und wie die technizistischen Ansätze alle hießen. Etwas ähnliches geschah auch in der Software-Entwicklung. Hier wurde das Dilemma auch als das benannt, was es ist: Softwarekrise. Allerdings verstand man darunter — ähnlich technizistisch wie bei der Autoindustrie — im wesentlichen ein Komplexitätsproblem: Wenig Code ist überschaubar und gut, viel Code ist komplex und schlecht. Das ging (und geht) aus meiner Sicht am eigentlichen Problem vorbei, was Annette Schlemm und ich anderenorts einmal als Widerspruch zwischen »Selbstverwertung und Selbstentfaltung« versucht haben auf den Punkt zu bringen. Oder noch platter aus meiner eigenen Projekterfahrung: »Wenn Geld ins Spiel kommt, fangen die Leute an zu spinnen.«

Nun gibt es seit über zehn Jahren Scrum. Das ist ein Vorgehensmodell bei der Entwicklung von Software. Es beansprucht, die Ideen agiler Software-Entwicklung systematisch umzusetzen. Scrum — so erklärt Wikipedia — überträgt die Philosophie des Toyotismus auf die Software-Entwicklung. Wie das?

Scrum gibt den Entwicklern mehr Handlungsmacht und dynamisiert den gesamten Prozess. Die Software wird in iterativen Zyklen von zwei bis vier Wochen entwickelt. Das Entwicklungsteam legt selbst fest, welche Aufgaben es wie erledigen kann. Es gibt keine kleinteilig vorgekauten und festzementierten Pflichten-/Lastenhefte, sondern die Anforderungen werden in einer Feature-Liste (Product Backlog) gesammelt und ggf. erweitert oder geändert. Ein Ausschnitt daraus wird in die Aufgabenliste für den Sprint (Sprint-Backlog) übernommen, wobei sich diese Liste während einer Iteration nicht ändert. Im Sprint werden die Aufgaben vom Team eigenverantwortlich umgesetzt, wobei täglich Status-Feedbacks erfolgen (Daily Scrum-Meeting). Das Ergebnis wird bewertet (Review) und der Sprint wird ausgewertet (Retrospektive). Im Idealfall ist nach 30 Tagen ein substanzieller Fortschritt in der Software-Entwicklung geschafft und die nächste Runde beginnt.

Bei Scrum gibt es nur drei — gleichberechtigte — Rollen: Auf der Auftraggeberseite der Product Owner, auf der Entwicklerseite das Team und dazwischen der Scrum-Master. Die klassischen Produktmanager oder Projektleiter gibt es nicht. Für die Freie Software ist das Modell so ungewöhnlich nicht. Im weitesten Sinne ist der Product Owner der Gründer und Maintainer eines Projektes, das Team sind die Mitglieder in einem Projekt und das Scrum-Master — ist auch wieder der Maintainer. Im Scrum-Prozess müssen Project Owner und Scrum-Master getrennt sein, weil der Owner die Nachfrage- und Geldseite repräsentiert, während der Scrum-Master Transparenz und gute Arbeitsbedingungen im Projekt schaffen soll. Gleichzeitig soll letzterer auch nicht Teil des Teams sein, um auch hier Neutralität zu wahren. Da in einem klassischen und insbesondere doppelt Freien Software-Projekt die Auftragseite wegfällt, wird die Vermittlerposition zwischen der »Geldseite« und »Arbeiterseite« hinfällig. Bei einfach Freien Software-Projekte (etwa im Auftrag) bietet sich hingegen die Scrum-Struktur geradezu an, die für die notwendig ablaufenden Interessenkonflikte eine Vermittlungsinstanz (»Betriebsrat«) parat zu haben.

Löst Scrum die Probleme, die aus dem Widerspruch zwischen Verwertungslogik und Selbstentfaltungswunsch kommen? Natürlich nicht. Denn eine Methode, ein Vorgehensmodell akzeptiert zunächst einmal die Rahmenbedingungen der entfremdeten Software-Produktion. Aber sie kann helfen, die auftretenden Widersprüche offen zu legen, um ggf. einen »Deal« zu finden, der die Interessenkonflikte befriedet. Während inzwischen in der proprietären Auto-Produktion die Re-Taylorisierung marschiert, wird die Softwarebranche ein wenig von agilen Methoden »erfrischt«. Mit dazu beigetragen hat sicher die Freie Software. Doch dass die ganz eigene Methoden braucht, die nicht ohne weiteres auf die proprietäre Software zu übertragen sind, ist inzwischen auch klar geworden.

Fazit: Die Verwertungslogik funktioniert nicht mehr nach Befehl und Gehorsam. Sie braucht den »ganzen Menschen«. Den bekommt sie aber nicht, denn Selbstentfaltung von »je mir« und Befolgen der »fremden« Verwertungsanforderungen sind nicht zusammen zu bringen. Allerdings lässt sich zumindest teilweise eine größere Nähe herstellen. Dazu dienen solch »subjektivistische« Methoden wie Scrum. Unter gegebenen Handlungsbedingungen mehr individuellen und kollektiven Spielraum zu haben, ist ja auch schon was. Und wer schlau ist, erkennt die Hinweise auf die freie Entfaltung, die in Scrum sichtbar werden. Die brauchen dann allerdings auch eine Freie Gesellschaft, um zur Geltung kommen zu können.

Kann jemand seine persönlichen Erfahrungen mit Scrum beschreiben? Sind Scrum und ähnliche Methoden auf dem Vormarsch oder in Zeiten der Krise eher wieder auf dem Rückzug?

45 Kommentare

Einen Kommentar hinzufügen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Entdecke mehr von keimform.de

Jetzt abonnieren, um weiterzulesen und auf das gesamte Archiv zuzugreifen.

Weiterlesen