Zum Inhalt springen
Mark Bregenzer

Über mich

Ich beschäftige mich mit einer Frage.

Wie müssen Organisationen gestaltet und geführt werden, damit sie unter Bedingungen von Dynamik und Komplexität wirksam handeln und lernen können?

Mark Bregenzer

Diese Frage ist nicht aus einem Buch entstanden. Sie ist über dreißig Jahre gewachsen, und sie war am Anfang eine viel kleinere.

Ein Auftrag, ein Kunde, ein Ergebnis

Angefangen habe ich mit einer Ausbildung zum Fernmeldeelektroniker bei Siemens in Mannheim. Ich konnte sie als Frühauslerner sechs Monate früher abschließen und wurde danach als Eilmonteur eingesetzt: ein Firmenwagen, eine Liste mit Kundenaufträgen, der Rest lag bei mir. Material beschaffen, Termine vereinbaren, Kabel verlegen, Systeme programmieren, dem Kunden die Anlage erklären, den Auftrag zur Abrechnung vorbereiten.

Meine Verantwortung endete nicht mit der technischen Umsetzung. Der Arbeitsplatz des Kunden musste hinterher in einwandfreiem Zustand sein. Wenn mir etwas auffiel, das formal nicht zum Auftrag gehörte, für ein überzeugendes Gesamtergebnis aber wichtig war, kümmerte ich mich darum.

Ich wusste damals nicht, dass ich End-to-End-Verantwortung übte. Ich wusste nur, dass es mir Freude machte, wenn beim Kunden am Ende etwas Vollständiges stand.

Wenn es funktioniert

Nach dem Studium der Nachrichtentechnik an der Fachhochschule Karlsruhe wechselte ich 1997 zu Siemens nach München, als Softwareingenieur. Von Mannheim aus hatte man immer von den Spezialisten in München gesprochen. Für mich fühlte sich der Schritt an wie der Wechsel von der Kreisklasse in die Champions League.

Das Telekommunikationssystem, an dem ich arbeitete, war zu groß, als dass ein einzelner Mensch es hätte überblicken können. Wenn ich weiterhin ein Ergebnis von Anfang bis Ende verantworten wollte, brauchte ich eine andere Perspektive. Ich fand sie auf der Ebene eines Features und seines Kundennutzens.

An einen Moment erinnere ich mich besonders gut. Ich rief von einem DECT-Telefon ein anderes an. Die Verbindung kam nicht zustande. Kurz darauf leuchtete am angerufenen Telefon das Briefsymbol auf. Ein Tastendruck, die Nummer des verpassten Anrufers wurde gewählt, die Verbindung stand.

Es funktionierte.

Ich hatte nicht Code geschrieben und keine Komponente fertiggestellt. Ich konnte das vollständige Kundenfeature benutzen. Aus einer Anforderung und vielen technischen Schritten war ein sichtbarer Nutzen geworden.

Wo Können an Bedingungen stößt

Im Jahr 2000 wechselte ich in die Mobilfunksparte, an den Radio Commander, ein Managementsystem für große Mobilfunknetze. Ein international verteiltes System an drei Standorten mit über 200 Entwicklern. Bis 2007 war ich dort Entwickler, Sub-System Owner und Teilprojektleiter. Technisch lernte ich viel. Gleichzeitig wuchs die Entfernung zwischen meiner Arbeit und dem, was am Ende jemand nutzte.

In dieser Zeit wurde mir etwas bewusst, das meinen Blick bis heute prägt. Viele Schwierigkeiten, mit denen wir kämpften, entstanden nicht aus technischer Komplexität. Sie entstanden aus Strukturen, aufgeteilten Verantwortlichkeiten und einer Projektlandschaft, die Abhängigkeiten und Zielkonflikte erzeugte. Menschen arbeiteten engagiert an ihren Aufgaben und kamen trotzdem nur schwer zu einem stimmigen Gesamtergebnis.

Die Menschen, die diese Bedingungen festlegten, waren für mich damals weit weg. Ich sah keinen Weg, daran etwas zu ändern, und konzentrierte mich auf meinen Einflussbereich.

Ein Satz meines Vorgesetzten aus dieser Zeit ist mir geblieben. Er übertrug mir ein Projekt, obwohl ein Kollege fachlich die naheliegendere Wahl schien. Auf meine Frage, warum, antwortete er sinngemäß:

Ich möchte, dass du das machst. Dann weiß ich, dass etwas dabei herauskommt, das wirkt, und dass nicht endlos nach der besten und schönsten Lösung gesucht wird, ohne dass jemals ein echtes Kundenfeature entsteht.

