Mahil Maurice, Head of Pivotal Labs

Read this article in English.

Mahil Maurice, Chef der Pivotal Labs in San Francisco, erklärt das besondere Konzept des Pair Programming, mit dem Pivotal klassischen Unternehmen agile Methoden beibringt. Er verrät außerdem, welche Fehler Unternehmen vermeiden müssen, damit angeschobene Transformationsprozesse nicht versanden.

Als wir die Pivotal Labs in San Francisco betreten, empfängt uns eine intensive Atmosphäre. Es fühlt sich eng und geschäftig an, ohne hektisch zu sein. Stehpulte stehen dicht an dicht, darauf riesige Bildschirme, auf denen die Teams an Codezeilen und Benutzeroberflächen arbeiten. Jeder Arbeitsplatz wird von zwei Personen gemeinsam genutzt, was auf das besondere Konzept des Pair Programmings bei Pivotal Labs zurückzuführen ist. Während Labs das Framework und die Methodik bereitstellt, gibt es noch die Technologieplattform “Pivotal Cloud Foundry” (PCF). Diese Plattform hilft bei der Transformation unzeitgemäßer, monolithischer Anwendungen in moderne, Microservice-basierte Systeme. Beide Dienstleistungen sind eng miteinander verwoben, wie wir im Gespräch erfahren werden.

Während unseres Besuchs in San Francisco hatten wir die Gelegenheit, mit Mahil Maurice, Chef der dortigen Pivotal Labs, über deren Framework zu sprechen. Mahil leitet das Lab seit November 2018. In diesem Text erfährst du

• wie Pivotal mit Paired Programming klassischen Unternehmen agile Methoden näher bringt.
• auf welchen Grundlagen Pivotal digitale Produkte entwickelt.
• mit welchen Methoden Pivotal Widerstände bei den Kunden überwindet.
• welche Fehler Unternehmen vermeiden müssen, damit angeschobene Transformationsprozesse nicht versanden.

Mahil, kannst du uns zunächst die Grundidee von Pivotal Labs erklären?

Wir tun im Prinzip zwei Dinge: Modernisierung und Innovation. Im Mittelpunkt der Modernisierung steht unsere Plattform, die Unternehmen dabei unterstützt, Software schneller einzusetzen. Dahinter steht unsere Methodik. Es handelt sich um ein fortschrittliches, agiles Framework, das auf der Software Plattform aufbaut.

Unsere Methodik besteht aus drei Dingen: Design, kann ein Benutzer es nutzen? Produkt, ist es wertschaffend? Und drittens, können wir es bauen? Wir haben ein Konzept namens „Balanced Teams“.  Wenn wir in ein Unternehmen gehen, bringen wir einen Produktmanager, einen Designer und ein paar Entwickler mit. Und unsere Kunden tun das Gleiche. Die Idee ist, eines ihrer Teams während der gesamten Dauer der Produktentwicklung weiterzuentwickeln. Dieses Team kann zurück in das Unternehmen gehen, ein anderes Team aktivieren und von da geht es nach diesem Prinzip exponentiell im gesamten Unternehmen weiter. Das ist die Idee hinter unserer Firma.

Also bilden eure Leute mit ihren jeweiligen Kollegen im Unternehmen Zweierteams?

Genau. Oft bekommen wir dabei Fragen wie: „Warum sollte man paarweise arbeiten? Ich kann fünf einzelne Entwickler haben, die mehr arbeiten als zwei deiner Zweierteams.“ Aber innerhalb von zwei bis drei Monaten erkennen viele dieser Unternehmen, wie viel dieser Ansatz bringt. Denn mit der Kopplung werden sie produktiver.

