Der musikalische Product OwnerDigitale Leute bei Native Instruments: Steffen Dierolf

Steffen Dierolf, 36, ist seit über fünf Jahren bei Native Instruments und seit August 2015 Product Owner. Er ist verantwortlich für das neuste Produkt in ihrer Hardware-Controller Produktpalette: Die Maschine Jam. Agile Produktentwicklung ist erst seit kurzem Thema bei Native Instruments. Grund genug uns den Produkt-Entwicklungsprozess anzuschauen und Steffen Dierolf als Owner zu interviewen.

Dieses Interview erschien zuerst auf unserem neuen Magazin digitale-leute.de. Dort schauen wir mit einer neuen, frischen Perspektive auf die deutsche Digitalszene. 

————

Hallo Steffen, du warst jetzt zum ersten Mal als Product Owner für die Entwicklung eines Produkts zuständig. Wie fühlt sich das im Vergleich zu deinen früheren Jobs bei Native Instruments an?

Die finale Unit in der Hand zu halten ist schon ein ganz anderes Gefühl, wenn man von Anfang an dabei gewesen ist. Das Konzeptionelle hatte mich in meiner vorherigen Rolle als Quality Assurance-Mitarbeiter nicht erreicht und ich war früher viel später involviert.

Was sind denn die Unterschiede zwischen einem Produkt Owner bei einem Hardware-Projekt und einem reinen Software-Projekt?

Nach unserer Erfahrung kann das Hardware-Development niemals so agil sein wie ein reines Software-Projekt. Das wird immer zu einem gewissen Grad ein Wasserfall bleiben. Wenn sich zum Beispiel herausstellt, dass man die falsche Komponente geordert hat, dann verzögert sich das gesamte Projekt bis man die passende Komponente gefunden hat.

Spannend ist, beide Ansätze miteinander zu verbinden. Das ist die aktuelle Herausforderung, der wir uns bei Native Instruments stellen: Wie schaffen wir es auf der einen Seite unseren Teams nur Problembeschreibungen zu geben, während wir auf der anderen Seite ein Hardware-Layout haben, das frühzeitig in Stein gemeißelt wird?

Das heißt, es können später keine Änderungen an der Hardware durchgeführt werden? Alle Knöpfe und Regler bleiben wo sie sind?

Genau, dieses Layout müssen wir relativ früh einfrieren. Was wir ändern können sind die Label, was wir uns auch recht lange offen halten. Zum Beispiel hatten wir bei der Jam die Idee, über die Touchstrips auch Noten spielen zu können. Bei ein paar Hackdays haben wir das reingehackt, um einen Eindruck davon zu bekommen, ob das funktioniert. Wir fanden das so gut, dass es zuletzt seinen Weg in das Produkt gefunden hat. Für einen Button hat das bedeutet, dass wir die Beschriftung geändert haben. Die ursprüngliche Funktion, die auf dem Button lag, wanderte dann auf ein Shift-Label.

An wen richtet sich euer neues Produkt Maschine Jam?

Unsere bisherigen Maschine-Produkte sind grundsätzlich für Producer aller Genres geeignet, aufgrund ihres Workflows sind sie aber besonders im Bereich Urban und Hip Hop beliebt. Die Maschine Jam richtet sich eher an Studios und Producer elektronischer Musik. Wir wollen uns ein bisschen mehr an den Programmierer statt an den klassischen Musiker wenden.

Auf den bisherigen Devices wird viel mit Fingerdrumming gespielt. Darum haben wir mit dem Layout der Pads einen neuen Weg beschritten und statt Pads Buttons genommen und statt 4×4 ein 8×8 Layout gewählt.

Jam ist ein Device mit dem man den gesamten Track im Auge hat, während die anderen Devices eher ins Detail gehen. Darum ergänzen sie sich auch super.

Seit wann wird bei Native Instruments mit agilen Methoden gearbeitet?

Noch gar nicht so lange. Ich war der Erste, der den Scrum Master Titel bei Native Instruments hatte und konnte so bei der Einführung und Umstrukturierung helfen. Was wirklich geholfen hat, war die Zertifizierung durch die Scrum Alliance, denn der Workshop hat mich persönlich weitergebracht. Ich komme selbst aus der Entwicklung und deshalb fand ich agile Entwicklungsmethoden immer total spannend, weil es die Engineers mehr einbezieht und auch mehr motiviert. Bei der Einführung war das ganze Team beteiligt.

Mit welchen Problemen hattet ihr bei der Einführung zu kämpfen? Welche Learnings konntet ihr aus dem Prozess ziehen?