Darauf war ich mächtig stolz. Und es beschreibt bis heute, worauf es mir ankommt: Die technisch schönste Lösung entfaltet keinen Wert, solange sie den Kunden nicht erreicht.

Dass es auch anders geht

2007 übernahm Nokia die Netzwerksparte von Siemens. Noch vor dem Zusammenschluss wurde mir angeboten, in einem neuen Team an einem Nokia-Projekt mitzuarbeiten. Das Projekt arbeitete mit Scrum und mit Large-Scale Scrum. Für mich war das die erste Berührung mit agiler Produktentwicklung.

Plötzlich war da vieles, was mir vorher gefehlt hatte: gemeinsame Verantwortung für ein Produkt, enge Zusammenarbeit, schnelle Rückmeldung, kontinuierliches Lernen, deutlich mehr Einfluss der Entwickler auf ihre eigene Arbeit.

Als Entwickler fühlte sich das für mich fast wie der Himmel auf Erden an.

Ich erlebte nicht nur eine neue Methode. Ich erlebte ein anderes Arbeitssystem. Diese Zeit war eine der besten meines beruflichen Lebens, und sie ist bis heute der eigentliche Grund für meine Arbeit. Ich möchte anderen Menschen solche Bedingungen ermöglichen.

Die Entscheidung

2009 wurde ich gefragt, ob ich interner Agile Coach werden wollte. Meine erste Reaktion war nicht nur Begeisterung. Die Entscheidung erschreckte mich, weil sie bedeutete, mich weiter von der technischen Arbeit zu entfernen. Software zu entwickeln und funktionierende Produkte zu erschaffen war ein wichtiger Teil meiner beruflichen Identität.

Also stellte ich mir eine grundlegendere Frage: Was bereitet mir eigentlich Freude, in meiner Arbeit und in meinem Leben?

Ich war damals Vater von drei Töchtern. Ich dachte über meine Erfahrungen mit meinen Kindern, mit Kolleginnen und Kollegen und im Sport nach, und erkannte ein Muster. Am meisten Freude machte es mir, Menschen bei ihrer Entwicklung zu begleiten und ihnen zu helfen, über das hinauszuwachsen, was sie sich zugetraut hatten.

Damit war die Sache klar.

Die Organisation wurde in dieser Zeit von Bas Vodde und Craig Larman begleitet. Ich habe organisationale Veränderung deshalb nicht aus Büchern kennengelernt, sondern über mehrere Jahre als Mitarbeiter, Entwickler, Scrum Master und interner Coach. Ich kenne Transformationen aus der Sicht derer, deren tägliche Arbeit sich verändert, und aus der Sicht derer, die sie gestalten. Ich weiß, welche Energie entsteht, wenn Menschen mehr Verantwortung und Feedback bekommen. Und ich kenne die Unsicherheit, wenn vertraute Rollen und Teile der eigenen beruflichen Identität infrage stehen.

LeSS, ohne es so zu nennen

Als sich abzeichnete, dass die Telekommunikationsentwicklung nach Asien wandern würde, stellte sich die nächste Frage: Wie werde ich ein besserer Coach? Die Antwort war dieselbe wie zuvor als Entwickler. Durch Praxis, und zwar durch möglichst unterschiedliche. Ich wollte verstehen, welche Probleme aus einem konkreten Kontext entstehen und welche Muster sich über Organisationsgrenzen hinweg wiederholen. Also wechselte ich 2011 zu Valtech.

Eines meiner ersten Projekte dort war die Unified Sales Platform bei der BMW Group. Ich verantwortete den agilen Prozess, und wir brachten Large-Scale Scrum mit zwei erfolgreichen Go-lives zum Einsatz.

Craig Larman kam in dieses Projekt. Er sah sich die Organisation an und die Veränderungen, die wir gemeinsam mit den Beteiligten eingeführt hatten. Und stellte fest, dass ich wesentliche Elemente von Large-Scale Scrum umgesetzt hatte, ohne das Vorgehen jemals so genannt zu haben.

Diese Beobachtung war mir wertvoll. Ich hatte keiner Organisation ein Framework übergestülpt. Ausgangspunkt waren die Situation, die erkennbaren Probleme und die Frage, welche Strukturen zu mehr End-to-End-Verantwortung, Lernen und Kundenwert führen. Auf diesem Weg war eine Gestaltung entstanden, die wesentlichen LeSS-Prinzipien entsprach.

