Kanban, Scrum und die Frage des Übergangs

Es gibt Beispiele, die sind komplizierter als das, was sie illustrieren sollen. Aber irgendwie – und dieses irgendwie muss man groß schreiben – IRGENDWIE veranschaulichen sie einen Aspekt so überdeutlich, dass sie doch wichtig sind.
So geht es mir mit der Frage des Übergangs. Ich habe einmal in einer Veranstaltung gesessen, ich weiß heute nicht mehr wie ich dahin kam, in der es um die Entstehung der 12-Ton-Musik ausgehend vom späten Bruckner ging. Ich verstehe eigentlich nichts von Musik, ich kann mit der 12-Ton Musik Schönbergs, wenn ich sie höre, nichts anfangen, und ich kenne kein einziges Werk des späten Bruckner mit Namen, aber die Veranstaltung beschrieb ein Muster so plastisch und anschaulich, dass ich fasziniert war.
Musikstücke – jetzt sollte jeder Nichtlaie weghören – haben eine Tonart. Ich kann mir das am einfachsten am Klavier vorstellen. Die 8 weißen Tasten angefangen beim C bilden die Grundtöne der Tonart C-Dur. Die Abstände der Tasten beim Klavier – egal ob weiß-weiß oder weiß-schwarz – bestehen aus einem Halbton. Da nicht zwischen allen weißen Tasten eine schwarze ist, gibt es weiße Tasten, die einen halben Ton und weiße Tasten, die einen ganzen Ton auseinander liegen. Wenn ich beim C anfange und nur die weißen Tasten drücke, habe ich eine Tonleiter, die klingt. Dabei habe ich zwei Ganztonsprünge, einen Halbtonsprung, dann wieder drei Ganztonsprünge und einen Halbtonsprung. Diese Reihe (1-1-0,5-1-1-1-0,5) kann ich jetzt bei jedem Ton starten. Wenn ich z.B. beim G beginne habe ich die G-Dur-Tonleiter. Ich muss in den Tonarten entsprechend viele schwarze Tasten drücken, um auf meinen Grundtönen zu bleiben. Was bleibt sind immer die Abstände der Töne in der Grundtonleiter.
Wo war ich? Ach ja! Musikstücke haben eine Tonart. Diese ist am Anfang eines Stückes markiert. Ich lege damit fest, welche acht Tasten ich drücke darf. Wenn ich nun der Meinung bin, ich brauche mal einen anderen Ton, der jetzt eigentlich nicht erlaubt ist, kann ich diesen einzelnen Ton mit einem Vorzeichen versehen und darf außer der Reihe drücken. Der Vortrag, von dem ich erzählen wollte, beschäftigte sich mit der Musik des ausgehenden 19. und beginnenden 20. Jahrhunderts, insbesondere mit der Musik Anton Bruckners. Es hieß im Spätwerk Bruckners würde eine schwebende Tonalität herrschen. Das meinte, die Stücke hätten zwar eine Tonart – ganz am Anfang des Stücks wäre eine notiert – es gäbe aber so viele Vorzeichen an einzelnen Noten im Stück, dass diese Tonart kaum noch zu erkennen sei – eben schwebend. Bruckner hätte mit den Mitteln der klassischen Tonalität das ausgereizt, was sich komponieren liesse, wenn man den Begriff der Tonart nicht aufgeben wolle. Den nächsten Schritt, ob das musikhistorisch überhaupt Sinn macht kann ich nicht beurteilen, stellte die 12-Ton-Musik Arnold Schönbergs dar. Schönberg ‘befreite’ die Musik vom Korsett der Tonalität. Er schuf eine Musik, die alle Tasten (12) gleichberechtigt nebeneinander stellte. Damit wäre es leicht gewesen, die Musik zu notieren, die der späte Bruckner komponiert habe. Mit der Befreiung von der Tonalität entstanden ganz neue Möglichkeiten von Musik, die neue Notation eröffnete Felder, die im Kontext der alten Notation nur als Randgebiete sichtbar waren.
Mich faszinierte an dem Vortrag das Muster, welches überdeutlich wurde. Das Neue – Schönbergs 12-Ton-Musik – was keine Erfindung, mit der man dann neue Sachen machen konnte. Im Gegenteil. Das Alte, die klassische Form der Musik hatte sich an eine Stelle entwickelt, an der ihr formales Gerüst bis an ihre Grenzen belastet wurde, an eine Stelle, an der sich die Sinnhaftigkeit dieser formalen Struktur stellte. Das Neue befreite nur den schon vorhandenen neuen Inhalt aus der alten Form und ließ ihm Raum sich weiter zu entwickeln.
Ich denke dass es sich mit vielen neuen Dingen so verhält, das sie auf dem Boden des alten entstehen, dieses bis an die Grenzen des Sinnhaften beanspruchen und so den Übergang zu etwas Neuem – nicht nur vorbereiten -, sondern erzwingen.
Wer zum Beipiel den Text von Winston Royce ‘Managing the Development of Large Software Systems’ liest, der gemeinhin als Manifest des Wasserfallmodells gilt, wird finden, dass dieser Aufsatz im Gegenteil sehr viele Anmerkungen zum Wasserfallmodell macht, die in Richtung einer agilen Sofwareentwicklung weisen. Mehr Agilität geht im Modell des Wasserfalls wahrscheinlich gar nicht. (Ich habe versucht das hier auszuführen.)
Etwas ähnliches scheint sich im Moment im Bereich Scrum/Kanban zu vollziehen. Wir setzen auf der Arbeit in unseren Projekten Taskboards ein. Die genaue Gestalt variiert von Team zu Team, aber ein Taskboard haben fast alle. Wenn ich mir die Boards der Projekte anschauen, die Tagesbetrieb/Wartung und Kleinprojekte machen, dann haben die nie den Charakter eines Scrum-Taskboards. (Ein echtes Scrum-Taskboard: Am Anfang der Iteration sind alle Karten links und am Ende rechts.) In den Tagesbetriebsprojekten führt es dazu, dass die Wochenplanungen immer wichtiger werden als die Releasemeetings, sofern es sie für das ganze Projekt noch gibt. Und es führt dazu, dass das Team das Gefühl hat, etwas falsch zu machen. ‘Eigentlich muss das doch anders gehen.’ Das Werkzeug ‘Prozess’ verwandelt sich in ein Korsett. Die Stellschrauben, die Scrum einführt, greifen in diesen Projekten nicht wirklich. Das Messen der Geschwindigkeit funktioniert nicht wirklich, weil sehr viele Aufgaben als dringende während des Sprints dazukommen. Das widerspricht zwar dem Gedanken des Sprints ist aber in Wartungsprojekten unerläßlich. Natürlich gibt es Workarounds: rote Karten, die nicht mitgemessen werden oder Puffer, die von vornherein für Wartung und Bugfixing reserviert werden. Es ist aber nicht sehr befriedigend einen großen Teil der Arbeit während eines Sprints nicht in die Messung einzubeziehen.
Die Kanban-Diskussion hat den befreienden Effekt, dass sie die Diskussion in eine andere Richtung lenkt. Es heisst nicht mehr Scrum Ja oder Nein, sondern es werden Instrumente sichtbar, mit denen man einen Prozess gestalten kann, der in einem Umfeld stattfindet, das keine feste Timebox mehr erlaubt. Die Diskussion um Kanban zeigt bspw. wie man den Durchsatz messen kann, wenn es einem nicht möglich ist die Geschwindigkeit im klassischen Sinne zu messen. Mit Beschränkungen der Warteschlangengrößen wird eine Stellgröße sichtbar, die der klassische Scrumprozess nicht kannte und auch nicht brauchte, da er in einem andern Umfeld zu hause ist. Insofern habe ich dass Gefühl Kanban ist das Neue, was auf dem Boden des Alten entstanden ist. Jetzt gilt es allerdings nicht mehr die Diskussion Alt gegen Neu zu führen, sondern auszuprobieren, wie sich die Instrumente, auf die Kanban die Aufmerksamkeit lenkt, einsetzen und erweitern lassen. Die Beipiele, die ich bisher in den verbreiteten Präsentationen gesehen habe – vor allem Verklemmungen beim Deployment – haben etwas Triviales, man hat den Eindruck, hier hätte nicht Kanban, sondern etwas gesunder Menschenverstand genügt.

