Lean Enterprise

Mit agilen Methoden zum innovativen Unternehmen

Jez Humble, Joanne Molesky, Barry O'Reilly, Elke Bethke, Elke Bethke

• Verlag: O'Reilly
• Jahr: 2017
• ISBN:
  9783960100799
• Thema: Informatik
• Thema: Projektmanagement

Neue Märkte und Technologien, sich verändernde Kundenbedürfnisse – Startups sind darauf eingestellt, unter diesen Bedingungen zu operieren. Aber wie steht es um etablierte Unternehmen und Organisationen? Wie können auch sie Innovation konsequent vorantreiben und IT zu ihrem Wettbewerbsvorteil machen?Jez Humble, Joanne Molesky und Barry O'Reilly plädieren sehr überzeugend dafür, das Potenzial des Lean-Mindset gerade auch für größere Unternehmen zu nutzen. Die Autoren werden hierbei ganz konkret. Sie zeigen, wie erfolgreiche Organisationen Lean-Startup- und DevOps-Methoden auf die typischen Aufgabenstellungen von Unternehmen anwenden – und zwar in allen Bereichen. Das Buch illustriert das agile Vorgehen anhand zahlreicher Fallstudien und präsentiert einen beeindruckenden Fundus an Strategien, Ansätzen und Methoden. Ob Vorstandsmitglieder, Geschäftsführer, Abteilungsleiter oder Produktmanager: Lean-Interessierte erhalten praktische Anleitungen zu typischen unternehmerischen Herausforderungen.Erfahren Sie, wie Sie: - Produkte und Geschäftsmodelle mit echtem Kundennutzen entwickeln und validieren- Investitionsrisiken messen und bewerten- das Potenzial Ihrer Teams durch Visionen und Handlungsspielräume entfalten- die Prozesse in Ihrer Organisation laufend verbessern- Softwareentwicklung durch Continuous Delivery, Continuous Integration und Testautomatisierung beschleunigen- Innovation als Teil Ihres Portfolios stärken- in umfassenden Programmen Mitarbeiter fördern, Qualität und Geschwindigkeit der Produktauslieferung erhöhen und Kosten senken u.v.a.m.

TEIL III

Nutzen

Prognosen sind schwierig, besonders wenn sie die Zukunft betreffen.

– Niels Bohr

Im zweiten Teil haben wir gezeigt, wie man neue Möglichkeiten untersucht – seien es neue Produkte oder interne Tools und Services. In diesem Teil erläutern wir, wie validierte Ideen genutzt werden können. Wie in Kapitel 2 diskutiert, erfordern diese zwei Bereiche komplett unterschiedliche Herangehensweisen in Management und Ausführung. Trotzdem sind beide notwendig – und ergänzen sich sogar – wenn wir unser Unternehmensportfolio ausbalancieren und uns an ein sich ständig veränderndes Geschäftsumfeld anpassen wollen.

Wir hoffen, dass Sie dieses Kapitel lesen, weil Sie das Stadium der Exploration erfolgreich verlassen haben – aber es ist genauso wahrscheinlich, dass Sie hier sind, weil Sie an einer großen Initiative in einem großen Unternehmen teilnehmen, die ziemlich traditionell aufgesetzt wurde. Dieser Teil des Buchs beschreibt deshalb vorrangig die Art und Weise, wie solche Programme oder Initiativen geführt oder gemanagt werden müssen, um die Mitarbeiter für die aktive Teilhabe an solchen Programmen zu befähigen und um die Lieferrate von werthaltigen, hochwertigen Produkten für die Kunden deutlich zu erhöhen. Aber bevor wir damit beginnen, müssen wir unsere derzeitigen Umstände verstehen.