Wir haben versucht die Einführung von agilen Methoden behutsam zu gestalten und haben uns dazu auch ein wenig externe Hilfe geholt. Zunächst gab es ein großes Standup. Dann fingen wir damit an, Schätzungen auf Tasks und Stories zu packen und die ersten kleinen Teams zu bilden. Da hat sich dann schon gezeigt, dass Scrum nur Sinn macht, wenn das Dreieck aus Team, Product Owner und Scrum Master vollständig ist.

Ein weiteres Thema war Ownership. In Scrum liegt deutlich mehr Verantwortung im Team als mancher gewohnt war.

Es hat eine Weile gedauert bis erkannt wurde, dass es nicht nur mehr Verantwortung gibt, sondern auch mehr Freiheit.

Die Anzahl der Meetings war am Anfang auch problematisch, weil wir parallel weiterhin Maschine entwickeln mussten. Das wichtigste Meeting aus dem Scrum-Katalog ist für uns die Retrospektive. Ohne die wären wir heute nicht wo wir sind.

Was genau ist deine Aufgabe bei Native Instruments?

Aktuell bin ich Product Owner für Maschine Jam, was bedeutet, dass bei mir alle Fäden zusammenlaufen. Ich bin im Kontakt mit unseren Hardware-Engineers, bin zuständig für die Software-Integration, arbeite mit dem Scrum-Team eng zusammen und bin der Ansprechpartner für Marketing, Sales und Sounddesign. Davor war ich Scrum Master, Projektmanager und in der Qualitätssicherung. Es hat sich hier bei Native Instruments ergeben, dass ich fast jedes Jahr einen neuen Job habe.

Wie bist du zu Native Instruments gekommen? Welche Ausbildung hast du absolviert?

Angefangen hat alles mit einer klassischen Toningenieurs-Karriere. Nach dem Abi habe ich beim nächst größeren Tonstudio eine CD mit Beats eingereicht und mich um einen Job beworben. Zwei Wochen später haben die sich tatsächlich gemeldet und mich als Freelancer engagiert. Dort hatte ich immer wieder die Möglichkeit dem Toningenieur über die Schultern zu schauen. Als der Toningenieur dann mal krank war, war ich an der Reihe. Und so bin ich dann reingekommen.

Dort habe ich Native Instruments Produkte mit reingebracht: Ich kenne die Produkte sozusagen von Anfang an und Native Instruments war auch schon immer eine Traum-Company, in der ich arbeiten wollte. Außerdem war ich noch als tourender DJ unterwegs, hatte eine eigene Radiosendung für sechs Jahre und habe DJs aus Deutschland, Österreich und der Schweiz bei mir in der Sendung gehabt.

Dann habe ich alle meine Platten und Plattenspieler auf einen Schlag verkauft, um mir Produktionsequipment zuzulegen und machte mich in Berlin mit Postproduktion selbstständig, also Mixing und Mastering.

Ich hatte mir aber das Ziel gesetzt spätestens mit 30 entweder nicht mehr 60 Stunden die Woche arbeiten zu müssen, oder mir eine vernünftige Arbeit zu suchen.

So kam es, dass ich für eineinhalb Jahre einen Ausflug nach Dänemark zu TC Electronic gemacht habe. Ich glaube, das hat schließlich meinen Einstieg bei Native Instruments möglich gemacht, denn TC Electronic ist einer der Weltmarktführer für Musikhardware. Da konnte ich dann auf einem Gebiet einfach Erfahrung vorweisen. Bei Native Instruments habe ich dann erst mal bei der Quality Assurance angefangen.

Bist du eigentlich Musiker?

Vor ein paar Jahren hätte ich gesagt, dass ich das bin. Inzwischen würde ich sagen, das mein Hobby Musiktechnologie ist. Ich mache noch immer an mehreren Tagen die Woche Musik, probiere neue Sachen aus, die auf dem Markt sind, habe aber seit über einem Jahr keinen Song mehr fertig gestellt.

Wie sieht dein Alltag bei Native Instruments heute aus?

Unser Tagesablauf richtet sich nach dem Scrum-Workflow. Wir haben eine Kadenz, das heißt, unsere Firma tickt im zwei-Wochen-Rhythmus. Alle zwei Wochen gibt es eine große Demo, bei der jedes Team auf die Bühne geht und zeigt, was erreicht wurde. Das ist mein Startschuss, denn dann geht es in die Planung mit den Teams, bei der wir uns die Backlog anschauen.

Das ist immer auch ein bisschen Verhandeln, denn wir versuchen ein Agreement zu erreichen, das realistisch und in zwei Wochen zu erreichen ist. Ich schreibe dabei keine Spec, sondern beschreibe die Probleme. Das Team kommt dann mit der Lösung. In den zwei Wochen bin ich für das Team ansprechbar, in denen wir zum Beispiel über verschiedene Lösungswege sprechen.