Leanproduction und das Eintüten eines Briefes

Die MIT-Studie über die zweite Revolution in der Automobilindustrie unterscheidet drei Weisen der Produktion. Die fordistische, amerikanische Massenproduktionsweise, die japanische Produktionsweise und die skandinavische Manufakturproduktionsweise. Da es einige Beispiele dafür gibt, Produktionsweisen am Beispiel des Eintütens von Briefen zu verdeutlichen, will ich in diesem Bild bleiben und versuchen den Unterschied der drei Weisen zu verdeutlichen.

Die Aufgabe besteht darin, 100 Briefe mit 100 DIN A4-Blättern zu füllen, die Umschläge zu zu kleben und diese mit 100 Briefmarken zu frankieren. Die erste – auch historisch erste – Form das Problem zu erledigen, die Manufakturproduktion, besteht darin, alle Briefe einzeln zu bearbeiten. Arbeiter 1 nimmt sich einen Brief, versieht ihn mit Inhalt, klebt ihn zu und frankiert ihn. Wären mehrere Arbeiter zugange, würde sie ebenfalls diese Tätigkeit ausführen. Jeder macht das gleiche. Der Arbeitsprozess zerfällt nicht in seine Bestandteile, jede Arbeitskraft vollzieht ihn ganz.

Die zweite Form das Problem zu lösen, die fordistische Produktionsweise, besteht darin, den Prozess zu zerlegen und ihn durch ein Medium wie das Fließband wieder zusammen zu setzen. Arbeiter 1 füllt die Briefe und gibt sie weiter. Arbeiter 2 klebt die Briefe zu und gibt sie weiter. Arbeiter 3 frankiert sie und legt sie auf den Stapel der fertigen Briefe. Jede Arbeitskraft vollzieht nur noch einen Teil der gesamten Arbeit. Weil die Arbeiten  unterschiedlich lange dauern, werden zwischen den unterschiedlichen Stationen Puffer aufgebaut und die Stationen werden skaliert. Es gibt drei Tütenkleber, zwei Frankierer und einen Füller. Jede Station wird optimiert. Möglichst schnell füllen, möglichst schnell frankieren und möglichst schnell kleben. Diese zweite Form der Produktion verdrängte historisch in vielen Bereichen die Manufakturproduktion und wurde als industrielle Produktionsweise bekannt.

