Agile Unternehmen E-Book

Jürgen Hoffmann

• Herausgeber: dpunkt.verlag
• Kategorie: Fachliteratur
• Sprache: Deutsch
• Veröffentlichungsjahr: 2018

Seitenzahl: 277

Beschreibung

Agile Softwareentwicklung ist in vielen Bereichen längst zum Status quo geworden. Die agilen Prinzipien lassen sich jedoch vielfältiger anwenden, um Abteilungen, Unternehmensbereiche oder auch komplette Unternehmen agiler zu gestalten. Solche Unternehmen agieren flexibler am Markt, sind innovativer und bieten ihren Mitarbeitern sinnstiftendere Arbeitsplätze. Das Buch beschreibt, was solche agilen Unternehmen ausmacht, und bietet konkrete Praktiken an, mit denen das eigene Unternehmen schrittweise agiler gestaltet werden kann. Dabei werden viele Fallbeispiele aus der Praxis zur Illustration herangezogen.

Leseprobe

Dr. Jürgen Hoffmann hat seit 2003 Erfahrung mit agilen Methoden und Scrum. Nach der ersten großen Scrum-Einführung in Deutschland bei der WEB.DE AG hat er in den Rollen als Coach, Trainer, Product Owner, Scrum Master und Teammitglied in unterschiedlichen Branchen und Firmengrößen gearbeitet. Diese Erfahrung aus Branchen wie Automotive, Energie, Finanzen, IT & Internet mit Soft- und Hardwareentwicklung fließen in jeden Beratungsprozess ein. Heute arbeitet er als Geschäftsführer und Managementberater bei der Emendare GmbH & Co KG, die er 2013 mitgründete. Als Certified Scrum Trainer (CST) und Certified Enterprise Coach (CEC) ist er Teil einer starken Gemeinschaft von über 280 Scrum-Trainern und Coaches der weltweiten Scrum Alliance®, die in ständigem Austausch miteinander ihre Trainings und Beratungsideen kontinuierlich verbessern und um aktuelle Fragestellungen ergänzen.

Dipl.-Inform. Stefan Roock ist Gründungsmitglied der it-agile GmbH. Ihm ist es in seiner Beratungstätigkeit wichtig, dass sich wirklich etwas ändert – hin zu erfolgreichen Unternehmen mit zufriedenen Mitarbeitern, die sich immer neuen Herausforderungen stellen. Stefan hat seit 1999 die Verbreitung agiler Ansätze in Deutschland maßgeblich mit beeinflusst. Zunächst hat er als Entwickler, später als Scrum Master und Product Owner in Scrum-Teams gearbeitet. Heute gibt er seine Erfahrung als Berater und Trainer weiter und hilft Unternehmen dabei, agiler zu werden. Neben seiner Beratungstätigkeit für it-agile ist er regelmäßiger Sprecher zu agilen Themen auf Konferenzen, schreibt Zeitschriftenartikel und hat mehrere Bücher veröffentlicht.

Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+:

www.dpunkt.plus

Jürgen Hoffmann · Stefan Roock

Agile Unternehmen

Veränderungsprozesse gestalten,agile Prinzipien verankern, Selbstorganisationund neue Führungsstile etablieren

Jürgen [email protected]

Stefan [email protected]

Lektorat: Christa PreisendanzCopy-Editing: Ursula Zimpfer, HerrenbergSatz: Birgit BäuerleinHerstellung: Susanne BröckelmannUmschlaggestaltung: Helmut Kraus, www.exclam.deDruck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn

Bibliografische Information der Deutschen NationalbibliothekDie Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print

978-3-86490-399-1

PDF

978-3-96088-437-8

ePub

978-3-96088-438-5

mobi

978-3-96088-439-2

1. Auflage 2018

Copyright © 2018 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Jürgen:Für Andrea, Linus und Lenka

Stefan:Für Silke, Mika, Levi und Mailin

Inhaltsübersicht

1Einleitung

2Begeisterte Kunden

3Wertschöpfung als Teamaufgabe

4Unterstützende Organisation

5Organisationsentwicklung

Anhang

AUser Research

BGroße Produkte mit dem LeSS-Framework entwickeln

Literaturverzeichnis

Index

Inhaltsverzeichnis

1Einleitung

1.1Echte Agilität

1.2Agile Fluency

1.3Fokus dieses Buches: echte Agilität oder auch »Optimize Value«

1.3.1Eigenschaften von »Optimize Value«-Unternehmen

1.3.2»Focus on Value« und »Deliver Value«: Literaturempfehlungen

1.4An wen richtet sich das Buch?

1.5Überblick über das Buch

1.6Danksagung

2Begeisterte Kunden

2.1Definieren, was Wert bedeutet und schafft

2.1.1Wert aus Kundensicht

2.1.2Bedürfnisse identifizieren

2.2Drei Horizonte für Wachstum und Innovation

2.2.1Herausforderungen bei der Umsetzung des 3-Horizonte-Modells

2.2.2Das 3-Horizonte-Modell und agile Entwicklung

2.2.3Wert bedeutet in jedem Horizont etwas anderes

2.3Wert in Horizont 1

2.3.1Umsatz als Indikator für Wertschöpfung

2.3.2Net Promoter System (NPS)

2.3.3NPS: Bitte beachten

2.3.4Produktreview/Sprint-Review

2.4Wert in Horizont 2

2.4.1Produktvision

2.4.2Produktreview/Sprint-Review

2.4.3Design Sprints

2.5Wert in Horizont 3

2.5.1Vorgehen in Horizont 3 zur Produkt-/Serviceentwicklung

2.5.2Konkrete Techniken zum Einsatz in Horizont 3

2.6Organisation für das 3-Horizonte-Modell

2.6.1Freiraum in Horizont 1

2.6.2Freiraum in Horizont 2

2.6.3Freiraum in Horizont 3

2.6.4Übergang von Horizont 3 nach Horizont 2

2.6.5Übergang von Horizont 2 nach Horizont 1

2.6.6Personalstrategien der Horizonte