Wir fragen CIOs oft, was sie denken, wie viel ein Entwickler im Unternehmen jede Woche programmiert. Und oft ist die Antwort, die wir bekommen: Wahrscheinlich 20 bis 25 Stunden. Weil sie zu Meetings gehen. Manchmal sind sie auf Facebook. All diese Dinge passieren. Aber wenn wir paarweise arbeiten, dann im Allgemeinen für etwa 35 Stunden. Das ist ziemlich intensiv, weil man reinkommt und plötzlich wird einem gesagt, man solle sich mit jemandem zusammentun, den man nicht kennt. Die Fähigkeiten können unterschiedlich sein. Aber nach etwa zwei, drei Monaten und ein paar Iterationen, wenn die ersten Dingen in die Produktion gehen, erkennen die Leute den Wert dieser Methode und das es funktioniert.

Wir sehen vier Vorteile des Pair Programmings. Erstens: Wir erreichen eine bessere Codequalität. Zweitens: Es gibt eine gemeinsame Ownership. Drittens: Die Leute lösen komplexe Probleme gemeinsam. Und last but not least: Der Übergang nach Abschluss der Projekte ist viel einfacher.

Passiert das auch auf Produktmanager-Ebene?

Es gibt viele Kunden, die zu uns kommen und eigentlich nur vier Entwickler für ein Projekt wollen. Wir versuchen, solche Aufträge zu begrenzen, weil es sich um reine Mitarbeiteraufstockung handelt und die Kunden unsere Methodik und unseren Auftrag nicht voll ausschöpfen.

Die Ebene des Produktmanagers ist entscheidend, da der Produktmanager des Kunden die Stimme des Unternehmens ist.

Uns geht es darum, durch den Einsatz unserer Methodik und der Plattform Ergebnisse zu liefern, die auf das Geschäftsmodell einzahlen.

Und machen die Produktmanager auch die Stories gemeinsam?

Ja, das tun sie. Und sie benutzen unsere Tools dafür. Eins heißt „Pivotal Tracker“, das für unser Framework entwickelt wurde. Entwickler sollten immer die erste verfügbare Story nehmen. Sie können also nicht zur siebten Geschichte gehen und sie herausnehmen, darum müssen die Produktmanager jederzeit die Priorisierung klar vor Augen haben.

Wie sieht das Framework genau aus?

Es umfasst drei Dinge: Lean Product, User-Centered Design und Extreme Programming (XP). Das gesamte Konzept rund um Lean Product ist es, sicherzustellen, dass nicht das Falsche gebaut wird, während man schnell vorankommen möchte. Die zweite Komponente ist User-Centered Design. Über all dem steht die Entwicklung. Das ist die Welt von Extreme Programming, test-driven Development und Continuous Integration, kombiniert mit den Zweierteams, die schnell iterieren.

Die Idee ist, nicht alle gewünschten Funktionen schon nach drei oder vier Monaten zur Verfügung zu haben. Das Risiko ist zu groß, und es gibt auch technische Einschränkungen. Mit unserer Methodik und Plattform können Kunden täglich Features an die Produktion liefern und dabei in kurzen Iterationen arbeiten. So können sie Änderungen mit minimalem Risiko vornehmen. Wenn unsere Kunden hundert Anforderungen haben, bauen wir nicht alle diese Anforderungen am ersten Tag. Wir versuchen, die wertvollsten Anforderungen herauszufinden, bauen diese zuerst und wiederholen dann den Kreislauf.

Wenn wir über Lean Development sprechen, welche Instrumente und Methoden werden bei Pivotal verwendet?

Wenn wir in ein Projekt gehen, heißt die allererste Phase „Discovery and Framing“. Das Konzept bei Discovery ist: Was ist das Problem? Und es gibt viele Probleme. Können wir das auf eine kleinere Anzahl von Problemen reduzieren? Die Framing-Komponente ist: Es gibt viele Lösungen. Können wir es auf eine Teilmenge von Lösungen herunterbrechen?