Die Manufakturproduktionsweise wird in den Bereichen geschätzt, in denen Qualität wichtig ist. So gab es – vom MIT in der Studie untersucht – in der skandinavischen Automobilindustrie Versuche die Manufakturarbeitsweise unter industriellen Bedingungen wieder zu beleben. Man setzte bspw. ein Team auf das Fließband, ließ es an allen Stationen vorbeifahren und ein Auto als Ganzes montieren.

Die dritte Form der Produktion – die toyotistische Massenproduktion – trat historisch auf den Plan, als die zweite, Fließband, Industrie, über die erste, Manufaktur, gesiegt hatte. Wie wird hier der Brief eingetütet. Der Grundgedanke ist: Arbeitsteilung wie in der Industrie, Arbeitsfluss wie in der Manufaktur. Was meint das? Wenn ich mich kurz in einen Brief verwandle, dann fühlt sich die erste Arbeitsweise so an, dass ich in einem Fluss gefüllt, verklebt und frankiert werde. Bei der zweiten Weise werde ich gefüllt und muss warten, werde verklebt und muss warten, werde frankiert und bin fertig. Bei der toyotistischen Arbeitsweise -besser: ihrem Ideal – fühlt es sich wieder so an wie in der ersten, ich werde in einem Rutsch gefüllt, verklebt, frankiert. Und das obwohl Arbeitsteilung herrscht und die füllenden, klebenden und frankierenden Hände unterschiedliche sind. Man nennt das ‘Single Piece Flow’. Die Kunst bei der dritten Weise der Produktion ist es also die Vorteile der zweiten Weise beizubehalten, aber ihre Nachteile, Warteschlangen, Verschwendungen, die den Prozess stocken lassen, zu überwinden. Single Piece Flow ist dabei ein Maßstab um den Prozess zu verbessern. Es ist kein Ideal in sich selbst. Gemessen am Single Piece Flow werden die Verschwendungen des Prozesses sichtbar und es kann an seiner Verbesserung gearbeitet werden. Hätte das Ideal einen Wert in sich, wäre es eine mögliche Option, zur alten Weise der Produktion – zur Manufaktur - zurückzukehren, doch diese Option besteht leider (?) nicht.