2.6.7Entwicklung in den drei Horizonten

2.6.8Produkt-Roadmaps in den drei Horizonten

2.7Das Kapitel in Stichpunkten

3Wertschöpfung als Teamaufgabe

3.1Eigenständige Teams

3.1.1Manager-led Teams

3.1.2Self-managing Teams

3.1.3Self-designing Teams

3.1.4Self-governing Teams

3.2Funktionsübergreifende Teams

3.2.1Zusammensetzung von Teams

3.2.2Product-Owner-Rolle

3.2.3Teambegleitung

3.2.4Effizienz vs. Effektivität

3.3Entscheidungen im Team

3.4Das Kapitel in Stichpunkten

4Unterstützende Organisation

4.1Störungen durch das Unternehmen

4.2Dezentrale Strukturen

4.2.1Zellmodell in der Praxis der Softwareentwicklung

4.2.2Mehr als ein Team pro Zelle

4.2.3Alles Illusion?

4.3Alignment bei dezentralen Strukturen

4.3.1Management by Objectives (MbO)

4.3.2Objectives and Key Results (OKR)

4.3.3MbO-Beispiel – so bitte nicht

4.3.4MbO-Beispiel – besser

4.3.5Nutzen und Gefahren von Management by Objectives

4.3.6Ziele ohne die MbO-Gefahren

4.4Feedbackschleifen statt statischer Ziele

4.4.1Feedbackschleife für den Umweltschutz

4.4.2Feedbackschleifen bei Command & Control-Strukturen

4.4.3Feedbackschleifen in einem agilen Unternehmen

4.4.4Das Unternehmen als Organismus

4.5Übergreifende Entscheidungsfindung bei dezentralen Strukturen

4.5.1Konsent

4.5.2Advice-Prozess

4.5.3Das Unternehmen verstehen

4.5.4Bewertung und Vergleich von Konsent und Advice-Prozess

4.6Neue Rolle für Führungskräfte

4.6.1Klassische Mitarbeiterführung

4.6.2Probleme klassischer Führung in einer dynamischen Welt

4.6.3Supporting Lines statt Reporting Lines

4.6.4Verteilte Führung

4.6.5Situative Führung

4.6.6Ausbildung

4.7Fallbeispiele zu moderner Mitarbeiterführung

4.7.1ImmobilienScout24

4.7.2sipgate

4.7.3it-agile

4.7.4Zusammenfassung der Fallbeispiele für Mitarbeiterführung

4.8Unternehmenskultur

4.8.1Unternehmenskultur und agiles Arbeiten

4.9Das Kapitel in Stichworten

5Organisationsentwicklung

5.1Organisationsentwicklung als komplexe Aufgabe

5.1.1Satir Change Model

5.2Erfolgsfaktoren für agile Organisationsentwicklung

5.2.1Erfahrungen mit dem Kotter Change Model

5.3Steuerung iterativer Organisationsentwicklung

5.3.1Das agile Transitionsteam

5.3.2Transition Backlog und Product Owner

5.3.3Produktvision und Produktinkremente des Transitionsteams

5.3.4Transitionsteam: Besetzung und Rollen

5.3.5Sprints im Transitionsteam

5.3.6Einbindung ins Unternehmen

5.3.7Weitere Probleme im Transitionsteam

5.4Organisationsentwicklung über Experimente

5.4.1Der PDCA-Zyklus

5.4.2PDCA in der Praxis

5.4.3Organisationsentwicklung als Abfolge von Experimenten

5.4.4Safe-to-Fail-Experimente

5.4.5Experimente erleichtern die Veränderung

5.4.6Organisation der Organisationsentwicklung

5.5Kultur der kontinuierlichen Verbesserung

5.5.1Transparenz in alle Richtungen

5.6Orientierung mit einem Nordstern (True North)

5.6.1Nordstern bei Toyota

5.6.2Nordsterne für die Wissensarbeit

5.6.3Eigenschaften eines guten Nordsterns

5.6.4Arbeiten mit dem Nordstern

5.6.5Nordstern und der PDCA-Zyklus

5.6.6Die A3-Technik

5.6.7Der Weg zum eigenen Nordstern

5.7Das Kapitel in Stichworten

Anhang

AUser Research

A.1Design Thinking konkret

A.1.1Team

A.1.2Raum

A.1.3Prozess

A.2Design Sprints

A.3Lean Startup

A.3.1Die Historie und das Umfeld

A.3.2Kundenbedürfnisse verstehen und Lösung validieren

A.3.3Den Markt validieren

A.3.4Minimum Viable Product (MVP)

A.3.5Pivots

A.3.6Skalierung

A.3.7Fallbeispiel bei it-agile

A.3.8Fazit zu Lean Startup

A.4Das Kapitel in Stichworten

BGroße Produkte mit dem LeSS-Framework entwickeln

B.1Veränderung folgt Notwendigkeiten

B.2Agile Skalierungsprinzipien nach LeSS

B.3Durchstarten zur Skalierung

B.3.1Schule alle Beteiligten

B.3.2Definiere das »Produkt«

B.3.3Definiere, wann es »fertig« ist

B.3.4Baue angemessen strukturierte Teams auf

B.3.5Nur der Product Owner versorgt die Teams mit Arbeit

B.4Ein Produkt – mehrere Teams

B.5Das Kapitel in Stichworten

Literaturverzeichnis

Index

1Einleitung

Märkte verändern sich immer schneller. Dadurch stehen viele Unternehmen heute vor der Herausforderung, schneller und flexibler auf diese Änderungen zu reagieren. Menschen mit Verantwortung in Unternehmen stellen die große Frage: »Wie werden wir agiler?«