Im Unternehmenskontext wird geplante Arbeit normalerweise durch einen zentralen oder an die Abteilungen gebundenen Planungs- und Budgetierungsprozess priorisiert. Bewilligte Projekte gehen dann durch den Entwicklungsprozess, bevor sie live gestellt oder in die Massenfertigung übergeben werden. Selbst in Organisationen, die »agile« Entwicklungsmethoden einsetzen, ähnelt die Wertschöpfungskette für das Projekt oftmals Abbildung III-1. Wir beschreiben das als »Wasser-Scrum-Fall«.¹ In Fällen, in denen eine oder mehrere der Phasen outgesourct sind, müssen wir zusätzlich einen Beschaffungsprozess durchlaufen, bevor wir mit den auf die Bestätigung folgenden Design- und Umsetzungsphasen fortfahren können. Weil dieser Prozess so beschwerlich ist, neigen wir dazu, Arbeit zusammenzufassen und damit große Programme zu kreieren, die das Problem mit dem Muster oder Paradigma »Projekt« selbst noch verschlimmern.

Abbildung III-1: Wasser-Scrum-Fall

Das projektbasierte Paradigma zur Durchführung von Softwareentwicklung in großem Maßstab stammt aus dem US-amerikanischen militärisch-industriellen Komplex der Nachkriegszeit. Damals war Software zwingend notwendig für den Bau neuer Flugzeuggenerationen, Raketenabwehrsysteme und Raumfahrzeuge, die genaugenommen einen Kunden hatten: die US-Regierung. Es ist kein Zufall, dass die Bezeichnung »Software Engineering« erstmals auf einer NATO-Konferenz im Jahr 1968 verwendet wurde. Diese Konferenz sollte ausarbeiten, wie sich die Softwareentwicklung großer Projekte formalisieren lässt.²

Das traditionelle, zentralisierte Phase-Gate-Projektparadigma ist in einer weniger angespannten Zeit entwickelt worden. Produkte konnten bis zu ihrer vollständigen Herstellung keinen Wert liefern, sie mussten im Verlauf ihres Lebenszyklus nicht großartig verändert werden, und wir waren recht überzeugt davon, die Spezifikation nicht anpassen zu müssen, sollten wir während der Entwicklung des Projekts neue Informationen erhalten.

Keins dieser Kriterien ist auf heutige softwarebasierte Systeme anwendbar. Die Macht von Software besteht darin, dass es einfach ist, Prototypen zu bauen und zu verändern. Besonders, da wir so regelmäßig falsch einschätzen, was die Nutzer unserer Produkte und Systeme für wertvoll halten, führt die Planung von großen Programmen Monate im Voraus zu enormer Verschwendung und zu Meinungsverschiedenheiten. Statt zu versuchen, die Zukunft besser vorherzusagen, sollten wir unsere Fähigkeit zur schnellen und effektiven Anpassung an neue Informationen verbessern.³

Das moderne Lean-Agile-Paradigma, das wir hier für die Umsetzung von großen Programmen vorstellen, ist das Ergebnis von Arbeit mit und dem Studium von Unternehmen, die ihre Softwareentwicklung vom kritischen Pfad holen müssen. Sie wollen sich in großem Maßstab schnell bewegen, schwache Marktsignale erkennen und zügig ausnutzen. Das erlaubt ihnen, einen besseren Kundenservice zu bieten, die Kosten für die Entwicklung und Weiterentwicklung von Produkten zu reduzieren sowie die Qualität und Stabilität ihrer Services zu erhöhen.

Es gibt verschiedene Frameworks, die sich mit der Skalierung agiler Softwareentwicklungsmethoden befassen. Allgemein nehmen diese Frameworks kleine Scrum praktizierende Teams und fügen weitere Strukturen zur Koordinierung ihrer Arbeit hinzu. Trotzdem sind diese Teams immer noch in den Phase-Gate-Programmen und Portfoliomanagement-Prozessen eingebunden, die mehr oder weniger unverändert vom traditionellen Projektmanagement-Paradigma abstammen. Sie verwenden immer noch Top-Down-Denken und neigen zur Zusammenfassung von Arbeit in Releases mit langer Cycle Time. Damit erschweren sie die Nutzung gesammelter Informationen für zukünftige Entscheidungen. Unser Ansatz unterscheidet sich an einigen wichtigen Stellen von diesen Frameworks, wie auch vom traditionelleren Phase-Gate-Framework.