Das Spezielle bei uns ist zudem, dass wir einen skalierten Ansatz fahren. Im klassischen Scrum-Ansatz gibt es einen Product Owner und ein Entwicklungsteam. Bei uns ist es aber so, dass ich als Product Owner wiederum Mitglied in einem Team bin, einem crossfunktionalen Team. Der Owner ist dann der Programe Owner. In diesem Team sind Mitlieder aus Marketing, Sales und Controlling und weitere Product Owner.
In diesem Team arbeiten wir viel mit einem Modell, das Lean Canvas heißt, was meist der erste Schritt zu einem neuen Produkt ist. Für diesen Prozess versuchen wir an so viele Zahlen wie möglich zu kommen, nutzen dafür aber auch Erfahrungswerte.

Vielleicht kannst du das mal an der Entwicklung von Maschine Jam erläutern.

Uns war von Anfang an klar, dass wir eine neue Kategorie einführen wollten, denn mit dem 4×4 Layout stößt man an Grenzen, beziehungsweise kann nur bestimmte Usergruppen ansprechen. Klassischerweise sind viele andere Hardware-Controller auf acht oder ein Vielfaches von acht ausgelegt. Schon ganz klassische Controller, die es schon seit über zwanzig Jahren gibt, haben acht Fader und lassen sich mit weiteren acht erweitern. Acht macht musikalisch durchaus Sinn.

Wie habt ihr dann versucht das Layout umzusetzen?

Neu bei der Entwicklung der Maschine Jam war, dass wir ein Prototyping mit einem Touchscreen gemacht haben, bevor wir die Hardware vorliegen hatten. Dafür haben wir uns eine Ladung Touchscreens geholt und dort Funktionen emuliert. Früher haben wir das mit Papier getestet. Das mit den Touchscreens war aber genial, denn wir hatten bereits richtige Funktionalität implementiert.

Zum Beispiel hatten wir da bereits den Step-Sequencer laufen. Bis wir auf die echte Hardware gegangen sind, hatten wir also mehrere Tage Zeit Funktionalität zu entwickeln, die wir dann direkt auch nutzen konnten. Das war großartig.

Wie wurde die Hardware entwickelt?

Unsere Hardware-Abteilung entwickelt zum Beispiel das Leiterplatten-Design, Industrial-Design, Mechanical Engineering, und übernimmt auch das Firmware-Development. Das ist ein sehr erfahrenes Team, wo ich das Projekt nur anzustoßen brauche, damit es läuft.

Als nach vielen Gesprächen klar war, dass wir ein 8×8 Grid haben wollen, hat einer unserer erfahrenen Produkt-Designer, der bereits beim Design des ersten Maschine-Produkts beteiligt war, einen Layout-Entwurf gemacht. Ab dem Zeitpunkt stand dann das Knopf-Layout fest, dass wir über den Touchscreen-Prototypen nochmal evaluiert haben. Im nächsten Schritt ging das dann an den Industrial-Designer, der das Produkt ausarbeitet und sich dabei viel mit dem Mechanical Engineering unterhält. Wir wollten das Produkt zum Beispiel dünner machen. Der Industrial-Designer prüft dann, ob das realistisch ist.

Das Hardware-Layout steht von Anfang an fest.

Parallel dazu läuft dann auch schon das Electrical Engineering, bei dem wir Leiterplatten bestücken und einen ersten Prototypen erstellen. Vom ID-Design machen wir dann ein reines Plastik-Gerät, was keine Funktion hat, aber das wir brauchen, um den Formfaktor zu überprüfen und einen Eindruck von der Anmutung zu bekommen. Dabei gilt es immer an die Workflows zu denken.

Wenn der Prozess mit dem ID-Mockup abgeschlossen ist, erstellen wir den ersten richtigen Prototypen für die Engineering Validation.

Wann ist dann die erste verkaufsfertige Version verfügbar?

Zunächst müssen wir noch die Design Verification abschließen. Das Electrical Engineering stellt sicher, dass das auch alles so funktioniert, wie wir uns das gedacht haben. Dann bauen wir ein paar weitere Prototypen, aber die bauen wir noch immer hier in Berlin. Die sogenannte Pilot Production findet dann vor Ort in China statt, wo wir prodzieren lassen, und dient als Vorbereitung für die Massenproduktion. Ein Team von uns ist dann vor Ort in China und hält zum ersten Mal das fertige Produkt in der Hand.