Vor einigen Jahren hat Ken Schwaber bei einem Vortrag in Karlsruhe eine Idee dazu präsentiert. Das CIF (Continuous Improvement Framework) schlägt einen Satz von Unternehmensmetriken vor. In regelmäßigen Abständen prüfen Mitarbeiter aller Unternehmensebenen den Fortschritt anhand dieser Metriken und beschließen Verbesserungsmaßnahmen. Beispiele für diese Metriken waren »Die Anzahl der Kunden« oder »Die Zeitdauer zwischen zwei Versionen eines Produktes«. Bei diesem Vorschlag wird das Unternehmen als Blackbox angesehen. Ken Schwaber machte dabei keine Vorschläge zur inneren Gestalt des Unternehmens. Dieses Buch dagegen ist voll von solchen Schritten. Der Leser kann, wie mit einer Lupe, einzelne Organisationsbereiche und Situationen fokussieren und bekommt dazu Ideen und Handlungsanweisungen für den individuellen Weg zu mehr Agilität.

Zu diesem Prozess fügen wir als Katalysator unsere Erfahrung aus diversen Unternehmen der verschiedensten Branchen hinzu. Wir, Stefan Roock und »Mentos« Jürgen Hoffmann, sind als ihre Trainer, Berater und Coaches dicht am Puls der Firmen. Unserer Beobachtung nach gibt es auch nicht das agile Unternehmen. Jedes hat andere Mitarbeiter, Herausforderungen und eine andere Geschichte. Der Versuch, von einem auf den anderen Tag einfach alle Ideen und Werkzeuge aus der Agile Community mit einem Schlag einzuführen, würde die Menschen, die Produkte und damit das ganze Unternehmen überfordern.

Eines der Prinzipien beim Einsatz von Agilität ist das ständige Experiment: »Try, inspect and adapt« – »Ausprobieren, Erfolgskontrolle und Anpassung«. Das ist der Weg, auf dem die hier vorgeschlagenen Ideen auch Ihr Unternehmen beleben und erfolgreicher machen können.

1.1Echte Agilität

Unserer Meinung nach stellt ein einfacher Zyklus den Kern agiler Entwicklung dar (siehe Abb. 1–1): Kunden haben Probleme, die ein selbstorganisiertes autonomes Team löst. Dieser Zyklus muss möglichst schnell und in direkter Interaktion stattfinden.

Abb. 1–1Kernidee agiler Entwicklung

Ein agiles Entwicklungsframework wie Scrum soll die agile Kernidee unterstützen (siehe Abb. 1–2). Wichtig ist, dass dabei stets die agile Kernidee im Vordergrund bleibt und nicht vom Scrum-Framework in den Hintergrund verdrängt wird.

Abb. 1–2Scrum zur Unterstützung der agilen Kernidee

Das klingt alles trivialer, als es ist. Faktisch haben die meisten Unternehmen sich Strukturen gegeben, die den beschriebenen Zyklus massiv stören (siehe Abb. 1–3). Die Beispiele für diese Störungen sind vielfältig:

Das Team hat keinen direkten Kontakt zu den Kunden.

Die Teammitglieder werden ständig zwischen Teams hin und her verschoben.

Vorgesetzte geben den Teammitgliedern Aufgaben, die sie von der Lösung kundenrelevanter Probleme abhalten.

Teammitglieder müssen Stage-Gate-Prozesse einhalten, die die Problemlösung für Kunden ganz erheblich verzögern.

Etc.

Abb. 1–3Unternehmensstrukturen stören die agile Kernidee.

In der Konsequenz stecken die meisten »agilen« Implementierungen noch in den Kinderschuhen (auch die, die sich bereits seit Jahren daran versuchen). So findet sich in vielen Fällen die Struktur aus Abbildung 1–4: Das Team ist selbstorganisiert, hat aber keinen direkten Kundenkontakt. Den Kundenkontakt hält z. B. das Produktmanagement und überführt die Kundenprobleme in Anforderungen, die das Team dann umsetzt. Die entwickelte Software liefert das Team nicht direkt an Kunden aus, weil das Team keine vollständig lieferbare Software herstellen kann (es fehlen z. B. die Integrationstests).

Abb. 1–4Selbstorganisiertes Team

In dieser Struktur ist mit dem selbstorganisierten Team zwar bereits eine wichtige agile Idee implementiert. Die Wirksamkeit des Teams bleibt aber beschränkt.

Häufig entwickelt sich diese Struktur technisch weiter. Das Team liefert die Lösung direkt an den Kunden aus, nachdem es die Fähigkeit erworben hat, in kurzen Abständen wirklich lieferbare Software zu erstellen (siehe Abb. 1–5). Die extremste Ausprägung findet sich heute im Continuous Deployment – die Software wird nach jeder Änderung sofort (also mehrmals täglich) an Kunden ausgeliefert.

Abb. 1–5Lieferndes Team

Wenn wir dann noch den oberen Teil des Zyklus von der Indirektion befreien und das Team direkt mit den Kunden über ihre Bedürfnisse und Probleme sprechen lassen, landen wir bei echter Agilität (siehe Abb. 1–6).

Abb. 1–6Kundenwertoptimierendes Team

Vor diesem Hintergrund kann man agil arbeitende Teams in einem Satz folgendermaßen definieren: Business-fokussierte Teams, die für Produkt und Prozess Verantwortung übernehmen.

In diesem Buch beschreiben wir, was über selbstorganisierte, liefernde Teams hinaus für echte Agilität notwendig ist. Wir gehen also davon aus, dass Sie als Leser bereits selbstorganisierte, liefernde Teams erreicht haben oder sich anderswo die Informationen besorgen, die dafür notwendig sind.

Wichtig ist uns hier noch, dass die beschriebenen »Stufen« nicht sequenziell durchlaufen werden müssen. Sie können bei der Einführung agiler Entwicklung auch direkt auf kundenwertoptimierende Teams abzielen und die für selbstorganisierte und liefernde Teams notwendigen Veränderungen gleichzeitig vollziehen.

1.2Agile Fluency