Die Eingrenzung der Probleme und die Fokussierung auf eine Reihe wertvoller Lösungen erfolgt durch Befragung von Usern, Recherche der Wettbewerber, Lean Experiments, Annahmen und Prototypen mit Anwendern testen, Entwicklung von Personas und durch weitere Methoden aus dem benutzerzentrierten Design. Das Ergebnis ist eine Teilmenge von Stories und Low-Fidelity Wireframes, um den Entwicklungsprozess zu starten. Von hier aus gibt es wöchentliche Iterationen und Feature-Entwicklung, bis wir zum MVP kommen.

Wenn sich der Kunde während des Projekts auf User-centered Design, Lean-Experimente und XP-Methoden einlässt, sind wir auf dem richtigen Weg.

Wie ändert man das Verhalten bei großen Unternehmen, bei denen die Transformation oft ein Top-down-Prozess ist? Das Management hat entschieden, dass aus einem Konzern ein digitales, agiles Unternehmen werden muss. Aber wie nimmt man die Menschen dabei mit?

Das ist die größte Herausforderung, die wir haben. Ich will ganz ehrlich sein: Es ist nicht so einfach mit Konzernen. Der CIO ist voll und ganz dabeil, aber dann treffen wir auf Leute, die ihren CIO nicht wirklich kennen.

Unsere Methodik ist ein Kulturschock für viele. Das ist erstmal nicht einfach. Die erste Hürde ist also, die Kollegen dazu zu bringen mitzumachen. Es gibt immer Widerstand dagegen, etwas Neues auszuprobieren, die Angst, etwas anderes zu tun, und den Drang, zu dem zurückzukehren, was man gewohnt ist. Das sind alles Elemente, mit denen wir uns bei den meisten Projekten beschäftigen. Aber sobald wir mit den Zweierteams beginnen, sehen sie die Vorteile der Methode, denn sie führt zu Ergebnissen.

Da das Paarprogrammieren so wichtig ist, testen wir die Entwickler während unseres Einstellungsprozesses sehr gründlich auf Teamfähigkeit. Wir suchen nach den grundlegenden Werten aus dem Extreme Programming: Communication, Courage, Simplicity, Respect und Feedback. Nicht jeder besteht diesen Lackmustest. Das Pairing selbst ist sehr intensiv. Daher ist es für den Erfolg unerlässlich, die richtigen Entwickler zu haben, die sich in ihre Partner einfühlen können und sie mitziehen, so dass beide voneinander lernen können.

Gibt es noch andere Dinge, um die Unternehmenskultur zu verändern?

Wir laden alle unsere Kunden ein, die Projekte in unseren Labs zu machen. Um die Methodik zu verstehen, muss man ganz in sie eintauchen. Wenn man an unserem Standort ist, kann man sich ganz auf das Projekt konzentrieren, ohne durch das eigene Büro abgelenkt zu werden.

Es gibt viele softe Dinge, die zur Kultur beitragen. Wir beginnen jeden Tag um 8.30 Uhr und frühstücken zusammen. So können wir mit ungezwungenen Gesprächen in den Tag kommen. Um 9:06 Uhr an jedem Tag haben wir ein Labs wide Stand-up für zehn Minuten. Sobald dies abgeschlossen ist, gehen die Teams in die Stand-ups in ihren Projekten. Jeder Montag beginnt mit Iteration Planning, ab dann daily Stand-ups und schließlich jeden Freitag eine Retro.

Die Teams machen kurze Pausen, spielen Tischtennis oder gehen spazieren. Wir haben jeden Tag 15-minütige Mini-Talks, die von einem unserer Mitarbeiter bei Pivotal zu verschiedenen Themen gehalten werden. Und das Büroteam plant auch immer viele Aktivitäten. Eine Stunde Mittagessen ist ein Muss, und wir arbeiten acht Stunden. Der Tag ist um 18 Uhr zu Ende. Wir legen großen Wert auf die Work-Life-Balance unserer Teams. Die Menschen müssen sich wohlfühlen, um in einem so intensiven Umfeld zu funktionieren. Wir ermutigen unsere Kunden, diese Dinge als Teil des Change-Prozesses zu übernehmen.