Mit welchen Tools organisiert ihr eure Workflows?

Für die Entwicklung benutzen wir Jira als Ticketsystem. Wo es dann ein bisschen übertrieben erscheint Jira zu nutzen, greifen wir zum Beispiel im Marketing und Sales auch gerne auf andere schlankere Tools zurück. Seit vier Wochen nutzen wir zudem Slack und es ist schön zu sehen, dass es jetzt eine ausgereifte Lösung gibt, mit der alle einverstanden sind. Vorher hatte beinahe jede Gruppe verschiedene Tools.

Welche Arbeitsmittel brauchst du, um gut arbeiten zu können?

Ohne Jira könnte ich nicht arbeiten. Aber ohne Post-Its geht gar nichts. Das liegt vielleicht an meinem Scrum-Hintergrund, dass ich ein Post-it Verfechter bin. Ich finde es super, wenn alles transparent an der Wand ist. Ich hatte mal die „Getting-Things-Done“ Methode ausprobiert. Letztendlich bin ich aber zu Jira und Papier zurückgekehrt.

Als Arbeitsgerät nutze ich einen Mac und wegen meiner Quality Assurance Vergangenheit habe ich noch einen PC. Ich finde es charmant beides zu haben, um Sachen ausprobieren zu können.

Was sind für dich wichtige Themen und Trends, die dich bei deiner Arbeit beschäftigen?

Generell kann man sagen, dass wir uns noch immer in der Transition zur agilen Methode befinden und ich denke, dass diese nie komplett abgeschlossen sein wird.

Neu für mich als Product Owner ist die Kommunikation mit unseren Usern. Das gab es sicherlich auch schon in der Vergangenheit, hat für mich jetzt aber eine andere Wertung. Da stellen sich Fragen nach der Methode und der Auswertung. Wie viel Feedback brauche ich, um eine gute Entscheidung treffen zu können?

Testing ist ein weiterer wichtiger Punkt bei Native Instruments. Testautomation, gerade in Bezug auf unsere Units, ist eines der Ziele. Als ich bei Native Instruments angefangen habe, wurde fast ausschließlich manuell getestet. Das hat sich inzwischen geändert, muss aber auch noch weiter entwickelt werden.

Ganz generell sind die aktuellen Entwicklungen auf dem Musik-Industrie Markt sehr spannend. Ein gutes Beispiel sind die modularen Synthesizer. Das ist ein riesiger Trend zu einer Zeit, in der es eigentlich eher um Software geht. Da geben die Leute hunderte von Euro für einzelne Module aus, die sie dann zusammenstecken, damit sie ein System haben, um einen einzigen Sound zu produzieren. Ich bin sehr gespannt wohin sich das entwickelt. Für uns ist das natürlich ein toller Trend, denn er zeigt, dass die Leute Geräte zum Anfassen haben wollen.

Gibt es Bücher oder Blogs, die du empfehlen kannst?

Das Buch “Agile Product Management with Scrum” von Roman Pichler über Product Ownership ist ein Buch an dem man nicht vorbeikommt, wenn man sich gerade neu mit dem Thema beschäftigt. Zu Scrum generell lese ich keine Blogs, habe aber einige Bücher gelesen. Eines, das ich toll fand, war „Coaching agile Teams“ von Lyssa Adkins. Das Buch “The Professional Scrum Master’s Handbook” von Stacia Viscardi ist auch sehr zu empfehlen.

Außerdem nutze ich viel Google, um nach Problemen zu suchen.

Haben eigentlich bei Native Instruments alle Mitarbeiter einen musikalischen Hintergrund?

Es ist nicht erforderlich Musiker zu sein, um bei Native Instruments arbeiten zu können. Aber ich glaube, es erleichtert den Alltag hier deutlich. In der Tat arbeiten viele Musiker bei uns, eine genaue Zahl kann ich aber nicht sagen. Die Leute arbeiten hier, weil sie hier arbeiten wollen und nicht, weil sie zufällig Entwickler sind und Native Instruments nach Entwicklern sucht.

Ich habe zum Beispiel das große Glück mit einem Team zusammen zu arbeiten, in dem alle die Produkte nutzen. Wenn ich mir jetzt vorstelle, dass wir im Sinne unserer agilen Entwicklung Userinterviews durchführen würden, aber die Antwort nicht nachvollziehen könnten, dann wäre das fatal.

Ich glaube es ist enorm wichtig in die Userrolle schlüpfen zu können. Das ist ein Schlüsselelement, egal ob man Entwickler, QA-ler, Produktdesigner oder Product Owner ist.

Vielen Dank für das Interview!

Webseite: Native Instruments