Die beschriebenen Unterscheidungen haben Diana Larsen und Jim Shore vor einigen Jahren im Agile Fluency Model™ formalisiert. Das Modell verwendet das Erlernen einer Fremdsprache als Metapher. Man kann eine Fremdsprache auf verschiedenen Stufen sprechen. Auf einer Basisstufe kann man vielleicht nach dem Weg fragen und Dinge des täglichen Gebrauchs einkaufen. Auf der nächsten Stufe kann man einfache Gespräche führen. Auf der dritten Stufe kann man anspruchsvolle Literatur verstehen und intellektuell anspruchsvolle Gespräche führen. Auf der vierten Stufe kann man alles Erdenkliche in der Fremdsprache ausdrücken. Fließend (fluent) ist man auf der jeweiligen Stufe, wenn man sie auch in Stresssituationen beibehält.

Dieser Ansatz wird mit dem Agile Fluency Model™ auf Agilität übertragen – es wird in der aktuellen Version allerdings nicht mehr von Stufen, sondern von Zonen gesprochen. Es werden die vier Zonen aus Abbildung 1–7 unterschieden.

Abb. 1–7Das Agile Fluency Model™

Das Modell geht davon aus, dass die Beteiligten in der Lage sind, Programmcode für Software zu schreiben (Start). Sie beherrschen also ihr grundsätzliches Handwerkszeug, um etwas herzustellen oder eine Dienstleistung zu erbringen. Für das Modell, wie wir es benutzen, ist die Art des Produktes nicht wichtig.

In der ersten Zone »Focus on Value«wird auf Wert fokussiert. Aus Geschäftssicht muss regelmäßig Fortschritt erkennbar sein und es muss die Möglichkeit geben, die Richtung zu ändern. Dazu ist in erster Linie ein Kulturwandel im Team notwendig – weg von einer technisch bestimmten wasserfallartigen Planung hin zu einer Planung aus Geschäftssicht. Regelmäßige Demonstrationen von Produktinkrementen schafft Transparenz über den Fortschritt. Regelmäßige Planungen erlauben das Umsteuern, wenn gewünscht. Ein einfaches iteratives Verfahren mit Planung und Review kann ausreichen, um »Focus on Value« zu erreichen. Diese Zone haben wir oben »selbstorganisiertes Team« genannt (siehe Abb. 1–4).

In der folgenden Zone wird auf die Lieferung von Wert fokussiert. Das Team muss in der Lage sein, so häufig an Kunden auszuliefern, wie es aus Geschäftssicht sinnvoll ist. Um diese Zone zu erreichen, müssen geeignete Entwicklungspraktiken wie Continuous Integration, automatisierte Unit Tests, testgetriebene Entwicklung, Pair Programming und Continuous Delivery installiert werden. Diese Zone haben wir oben »lieferndes Team« genannt (siehe Abb. 1–5).

In der dritten Zone wird auf die Optimierung von Wert durch das Team fokussiert. Hier geht es um die Frage, welche Produkte und Produkteigenschaften wirklich wertvoll für Kunden sind. Es müssen exzellente Produktentscheidungen gefällt werden. Hierzu ist sowohl eine Veränderung der Unternehmensstruktur als auch Fachexpertise im Team notwendig. Das kann durch die Integration von Business-Analysten oder sogar direkt von Kunden ins Team erfolgen.

In der vierten Zone »Optimize for Systems« werden schließlich Gesamtsysteme optimiert. Dazu werden Gesamt-Wertschöpfungsketten optimiert und systematisch marktrelevante Innovationen erzeugt. Um diese Zone zu erreichen, ist ein Wandel der Unternehmenskultur notwendig. So muss es z. B. möglich sein, Dinge auszuprobieren, die vermeintlich nichts mit dem Geschäftszweck zu tun haben. Es muss auch erlaubt sein, Fehler zu machen. Und nicht zuletzt muss global optimiert werden.

Wichtig ist bei allen Zonen der Fluency-Aspekt. Ein Team ist in einer Zone fluent, wenn es auch in Stresssituationen innerhalb dieser Zone bleibt. Ein Team ist also dann in der Zone »Deliver Value« fluent, wenn es auch bei anspruchsvollen Terminen und großem Druck durch das Management die agilen Entwicklungspraktiken wie testgetriebene Entwicklung einsetzt.

Das Agile Fluency Model™ ist nicht als Reifegradmodell gedacht. Zum einen werden die Zonen nicht vollständig sequenziell erreicht. Es kann also durchaus sein, dass man die Praktiken für »Deliver Value« einführt, bevor man in »Focus on Value« fluent ist. Zum anderen muss die Reihenfolge auch nicht in allen Fällen wie beschrieben ablaufen. Die dargestellte Reihenfolge deckt sich allerdings mit dem, was viele Agile Coaches in ihrer täglichen Arbeit beoachten.

1.3Fokus dieses Buches: echte Agilität oder auch »Optimize Value«

Dieses Buch fokussiert auf echter Agilität alias »Optimize Value« nach dem Agile Fluency Model™ – aber nicht beschränkt auf einzelne Projekte, sondern als relevanter Aspekt der Unternehmensorganisation. Das Buch erläutert nicht, wie »Focus on Value« oder »Deliver Value« erreicht werden, sondern geht davon aus, dass die dafür notwendigen Praktiken bereits erfolgreich eingeführt wurden.

Teams, die »Optimize Value« erreicht haben, liefern größeren Wert an Kunden und treffen bessere Produktentscheidungen. Diese Verbesserung kann direkt mit geschäftsrelevanten Metriken (z. B. Kundenzufriedenheit und Umsatz) gemessen werden.

Kundenwertoptimierende Teams liefern im Verhältnis zur Investition den größtmöglichen Wert. Sie verstehen, was der Markt wünscht, was das Unternehmen benötigt und wie beide Bedürfnisse befriedigt werden können. In einer Start-up-artigen Umgebung weiß das Team, was es lernen muss und wie es das lernen kann.

Diese Teams nutzen z. B. Lean Startup und Design Thinking sowie weitere Techniken zur Product Discovery. Sie arbeiten mit adaptiver Planung, haben das Produktmanagement ins Team integriert und interagieren direkt und persönlich mit Endkunden.

Sie schaffen Transparenz, indem sie mit konkreten Geschäftsmetriken (z. B. Return on Investment, Kundenzufriedenheit, Umsatzrendite pro Mitarbeiter) ins Unternehmen berichten.