Wirklich agil zu arbeiten und die Prozesse am Leben zu halten, die in das Unternehmen eingebracht wurden, ist der schwierige Teil. Was sind typische Fehler, die Unternehmen machen, sobald sie digitale Produkte auf eigene Faust entwickeln müssen?

Am Ende des Tages ist die digitale Komponente nicht so schwer. Es gibt Hardware, es gibt Software, die dabei helfen können. Ich denke, woran es oft scheitert, ist die richtigen Leute einzustellen, ein vernünftiges Business Modell zu schaffen und die richtigen Anreize in der Firma zu setzen. Das muss im gesamte Unternehmen passieren.

Viele Unternehmen denken, dass sie nur die Technologie verändern müssen. Aber sie sehen nicht die strukturelle Perspektive.

Die Unternehmen, die es gut machen, haben ein separates Innovation Lab gegründet. Dort kann ohne Denkverbote gearbeitet werden. In solchen Labs werden Veränderungen zuerst gelebt. Von da kann in kleinen Schritten und über Projekte und Tools die Methode in die größere Organisation transferiert werden. Es entstehen mehr Balanced Teams und die verändern die Art und Weise, wie Software entwickelt wird.

Das finde ich interessant, dass du Innovation Labs hervor hebst. Das machen so viele Unternehmen, dass es schon zu einem Buzzword geworden ist. Aber du sagst, dass es wirklich wichtig ist, die digitale Unit auszulagern und den Menschen die Möglichkeit zu geben, in einem geschützten Raum zu arbeiten.

Ja, und das kann ich deshalb sagen, weil ich vor Pivotal ein solches Innovation Lab in einem Konzern aufgebaut habe. Und ich würde sagen, wir haben viele Dinge gut gemacht. Wir waren weit weg von der Geschäftsleitung. Wir hatten herrliche Räumlichkeiten. Der CEO hat mir gesagt: „Stell’ die richtigen Leute ein und bau’ eine Innovationsmaschine auf.“ Die eine Sache, die wir nicht gut gemacht haben, war, dass wir nicht das passende Framework hatten. So kam ich damals mit Pivotal in Kontakt.

Zu oft fehlt das Framework. Es ist eine andere Denkweise. Build fast, fail fast. Verschwende keine sechs Monate und fünf Millionen Dollar und scheitere dann. Du solltest in der Lage sein zu scheitern, nachdem du zehntausend Dollar ausgegeben und einen Prototyp gebaut hast. Das ist für viele Menschen schwer zu verstehen. Du musst das richtige Mindset dafür haben und verstehen, dass du dich auf einer Reise befindest, die dem Unternehmen hilft, im Wettbewerb zu bestehen, relevant zu bleiben und zu wachsen.

Was braucht es noch dafür, um diesen Prozess zu meistern?

Der Schlüssel ist der vollständige Buy-in und die Unterstützung durch das ganze Managementteam. Das reicht von der Spitze bis runter zu den einzelnen Akteuren. Häufig will der CIO oder VP Digital die Veränderung. Aber sie geben dem mittleren Management nicht die dafür nötige Sicherheit, die nötige Weiterbildung und die Vision mit. Wir stoßen dann auf das, was wir “frozen middle” nennen. In so einer Situation ist es sehr schwer für uns, die Leute mitzunehmen.

In größeren Unternehmen kommt der Wandel allmählich durch viele Projekte über die gesamte Organisation hinweg, so dass viele Balanced Teams entstehen. Das Management muss seine Mitarbeiter dabei unterstützen, in diesem Wandel zu experimentieren. Viele trauen sich nicht, weil sie das Risiko scheuen. Das wahre Risiko ist jedoch, wie es sich auf die Geschäftsmodelle auswirkt, wenn Sie den Weg hin zu diesem Wandel gar nicht entdecken.

Mahil, danke für das Interview.