Der Tod des Navigators

Wir machen auf der Arbeit regelmäßig ein Coding-Dojo: vier Leute, drei Monate, zwei mal in der Woche anderhalb Stunden, eine Aufgabe, rotierendes Pairprogramming am Beamer. Die Frage nach der Rolle des Navigators, des Beifahrers, beim Pair Programming hat uns dabei schon öfter beschäftigt. Wir rotieren alle 5 Minuten (btw: Minuteur ist ein wuenderbares Tools um das auf dem Mac zu steuern). In der Literatur, in Vorträgen findet sich ein gängiges Muster: Der Fahrer sei zuständig für die taktischen Fragen, der Navigator für die Strategie. Den Fahrer kümmere die Syntax, den Navigator der große Plan, die Route. Obwohl diese Beschreibung sich durchgängig findet, hat das Beschriebene bei uns einfach nicht funktioniert. Das mag  verschiedene Gründe haben: falsch angewendet, unerfahren, unqualifiziert, zu wenig Disziplin, eine falsche Vorstellung davon wie es auszusehen hat.

Und nun sind wir auf zwei Studien gestoßen: Pair Programming an the Mysterious Role of the Navigator und The Social Dynamics of Pair Programming. Beide untersuchen die Frage der Kommunikation beim Pair Programming empirisch. Und beide Studien kommen zu dem Ergebnis, dass es die Rollenaufteilung in Navigator und Fahrer nicht gibt. Die Anteile beider Rollen an verschiedenen Ebenen der Betrachtung des Programms sind gleichverteilt. Es gibt keinen Unterschied in dem, was ich betrachte – und dann auch verbalisiere -, der sich aus meiner Rolle ableiten läßt. Und dass obwohl die Beteiligten selber ihre Rollen vor dem Experiment als Fahrer und Navigator beschrieben und der Meinung waren, so funktioniere ihr Pairing. Wenn die Rolle des Navigators als permanentem Code Reviewer oder als Steuermann eine Chimäre ist, was kennzeichnet denn dann das Gespräch zwischen den beiden? Die Rollen seien zumindest nicht sehr unterschiedlich, sehe man einmal vom trivialen Umstand ab, dass der eine die Tastatur hat und der andere nicht. Das Gespräch spiele sich eher auf einer Ebene von ‘abstract chunks of code’ ab. Damit seien Fragen von Namensstandards, Fragen allgemeiner Programmierstrategien, Umsetzungen von Programmstrategien im konkreten Programm gemeint. Der Bereich – so die eine Studie – der ‘abstract chunks of code’ sei der Vermittlungsbereich zwischen der Diskussion über konkrete Methode, Variablen und Syntax auf der einen und Fachdomänen bzw. der Übersetzung von Fachdomänenfragen ins Programm auf der anderen Seite. Pair Programming sei am effektivsten, wenn beide Teilnehmer ständig beide Rollen ausfüllten.

Einen wirklichen Unterschied sieht die eine Studie, wenn erfahrene mit unerfahreneren Programmierern pairen. Bei einem grossen Unterschied werde der unerfahrene Programmierer passiv. Diese Passivität führe dazu, dass er nicht mehr wirklich handle, sondern mehr zuschaue, und nicht mehr viel lerne. Pair Programming eigne sich nicht für den Wissenstransfer bei grossen Unterschieden in der Erfahrung oder Qualifikation. Die eine Studie schliesst eine Beobachtung an, die sie nicht mehr verifiziert, weil sie beendet wurde. Neu ins Team gekommene Programmierer, hätten nicht so viele Probleme die Erfahrenen zu unterbrechen, sie würden nicht so schnell passiv werden, das könne ein Indiz sein, dass bei ihnen der Transfer auch bei einem grossen Wissensunterschied noch funktioniere.

Die Lektüre der zwei Studien wirkte sich befreiend aus. Vorher hatte ich das Gefühl, unsere Betrachtungen müssten in die Richtung eigener Unzulänglichkeiten gehen, warum machen wir das noch nicht richtig. Danach würde ich sagen, die Frage, wie Pair Programming zu lehren uns zu kultivieren sei ist wieder offen oder aber schon beantwortet, weil man sich eben so verständigt, wie man sich verständigt: auf der mittleren Ebene und gleichberechtigt.