Gegenseitiges Vertrauen zwischen Team und Unternehmen führt zu schnellen und effektiven Aushandlungsprozessen. Das Team ist so breit bzgl. seiner Fähigkeiten aufgestellt, dass Übergaben eliminiert werden und Entscheidungen schnell gefällt werden können.

Kundenwertoptimierende Teams erkennt man daran, dass sie mit Geschäftsmetriken arbeiten, auf Kundenbegeisterung hin optimieren und profitabel sind. Weisen relevante Geschäftsmetriken (z. B. Kundenzufriedenheit) auf Probleme hin, reagieren kundenwertoptimierende Teams sofort darauf und ändern ggf. selbstständig die Richtung. Im Extremfall schlägt das Team vor, das Projekt oder Produkt zu beenden.

Um kundenwertoptimierende Teams zu erhalten, muss das Unternehmen in sie investieren und Business-Experten ins Team integrieren. Diese müssen reguläre Vollzeit-Teammitglieder sein.

Darüber hinaus können diese Teams nur dann erreicht werden, wenn organisatorische Hindernisse bei Werterzeugung und Wertlieferung beseitigt werden. Dazu muss das Management im ganzen Unternehmen kooperativ zusammenarbeiten. In den meisten Fällen müssen die Manager dabei gecoacht werden, wie sie diesen veränderten Herausforderungen gerecht werden können.

1.3.1Eigenschaften von »Optimize Value«-Unternehmen

Damit dies alles möglich wird, müssen Unternehmen in der Regel die folgenden Eigenschaften herausbilden:

Jeder Mitarbeiter sieht die Wertschöpfung des Unternehmens durch die Augen des Kunden.

Jeder Mitarbeiter versteht, wie er zu dieser Wertschöpfung beiträgt.

Jeder Mitarbeiter engagiert sich in der kontinuierlichen Verbesserung der Wertschöpfung.

Jedes Teammitglied versteht sich als Bestandteil eines Teams mit gegenseitigen Abhängigkeiten.

Jedes Teammitglied bringt sich so in das Team ein, wie es gerade notwendig ist – auch außerhalb der eigenen Spezialisierung und Komfortzone. Titel und Positionen treten in den Hintergrund.

Karrierepfade im Unternehmen orientieren sich nicht mehr an fixen Positionen. Stattdessen tritt der Beitrag zum großen Ganzen in den Vordergrund. Für Gehaltserhöhungen spielt daher das Ansehen der Kollegen eine große Rolle. Sie wissen durch die Arbeit im Team am besten um den Beitrag ihres Kollegen.

Mitarbeiter wechseln die Rolle im Team sowie die Teammitgliedschaft so, wie es für die Generierung von Kundennutzen optimal ist.

Das Unternehmen sorgt dabei dafür, dass sich die Mitarbeiter weiterentwickeln können und maximiert mit ihren Stärken arbeiten können.

Es ist also sowohl ein struktureller wie auch kulturellen Wandel notwendig.

1.3.2»Focus on Value« und »Deliver Value«: Literaturempfehlungen

Für »Focus on Value« nach dem Agile Fluency Model™ empfehlen wir die folgenden Bücher:

Stefan Roock: »Scrum auf dem Bierdeckel erklärt«. dpunkt.verlag, 2016. Freies PDF:

http://www.dpunkt.de/ebooks_files/free/12551.pdf

.

Henning Wolf, Wolf-Gideon Bleek: »Agile Softwareentwicklung«. dpunkt.verlag, 2010.

Stefan Roock, Henning Wolf: »Scrum – verstehen und erfolgreich einsetzen«. dpunkt.verlag, 2015.

David J. Anderson: »Kanban: Evolutionäres Change Management für IT-Organisationen«. dpunkt.verlag, 2011.

Henning Wolf (Hrsg.): »Agile Projekte mit Scrum, XP und Kanban«. dpunkt.verlag, 2015.

Für »Deliver Value« nach dem Agile Fluency Model™ empfehlen wir die folgenden Bücher:

Robert C. Martin: »Clean Code: A Handbook of Agile Software Craftsmanship«. Prentice Hall, 2008.

Roman Pichler, Stefan Roock (Hrsg.): »Agile Entwicklungspraktiken mit Scrum«. dpunkt.verlag, 2011.

Henning Wolf, Stefan Roock, Martin Lippert: »eXtreme Programming«. dpunkt.verlag, 2005.

Eberhard Wolff: »Continuous Delivery: Der pragmatische Einstieg«. dpunkt.verlag, 2016.

1.4An wen richtet sich das Buch?

Das Buch richtet sich an alle, die bereits selbstorganisierte, liefernde Teams erreicht haben und den nächsten Schritt in Angriff nehmen wollen. Da hierfür eine Änderung der Unternehmensstruktur notwendig ist, adressiert das Buch insbesondere diejenigen, die diese Strukturen verändern können. Es wendet sich außerdem an alle, die vielleicht nicht die Macht haben, die Unternehmensstrukturen zu verändern, aber den Einfluss, um die »Mächtigen« dazu zu bringen.

Konkret wendet sich das Buch also an folgende Gruppen:

Unternehmensgründer

Geschäftsführer

Hochrangige Manager (CxO-Ebene, Senior Vice Presidents, Vice Presidents, Bereichs- und Abteilungsleiter)

Berater obengenannter Menschen

1.5Überblick über das Buch

Dieses Buch ist entlang der Herausforderungen aufgebaut.

Kundenwertoptimierende Teams müssen ein gutes Verständnis darüber haben, was Wert für Kunden schafft. Sie verstehen die Kundenbedürfnisse und arbeiten effektiv mit Produktvisionen. Ihnen ist außerdem klar, dass neue Produkte für neue Kundensegmente ganz anders entwickelt werden müssen als neue Features für bereits existierende Produkte. Das 3-Horizonte-Modell stellt ein leicht verständliches und trotzdem nützliches Denkmodell für die verschiedenen Produktstadien dar. All diese behandeln wir in Kapitel 2.