Der wichtigste Unterschied: Statt ein bestimmtes Set an Prozessen und Praktiken zu implementieren, konzentrieren wir uns darauf, auf Senior-Führungsebene kontinuierliche Verbesserung einzuführen und so die Evolution der Organisation und der eingesetzten Prozesse voranzutreiben. Kontinuierliche Verbesserung kann nicht an den Rändern unseres großen Organisationsplans verortet sein: Wir sehen sie vorn und im Zentrum. Das spiegelt die Tatsache wider, dass es keine One-Size-Fits-All-Lösung gibt und dass jedes Unternehmen unterschiedlichen Umständen gegenübersteht. Jedes Unternehmen wählt seinen eigenen Weg, um Veränderung anzugehen, jeweils abgestimmt auf die eigenen Geschäftsziele. Um langfristig anhaltende Ergebnisse zu erzielen, müssen wir Teams dazu befähigen, Dinge auszuprobieren und zu lernen, was für sie funktioniert und was nicht.

In den folgenden Kapiteln präsentieren wir die folgenden Prinzipien für die skalierte Lean-Agile-Produktentwicklung:

• Implementierung eines iterativen kontinuierlichen Verbesserungsprozesses auf Führungsebene mit präzisen, klar spezifizierten Ergebnissen (Outcomes), um gemäß dem Missionsprinzip eine gemeinsame Ausrichtung (Alignment) zu erzeugen

• Wissenschaftlich an herausfordernden Zielen arbeiten, um wertlose Aktivitäten zu identifizieren und zu entfernen – oder zu vermeiden

• Einsatz von Continuous Delivery zur Reduzierung von Release-Risiken, zur Verkürzung der Cycle Time und um es ökonomisch zu machen, in kleineren Paketgrößen (Batches) zu arbeiten

• Entwicklung einer Architektur, die lose gekoppelte Teams mit Kundenkontakt unterstützt, die selbst entscheiden können, wie sie arbeiten, um die Ziele auf Programm-Level zu erreichen

• Verringerung von Batch-Größen und Anwendung eines experimentellen Ansatzes im Produktentwicklungsprozess

• Erhöhung der Anzahl und Verstärkung von Feedbackschleifen, um kleinere und regelmäßigere Entscheidungen auf Basis der bei der Arbeit gewonnenen Informationen zu treffen und den Kundennutzen zu maximieren

Wir werden verschiedene Beispiele von Unternehmen zeigen, die diese Prinzipien genutzt haben, um einen bleibenden Wettbewerbsvorteil zu erzielen. Dabei beschreiben wir auch, wie sich diese Unternehmen im Verlauf des Prozesses selbst transformiert haben.

KAPITEL 6

Kontinuierliche Verbesserung verankern

Es ist paradox, dass langfristige Verbesserungen kaum auftreten, wenn sich Manager auf Produktivität konzentrieren. Konzentrieren sich Manager hingegen auf Qualität, so verbessert sich die Produktivität kontinuierlich.

John Seddon

In den meisten Unternehmen unterscheidet man zwischen den Mitarbeitern, die Software entwickeln und betreiben (gern als »IT« bezeichnet), und denen, die die Investitionsentscheidungen treffen und festlegen, was die Software können soll (meist als »Business« bezeichnet). Diese Bezeichnungen sind Relikte einer längst vergangenen Zeit, als IT noch als notwendiger Kostenpunkt zur Verbesserung der Effizienz des Business betrachtet wurde, nicht jedoch als Lieferant von Mehrwert für externe Kunden, der Produkte und Services baut. Die Bezeichnungen und die funktionale Trennung sind in vielen Organisationen einfach geblieben (wie auch die Beziehungen zwischen ihnen und die damit einhergehende Einstellung). Unser Ziel ist es, diese Unterscheidung aufzuheben.

In hochperformanten Unternehmen sind die Mitarbeiter, die softwarebasierte Produkte designen, bauen und betreiben, ein integraler Bestandteil des Business. Ihnen wird Verantwortung für das Kundenergebnis übertragen – und sie nehmen die Verantwortung an. Diesen Zustand zu erreichen, ist jedoch schwierig. Allzu leicht fällt man in die alten Verhaltensmuster zurück.