Diese Arbeit war der Anlass. Der Weg dorthin führte über das Schreiben der öffentlichen Fallstudie. Das klingt nach Dokumentation, war aber das Gegenteil: Erst beim Schreiben musste ich begründen, warum welche Entscheidung getroffen wurde und was sie bewirkt hat. Craig hat mich dabei begleitet und meine Entwicklung unterstützt. Aus der Zusammenarbeit wurde ein Mentoring, und Craig wurde offiziell mein Mentor auf dem Weg zum Certified LeSS Trainer.

Der Zertifizierungsprozess dauerte rund eineinhalb Jahre und gehörte zu den härtesten und frustrierendsten Phasen meiner beruflichen Entwicklung. Craig war in seinen Qualitätsansprüchen unerbittlich. Immer wieder dachte ich, dass ich es womöglich nicht schaffen würde. Gleichzeitig wusste ich: Selbst wenn nicht, lerne ich in diesem Prozess so viel, dass ich danach auf einem deutlich höheren Niveau arbeiten werde.

2015 wurde ich der erste deutschsprachige Certified LeSS Trainer.

Von Menschen zu Organisationen

Von 2011 bis 2023 war ich bei Valtech als Principal Consultant. Dort baute ich die Practice Organizational Design & Cultural Change auf und führte sie fachlich. Am Anfang waren wir vier Personen mit agilem Wissen, aber niemand von uns hatte zuvor als Agile Coach oder Scrum Master gearbeitet. Die anderen kamen aus der Architektur und dem Projektmanagement. Daraus wurde eine Einheit mit mehr als 25 Coaches.

Dazu gehörten Recruiting, Mentoring, Karrierepfade, gemeinsame Qualitätsvorstellungen und die wirtschaftliche Verantwortung. Am wichtigsten war mir dabei nicht das Wachstum, sondern dass eine Struktur entstand, die zunehmend unabhängig von einzelnen Personen handeln konnte.

In den Mandaten arbeitete ich mit Entwicklern, Teams, Führungskräften und Executive Teams, von einzelnen Teams bis zu Transformationen mit mehr als 1.000 Beteiligten. Dabei zeigte sich immer wieder: Viele Herausforderungen, die wie Probleme einzelner Menschen, Teams oder Methoden aussehen, lassen sich nur verstehen, wenn man Strategie, Struktur, Führung, Entscheidungswege, Produktentwicklung, Architektur, Kompetenzen und Anreize zusammen betrachtet.

Seit 2021 bin ich zusätzlich selbständig gewesen, seit 2023 ausschließlich. Heute arbeite ich als unabhängiger Berater, Coach und LeSS Trainer für Unternehmen unterschiedlicher Größe und Branchen.

Netzwerk und Lehre

Seit 2017 halte ich als Gastdozent Vorträge und Workshops zu Organisationsdesign und Kulturwandel an der Business School der OTH Amberg-Weiden, im Masterstudiengang Digital Leadership & Transformation. Dort arbeite ich mit Prof. Dr. Bernt Mayer zusammen. Mit ihm ist auch das Modell für gleichwertige fachliche und disziplinarische Entwicklungswege entstanden.

Ich bin selbständig, aber ich arbeite nicht allein. Mit mehreren Partnern in Deutschland und Österreich arbeite ich seit Jahren zusammen, und in der LeSS Community bin ich als Mitorganisator aktiv. Wenn ein Mandat größer wird, als eine Person es tragen kann, kann ich skalieren.

Mein Netzwerk

Die Frage wird größer

Aus

wie werde ich ein besserer Entwickler

wurde

wie entwickeln wir bessere Produkte

Daraus wurde

welche Bedingungen brauchen Menschen, um Verantwortung zu übernehmen, zu lernen und gute Arbeit zu leisten

Und schließlich

wie müssen Organisationen gestaltet und geführt werden, damit sie unter Bedingungen von Dynamik und Komplexität wirksam handeln und lernen können

Diese letzte Frage beschreibt den Kern meiner heutigen Arbeit.

Was mich antreibt

Ein wesentlicher Teil meiner Motivation ist der Beitrag zur langfristigen Wettbewerbs- und Zukunftsfähigkeit Europas. Europa steht in einem intensiven technologischen, wirtschaftlichen und geopolitischen Wettbewerb. Unternehmen und Institutionen brauchen die Fähigkeit, auch unter schwierigen Bedingungen eigenständig, innovativ und wirksam zu handeln.

Diese Motivation ist persönlich. Ich möchte dazu beitragen, dass meine drei Töchter und ihre Generation in Europa eine lebenswerte Zukunft und gute, angemessen bezahlte Arbeit finden.

Organisationen sollen ihre Zukunft aus eigener Kraft gestalten können. Wirtschaftlich leistungsfähig, technologisch souverän, menschlich attraktiv, anpassungsfähig und resilient.