Kapitel 3 widmet sich dem Team. Kundenwertoptimierende Teams verstehen sich nicht als Lieferanten für die Bestellungen der Fachseite oder eines Product Owners. Sie sehen die Wertschöpfung für Kunden als gemeinsame Teamaufgabe an. Daher muss die entsprechende Fachkompetenz bzgl. Kunden, Markt, Business-Modell etc. im Team vorhanden sein. Das kann durch die Integration der entsprechenden Experten erfolgen oder dadurch, dass sich das Team die Kompetenzen aneignet. Mit einem so breit aufgestellten Team ändert sich auch die Sichtweise auf die Product-Owner-Rolle. Solche Teams berichten mit Metriken ins Unternehmen, die direkte Geschäftsrelevanz haben (z. B. Kundenzufriedenheit, Umsatz). Nicht zuletzt stellt sich an dieser Stelle für viele Produkte die Frage nach der Skalierung der Teams: Wenn ein Team nicht genügt, um das Produkt ausreichend schnell zu entwickeln, müssen mehrere Teams am selben Produkt arbeiten. Abhängig von Produkttyp muss das geeignete Skalierungsmodell ausgewählt oder entwickelt werden.

Damit das alles Wirklichkeit werden kann, muss die Organisation die Arbeit kundenwertoptimierender Teams geeignet unterstützen. Das bedeutet in erster Linie, dass die Organisation die Arbeit des Teams nicht behindern darf. Zielsysteme (z. B. Management by Objectives – MbO, Objectives and Key Results – OKRs), Bonussysteme, Aufgaben und Verantwortungen von Führungskräften sowie Roadmap- und Portfolioplanung müssen sich der Wertschöpfung für den Kunden unterordnen. In Kapitel 4 diskutieren wir, was das für Unternehmen konkret bedeutet.

In Kapitel 5 beleuchten wir schließlich den Weg hin zu kundenwertoptimierenden Teams und Organisationen. Dieses Vorhaben ist ebenso wenig komplett planbar wie die Entwicklung eines innovativen Softwareproduktes. Daher muss auch hier ein iterativer Ansatz wie z. B. Scrum oder Kanban verwendet werden. Mit dem Nordstern-Konzept kann sichergestellt werden, dass die notwendigen organisatorischen Veränderungen von vielen Schultern getragen und dennoch in eine einheitliche Richtung betrieben werden.

Im Anhang A beschreiben wir detaillierter konkrete Methoden zum User Research, namentlich Design Thinking, Design Sprints und Lean Startup.

Für die Entwicklung größerer Produkte reicht ein einzelnes Team nicht aus. Mehrere Teams müssen koordiniert an dem Produkt zusammenarbeiten. Anhang B stellt mit dem LeSS-Framework einen sehr leichtgewichtigen Scrum-basierten Ansatz dafür vor.

1.6Danksagung

Dieses Buch wäre ohne die Mitarbeit und Offenheit vieler anderer Menschen nicht möglich gewesen. Wir danken konkret

dem dpunkt.verlag und besonders unserer Lektorin Christa Preisendanz für die Unterstützung,

Corinna Baldauf (sipgate) und Frank Schlesinger (ImmobilienScout24) für ihre offenen Antworten zu Fragen der agilen Mitarbeiterführung,

unseren Kunden für die partnerschaftliche Arbeit, aus der viele der hier vorgestellten Erkenntnisse erwachsen sind,

den it-agile-Kollegen für den unermüdlichen Einsatz, it-agile immer ein Stück weiter in Richtung eines noch agileren Unternehmens zu entwickeln,

den Emendare-Kollegen für den ständigen Gedankenaustausch und gemeinsames Lernen sowie

den Reviewern der Vorabversion dieses Buches, die uns wertvolles Feedback für den letzten Feinschliff gegeben haben.

Jürgen Hoffmann, Stefan RoockKarlsruhe, Hamburg, Dezember 2017

2Begeisterte Kunden

Begeisterte Kunden sind der Garant für jedes Unternehmen, langfristig zu wachsen. Die Aufgabe der Produktentwicklung ist es, die Grundlage für dieses Wachstum zu schaffen. Kundenwertoptimierende Teams (»Optimize Value« nach dem Agile Fluency Model™ [Larsen & Shore]) übernehmen für die Kundenbegeisterung als Team die Verantwortung. Sie müssen also ein gutes Verständnis darüber haben, was Wert für Kunden schafft. Sie verstehen die Kundenbedürfnisse und arbeiten effektiv mit Produktvisionen. Sie verstehen außerdem, dass neue Produkte für neue Kundensegmente ganz anders entwickelt werden müssen als neue Features für bereits erfolgreiche Produkte.

Wir betrachten in diesem Kapitel zuerst, was Wert bedeutet. Anschließend diskutieren wir, wie Wert identifiziert werden kann. Die konkreten Techniken unterscheiden sich je nach Kontext. Wir stellen mit dem 3-Horizonte-Modell ein Instrument vor, das hilft, die passenden Techniken zur Wertidentifikation zu finden.

2.1Definieren, was Wert bedeutet und schafft

In einem kundenwertoptimierenden Team muss jede(r) Einzelne verstehen, was Wert für Kunden bedeutet und wie zusätzlicher Wert (Kundennutzen) geschaffen werden kann. So bekommt die Arbeit Sinn, die gegenseitige Abhängigkeit im Team wird sichtbar gemacht und es wird eine Orientierung gegeben, was Fortschritt bedeutet. Dadurch können (Produkt-)Visionen und Strategien selbstorganisiert (ohne Command & Control) erreicht werden.

2.1.1Wert aus Kundensicht