Eine hohe Performance erreichen Unternehmen, die Software als strategischen Vorteil sehen, durch Abstimmung dieser Ausrichtung (Alignment) der IT mit der restlichen Organisation sowie durch das Vermögen der IT zur Durchführung (execute). Das zahlt sich aus. In einem Bericht für den MIT Sloan Management Review, »Avoiding the Alignment Trap in Information Technology«, untersuchten die Autoren 452 Unternehmen und entdeckten, dass High Performers (7% von allen) weniger als der Durchschnitt für IT ausgeben und zugleich substanziell höhere Umsatzsteigerungsraten erzielen.¹

Es ist wichtig, wie man sich von niedriger zu hoher Performance entwickelt. Unternehmen mit schlechtem Alignment und ineffektiver IT haben die Wahl. Sollen sie zuerst Alignment von IT und Business herstellen oder eher ihre effektive Umsetzung von IT-Initiativen verbessern? Die Daten zeigen, dass Unternehmen mit schlechten IT-Fähigkeiten noch schlechtere Resultate erzielen, wenn sie das Alignment angehen, bevor sie die Durchführung in der IT verbessern. Im Gegensatz dazu erzielen Unternehmen, deren IT gut darin ist, ihre Arbeit pünktlich zu liefern und ihre Systeme zu vereinfachen, bessere Ergebnisse – und das mit wesentlich geringeren Kosten, selbst wenn die IT-Investitionen nicht auf die Business-Prioritäten abgestimmt sind.

Die Forscher schlossen daraus, das sich Unternehmen, die auf Software setzen, zuallererst auf ihre Umsetzungsfähigkeiten konzentrieren, verlässliche Systeme bauen und kontinuierlich an der Reduktion ihrer Komplexität arbeiten sollten, um eine hohe Performance zu erreichen. Nur dann zahlt sich die Abstimmung mit Business-Prioritäten aus. In jedem Team balancieren wir die Arbeit, die wir in die Verbesserung unserer Leistungsfähigkeit stecken, mit der Arbeit aus, die für den Kunden Wert schafft. Um das effizient tun zu können, müssen wir beide Formen von Arbeit sowohl auf Programmebene als auch auf Value-Stream-Level managen. In diesem Kapitel beschreiben wir, wie dies mithilfe eines als Improvement Kata bezeichneten Frameworks erreicht werden kann. Das ist der erste Schritt, um kontinuierliche Verbesserung in der Durchführung von großen Programmen zu erzielen. Haben wir das erreicht, können wir die Werkzeuge aus den folgenden Kapiteln zur Identifikation wertloser Aktivitäten verwenden und sie aus dem Produktentwicklungsprozess beseitigen.

Fallstudie: HP LaserJet Firmware

Wir beginnen mit einer Fallstudie über das LaserJet-Firmware-Team bei HP, das mit beiden Problemen konfrontiert war: Problemen beim Alignment und bei der Durchführung.² Wie Firmware schon andeutet, arbeitete das Team an embedded Software für Kunden, die kein Interesse daran hatten, regelmäßig Software-Updates zu erhalten. Trotzdem ist es ein exzellentes Beispiel dafür, wie die in Teil III beschriebenen Prinzipien in verteilten Teams funktionieren und welche Vorteile ihre Anwendung bringt.

Die LaserJet-Firmware-Abteilung bei HP baut die Firmware für alle Scanner, Drucker und Multifunktionsgeräte. Das Team besteht aus 400 Mitarbeitern, die über die USA, Brasilien und Indien verteilt sind. Im Jahr 2008 hatte die Abteilung ein Problem: Sie war zu langsam. Sie war mit allen neuen Produkt-Releases des Jahres in Verzug und nicht in der Lage, neue Funktionalitäten z...

Inhaltsverzeichnis

• Cover
• Titel
• Impressum
• Inhalt
• Einleitung
• Teil I: Orientieren
• Teil II: Erkunden
• Teil III: Nutzen
• Teil IV: Verändern
• Literaturverzeichnis
• Über die Autoren
• Über die Übersetzerinnen
• Index
• Fußnoten