Wenn man heute die Menschen in einer Firma fragt, was wichtig und wertvoll ist, wird man meist sehr unterschiedliche Antworten bekommen. Der Mitarbeiter vom Empfang wird vielleicht sagen: »Wichtig ist, dass die Besucherlisten korrekt ausgefüllt sind.« Die Antwort des Softwareentwicklers könnte sein: »Die hausinternen Richtlinien für guten Softwarecode sind wertvoll – wenn wir sie einhalten.« Der CFO würde antworten: »Relevant ist die Umsatz- und Gewinnsteigerung in allen Quartalen.«

Gemeinsam an diesen Antworten ist die Fokussierung auf die Innenansicht der Unternehmung. Es fließt viel Energie in interne Vorgänge, in Karriereplanung und -schritte, Absicherung und absolute Fehlervermeidung.

Meist ergeben sich interessante andere und neue Perspektiven, wenn man das eigene Unternehmen und die eigenen Produkte durch die Augen der Kunden betrachtet. In vielen Fällen werden sich dabei große Diskrepanzen zwischen Außen- und Innenwahrnehmung ergeben. So halten die meisten Entwickler von Internetanwendungen ihr Unternehmen für eine »Product Company« und glauben folglich, sie würden ein Produkt entwickeln. Die Kunden kaufen meist aber gar kein Produkt. Sie nehmen einen Service in Anspruch. Kunden von mobile.de kaufen oder verkaufen Autos. Kunden bei ImmobilienScout24 suchen nach Häusern oder Wohnungen bzw. bieten diese an. Tatsächlich wäre das Softwaresystem als Produkt für die Kunden nutzlos. Der Mehrwert entsteht erst durch die im System vorhandenen Daten über die Autos, die Wohnungen, die Häuser etc.

Diese geänderte Sichtweise ist relevant und nicht bloß Wortklauberei. Mit der Produktsichtweise wird mobile.de vielleicht darüber nachdenken, wie man per Handy aufgenommene Fotos von Fahrzeugen einfacher auf der Plattform einstellen kann. Man wird aber nicht darüber nachdenken, den Händlern einen Fotoservice anzubieten: Professionelle Fotografen machen ansehnlichere Fotos der Fahrzeuge, sodass die Verkaufschancen erhöht werden. Mit der Serviceperspektive ist mobile.de offener, noch unbefriedigte Bedürfnisse seiner Kunden zu identifizieren und mehr Wert zu schaffen.

Eine Änderung der Sichtweise von Produkt auf Service bedeutet nicht nur ein Umdenken, sondern häufig auch eine Reorganisation. Die Organisationsstruktur muss diese Sichtweise abbilden, um Friktionen zu minimieren.

Eine Wertstromanalyse1 jedes Unternehmens wird schnell offenlegen, ob das Unternehmen sich im Produkt- oder Servicegeschäft bewegt und dass Wertbildung beim Kunden beginnt. Echte Bedürfnisse von Menschen, die zu Kunden werden, bilden das Fundament langfristig tragfähiger Werterzeugung. Wer die Kunden und ihre Bedürfnisse aus den Augen verliert, wird durch den Wettbewerb leicht angreifbar.

Götz Werner schreibt in seiner Autobiographie [Werner 2015] über den Kundengrundsatz von dm-drogerie markt: »Wir sehen als Wirtschaftsgemeinschaft die ständige Herausforderung, ein Unternehmen zu gestalten, durch das wir die Konsumbedürfnisse unserer Kunden veredeln.« Damit stellt sich Götz Werner und das Unternehmen dm-drogerie markt auf den Standpunkt, dass dauerhafter Wert nicht geschaffen wird durch die Stimulation von Bedürfnissen, die die Menschen gar nicht haben. So gibt es zum Beispiel im dm-drogerie markt vor der Kasse keine »Quengelregale« mit Süßigkeiten für Kinder. Stattdessen versuchen die Mitarbeiter von dm die latent vorhandenen echten Bedürfnisse zu identifizieren. Götz Werner formuliert das in seinen Worten so: »Die Kunst ehrlicher Kommunikation ist es – beharrlich und bescheiden –, an der Zielsetzung zu arbeiten, den Kunden auf Augenhöhe anzusprechen, damit auf Dauer wirklich erlebbar wird, dass der Kunde nicht das Objekt unserer Begierde ist, sondern das Ziel unserer Anstrengungen.« Wert definiert sich also vom Kunden, vom Menschen, her.

Wir können von dm-drogerie markt noch mehr lernen. Kapitel 11 seines Buches »Womit ich nie gerechnet habe« [Werner 2015] ist überschrieben mit den Worten »Radikale Kundenorientierung«. Dieser Gedanke, sich ganz auf den Kunden zu fokussieren – und nicht nur auf sein Geld –, ist es wert, zu Ende gedacht zu werden. Für Götz Werner war 1992 der Gedanke, auf Sonderangebote zu verzichten, bestechend: »Der Kunde soll doch die Ware dann kaufen, wenn er sie braucht, und nicht, wenn sie bei uns billig ist.« Das ist vom Kundenbedürfnis her gedacht und nicht aus Händlersicht. In der Handelsbranche ist es üblich, mit Sonderangeboten Menschen in die Läden zu locken und nebenbei Restposten loszuwerden. Insofern sieht der Verzicht auf Sonderangebote aus Sicht der Handelsbranche wie eine sehr verrückte Idee aus. Ohne Angebote kann man auch keine wöchentlichen Werbeflyer in die Briefkästen verteilen lassen – was sollte da auch draufstehen? Diese Woche kostet eine Tube Zahnpasta dasselbe wie letzte Woche? Also musste dm-drogerie markt mit einer solchen Entscheidung auch neu herausfinden, wie man sich als Unternehmen im Leben der Menschen einen Platz sucht, ohne ständig nach Aufmerksamkeit zu schreien. Rückblickend können wir sagen: Der langfristige Erfolg gibt der Entscheidung von Götz Werner recht.

In der Menschheitsgeschichte sind auch kurzlebigere Modelle entwickelt worden. Sie basieren auf Betrug oder der Einflüsterung von Bedürfnissen, die nicht wirklich vorhanden oder nicht wirklich gestillt werden. Die populäre Geschichte von dem »besten Verkäufer«, der es schafft, Eskimos einen Kühlschrank zu verkaufen, ist ein Beispiel dafür. Wir würden so einem Verkäufer sicher ein überzeugendes Auftreten und rhetorisches Geschick attestieren. Ein guter Verkäufer ist er aber nicht. Schließlich bekommt der Kunde etwas, was er nicht braucht. Dieser Kunde wird vermutlich nicht nochmal etwas bei diesem Unternehmen kaufen und es auch nicht weiterempfehlen. Der Verkäufer hätte seinem eigenen Unternehmen also geschadet.

Leider ist die Fokussierung auf kurzfristige Umsätze immer noch gang und gäbe. So hat in Deutschland der Gesetzgeber darauf reagiert und gibt Endkunden die Möglichkeit, von Haustürgeschäften oder telefonisch vereinbarten Verträgen innerhalb vernünftiger Fristen zurückzutreten.

2.1.2Bedürfnisse identifizieren

»Wenn ich die Kunden gefragt hätte, was sie wollen, hätten sie gesagt ›schnellere Pferde‹«. Dieser Ausspruch wird Henry Ford zugeschrieben2. Ford hat aber keine schnelleren Pferde gezüchtet, sondern erschwingliche Autos produziert. Er hat das eigentliche Bedürfnis identifiziert: schnell von A nach B zu kommen.

Das Beispiel zeigt, dass es meist nicht zielführend ist, Menschen direkt nach ihren Bedürfnissen zu fragen. Ein Bedürfnis ist ein Mangel – etwas, das fehlt. Ein Produkt oder Service füllt diese Lücke und beseitigt oder mildert damit den Mangel. Dem Aufdecken von Bedürfnissen stehen zwei Aspekte im Weg:

Wir haben uns mit den meisten Mängeln so weit arrangiert, dass sie uns nicht ständig bewusst sind. (Sonst hätten wir vermutlich notorisch schlechte Laune.) Was uns nicht bewusst ist, können wir auf direkte Nachfrage auch nicht benennen.

Wir sind so konditioniert, dass wir sehr schnell in Lösungen denken und das tun wir stets in dem uns bekannten Lösungsrahmen. Wenn die Menschen gewohnt sind, per Pferd zu reisen, wird die Frage nach ihren Bedürfnissen ganz natürlich mit »schnelleren Pferden« beantwortet. Das ist allerdings nicht das Bedürfnis, sondern der Lösungsvorschlag. Diese Lösungsvorschläge sind nicht per se unsinnig, aber selten innovativ.

Es ist also keineswegs trivial, Kundenbedürfnisse zu identifizieren. Das ist den meisten Unternehmen klar. Häufig versuchen Unternehmen, das Problem über Expertenmeinungen zu lösen. Sie kaufen Experten für Produktdesign und Produktentwicklung ein und die starten Versuchsballons – fliegt der Ballon gut, so wird die Produktion ausgebaut. Jedes Produkt ist dann eine Mischung aus Erfahrung und Kompromissen dieser Experten. Dieses Verfahren funktioniert ganz gut im Bereich von »Me-too«-Produkten: Ein anderes Unternehmen hat eine neue Dienstleistung oder eine neue Klasse von Produkten erfunden. Wir beobachten die Stärken und Schwächen des Konkurrenzproduktes und bieten möglichst bald eine bessere Version des Produktes an. Die Verbesserung kann in einem größeren Funktionsumfang, geringerem Preis, höherer Qualität, Verfügbarkeit in einem bestimmten Land etc. bestehen. So hat Zalando z. B. die US-Plattform Zappos als Vorbild und im Grunde den gleichen Service für den deutschen Markt angeboten.

Ein alternativer Weg zu den eingekauften Produktexperten führt über die Kunden als Experten für ihre eigenen Bedürfnisse. Hier versuchen wir aus einem ständigen Dialog mit den Menschen Entscheidungen für das Produkt oder den Service abzuleiten. In den meisten Fällen generiert dieser Dialog schneller validiertes Wissen und ist daher für die Entwicklung innovativer Produkte oder Services effektiver. Wir stellen in diesem Kapitel Techniken vor, mit denen der Dialog mit den Menschen über ihre Bedürfnisse gelingen kann.

Allerdings ist nicht jede Technik in jedem Kontext effizient. Wir klassifizieren die Kontexte nach ihrem Innovationsgrad über das 3-Horizonte-Modell, das wir im nächsten Abschnitt vorstellen. Anschließend betrachten wir, welche Techniken in welchem der drei Horizonte nützlich sind.

2.2Drei Horizonte für Wachstum und Innovation

Das 3-Horizonte-Modell unterscheidet drei Innovations- und Wachstumshorizonte [Baghai et al. 2000], die in Abbildung 2–1 dargestellt sind. Jedes Unternehmen, das langfristig wachsen möchte, muss alle drei Horizonte abdecken.

Abb. 2–13-Horizonte-Modell für Wachstum

In Horizont 1 findet das aktuelle Geschäft statt; dort wird aktuell das Geld verdient. Wenn ein Start-up erfolgreich wird, wächst es schnell bezüglich der Umsätze. Irgendwann tritt allerdings eine Sättigung in dem Geschäftsfeld ein: Die Wachstumskurve verläuft logarithmisch (siehe Abb. 2–2).

Abb. 2–2Das Wachstum des aktuellen Geschäfts ist endlich

Irgendwann ist weiteres Wachstum nicht mehr möglich: Der Markt ist insgesamt gesättigt und zwischen den Wettbewerbern aufgeteilt. Diese Aufteilung kann sich natürlich prinzipiell verschieben. Das passiert meist aber nur langsam. Und spätestens wenn ein Unternehmen ein Quasi-Monopol herausgebildet hat, stagniert das Wachstum. Auch wenn das Wachstum bereits stagniert, können Unternehmen über lange Zeit sehr profitabel arbeiten. Unternehmen wie mobile.de können im deutschen Gebrauchtfahrzeugmarkt kaum noch wachsen, fahren jedes Jahr aber beträchtliche Gewinne ein.