Agil im ganzen Unternehmen: Wie Sie eine dynamische, flexible und kundenorientierte Organisation gestalten

Von Matt LeMay

Die agile Bewegung gibt konkrete, umsetzbare Antworten auf die Frage, die viele in Unternehmen nachts wachhält: Wie bleiben wir in einer sich schnell verändernden und unvorhersehbaren Welt erfolgreich? "Agile" hat bereits verändert, wie moderne Unternehmen Software entwickeln und ausliefern. Dieses praktische Buch zeigt, wie ganze Unternehmen - von Produktmanagern und Ingenieuren bis hin zu Marketingspezialisten und Führungskräften - agile Praktiken und die entsprechende Haltung zum Einsatz bringen.
Der Autor Matt LeMay erklärt "Agile" prägnant und ohne Jargon und liefert konkrete und umsetzbare Schritte, die jedem Team helfen, seine spezifischen Werte und Prinzipien in die Praxis umzusetzen. Beispiele aus einer Vielzahl von Organisationen, darunter kleine NGOs und globale Finanzunternehmen, lassen branchen- und funktionsübergreifend die grundlegenden Aspekte von Agilität lebendig werden.

- Verstehen Sie genau, was agiles Arbeiten auszeichnet und warum es wichtig ist
- Nutzen Sie "Agile", um die spezifischen Bedürfnisse und Ziele Ihres Unternehmens zu realisieren
- Setzen Sie die Theorie der Kundenorientierung in echte Praxis um
- Hören Sie auf, Zeit mit einer "Berichts- und Kritikkultur" zu verschwenden und fangen Sie an, bessere Entscheidungen zu treffen
- Schaffen Sie einen harmonischen Zyklus von Lernen, Zusammenarbeit und Auslieferung
- Lernen Sie von "Agile"-Experten in Unternehmen wie IBM, Spotify und Coca-Cola

• Sprache: Deutsch
• Herausgeber: O'Reilly
• Erscheinungsdatum: 2. Sept. 2019
• ISBN: 9783960103578

Buchvorschau

Index

Einführung

Meine Einführung zu Agile: »In der Hälfte der Zeit doppelt so viel Arbeit«

Wir werden einige neue Agile-Prozesse implementieren, die unseren Produktteams ermöglichen, in der Hälfte der Zeit doppelt so viel Arbeit zu erledigen.

Dies war das Erste, das ich über Agile gehört habe, und ich hatte keinen Grund, daran zu zweifeln. Ich war als Produktmanager in einem mittelständischen Unternehmen tätig, und unsere Geschäftsleitung hatte ein firmenweites Meeting einberufen, um ihre Pläne für das kommende Jahr zu verkünden. Ich war mir nicht sicher, ob »Agile« ein Ding mit einem großen A war oder nur ein allgemeiner Deskriptor für die Art und Weise, wie wir weiterarbeiten würden, doch in beiden Fällen klang es für mich ziemlich gut. Mein Team war in der Tat ziemlich langsam im Fertigstellen neuer Produkte gewesen, was im Wesentlichen zurückzuführen war auf einen Führungswechsel, der uns ohne eine klare Vision über das weitere Vorgehen gelassen hatte. Könnte uns dieses »Agile« Ding vielleicht helfen, das zu lösen? Als ich an meinen Schreibtisch zurückkehrte, suchte ich schnell nach »Agile Process« und wurde mit dem folgenden Absatz à la Wikipedia begrüßt:

Agile Softwareentwicklung ist eine Palette von Softwareentwicklungsmethoden, die auf iterativer und inkrementeller Entwicklung basieren, wobei sich Anforderungen und Lösungen über Zusammenarbeit zwischen selbstorganisierenden, interdisziplinären Teams entwickeln. Sie fördert adaptives Planen, evolutionäre Entwicklung und Bereitstellung, einen auf Zeitfenster (Timeboxes) abgestellten iterativen Ansatz sowie schnelle und flexible Reaktion auf Veränderungen. Es handelt sich um ein konzeptionelles Framework, das voraussichtliche Interaktionen während des gesamten Entwicklungszyklus vorantreibt. Im Jahr 2001 hat das Agile Manifest diesen Begriff eingeführt.¹

Nachdem ich diese Erläuterung gelesen hatte, fühlte ich mich erst mal stark überfordert. Alle oben genannten Konzepte – »selbstorganisierend«, »evolutionäre Entwicklung«, »schnelle und flexible Reaktion auf Veränderungen« – klangen mit Sicherheit ziemlich gut. Aber es war mir vollkommen unklar, was ich in dieser Hinsicht tun sollte. Was genau ist ein »auf Zeitfenster abgestellter iterativer Ansatz?«, und wie spielt das alles zusammen, sodass wir in der Hälfte der Zeit die doppelte Arbeit leisten können?

Da ich mir nicht sicher war, was von mir erwartet wurde, suchte ich Hilfe und Rat von erfahrenen Entwicklern und Designern in meinem Team. Sie erklärten mir, dass man mit Agile eine Reihe von Ansätzen beschreibt, die sich in ihrem Geist weitgehend ähneln, sich aber in ihren konkreten Methoden unterscheiden. Der beliebteste dieser Ansätze heißt Scrum. Meine Kollegen empfahlen mir einige Bücher und Artikel, und ich begann zu lernen, worum es bei diesem Scrum-Ding ging und wie es meinem Team helfen könnte, schneller und effizienter zu werden.

Nachdem ich ein Wochenende damit verbracht hatte, E-Books und Blogposts zu lesen, konnte ich einige taktische Schritte herausfiltern, die mir für die Implementierung von Scrum wesentlich erschienen. Zuerst sollten wir unsere Arbeit in zweiwöchige Perioden unterteilen, die sogenannten Sprints. Am Ende jedes Sprints sollten wir etwas vorweisen können, das tatsächlich fertiggestellt ist und für unsere Benutzer freigegeben werden kann. Und an jedem Tag des Sprints muss ein tägliches Meeting durchgeführt werden, Daily Standup oder Daily Scrum genannt. Während dieses Meetings sollen die einzelnen Teammitglieder mitteilen, was sie abgeschlossen haben, woran sie gerade arbeiten und was ihren Fortschritt behindern könnte.

Ich berichtete meinen Kollegen, dass ich die von ihnen empfohlenen Bücher und Artikel gelesen hatte und dass ich bereit wäre, einige spannende Veränderungen an unserer Arbeitsweise vorzunehmen. Die Idee, alle zwei Wochen etwas fertigzustellen, schien wie ein todsicherer Schub sowohl für die Produktivität als auch die Moral, und jeden Morgen persönlich etwas Zeit miteinander zu verbringen, dürfte doch nur die Kommunikation unseres Teams verbessern. Meine erfahrenen Kollegen tauschten einen freundlichen, aber wissenden Blick aus: »Okay«, sagten sie, »lass es uns versuchen.«

Ich brauchte nicht lange, um zu begreifen, warum meine naive Begeisterung nicht unbedingt geteilt wurde. Kaum hatten wir diese neuen agilen Prozesse implementiert, wurden sie auch schon von genau den Führungskräften untergraben, die uns überhaupt erst an »Agile« verkauft hatten. Wir begannen, die Arbeit in zweiwöchigen Sprints zu planen, doch diese Sprints wurden ständig durch neue Forderungen und Prioritäten von oben durchkreuzt. In einem speziellen Fall schrieb ein Führungsmitglied eine E-Mail an ein Mitglied meines Teams und bat es, für die Dauer des Sprints an etwas anderem zu arbeiten – und, ach ja, nebenbei, bitte nichts dem übrigen Team davon erzählen. All die Funktionsstörungen und Missklänge, die bisher unsere Arbeit behindert hatten, waren immer noch vorhanden. Wir waren nicht schneller, und wir waren nicht effizienter.

Dennoch war etwas unbestreitbar anders. Jede dieser Veränderungen, die wir vorgenommen hatten, half uns auf Umwegen, etwas über unsere Organisation zu erfahren, was vorher für uns unsichtbar war. Die Priorisierung und Verpflichtung zu Leistungen in zweiwöchigen Zyklen machte deutlich, wie oft die Vision für das Produkt auf höherer Ebene in gegensätzliche Richtungen gezerrt wurde. Der allmorgendliche gegenseitige Austausch machte deutlich, wie sehr sich die einzelnen Mitglieder meines Teams von unserer gemeinsamen Mission und unseren gemeinsamen Zielen abgekoppelt hatten. Es war, als hätten die Poltergeister der organisatorischen Funktionsstörungen, die uns heimsuchten, plötzlich eine materielle Form angenommen und würden mit ektoplasmischem Kaffee in der Hand in unseren Teammeetings auftauchen.

Da nun diese Fehlfunktionen ans Licht gebracht wurden, konnten mein Team und ich einige schwierige, aber notwendige Schritte unternehmen, um sie tatsächlich zu beheben. Meinungsverschiedenheiten zwischen Teammitgliedern, die bisher die Qualität unseres Produkts beeinträchtigt hätten, wurden in unseren täglichen Meetings zur Sprache gebracht und dann in kleineren Folgegesprächen gelöst. Ich fühlte mich ermutigt, die in letzter Minute erfolgten exekutiven Änderungen zurückzudrängen, indem ich darauf hinwies, dass wir kaum etwas halb so schnell ausliefern könnten, geschweige denn doppelt so schnell, wenn wir nicht einmal zwei Wochen lang ohne drastische Kursänderungen gehen könnten. Die Macht, die einst durch List und Sabotage ausgeübt wurde, stieß nun auf klare und abgestimmte betriebliche Prozeduren. Kurz gesagt, die von der Führung eingebrachte Silberkugel entpuppte sich nun eher als trojanisches Pferd.

Die Alchemie von Agile: Prinzipien und Praktiken vereinen

Nach meinen ersten Erfahrungen mit Agile fühlte ich mich, als hätte ich eine große Entdeckung gemacht: Bei Agile ging es nicht nur um Prozesse und Werkzeuge, sondern um Menschen und Kultur! Obwohl die taktischen Veränderungen, die wir vorgenommen hatten, nicht nach Plan verliefen, haben sie uns als Team zusammengebracht und uns geholfen, die Herausforderungen zu verstehen, mit denen wir als Unternehmen konfrontiert waren. Inspiriert durch diese Erkenntnis, begann ich, etwas tiefer zu graben in der Geschichte der agilen Bewegung – einer Geschichte, die wir in Kapitel 1 ausführlicher untersuchen. Ich brauchte nicht lange, um zu erkennen, dass meine große Entdeckung eigentlich überhaupt keine Entdeckung war. Es zeigte sich, dass Menschen und Kultur die ganze Zeit über im Mittelpunkt der agilen Bewegung gestanden haben.

Dieses Wissen veränderte mein Herangehen an Agile dramatisch. Die menschlichen Werte und Prinzipien der agilen Bewegung sorgten für einen hellen und stabilen Nordstern, dem mein Team und ich folgen konnten, selbst wenn eine bestimmte Praktik »nach Lehrbuch« nicht für uns zu funktionieren schien. Dies erwies sich als besonders wertvoll, da es offenbar unzählige Bücher gibt, die Ihnen viele verschiedene Dinge erzählen. Anstatt wie gelähmt vor der Entscheidung zu stehen, welche der vielen scheinbar widersprüchlichen Ansätze von Agile »richtig« wären, fragte ich einfach: »Was kann ich aus jedem dieser Ansätze ziehen, was dem konkreten Team, mit dem ich arbeite, hilft, agile Prinzipien und Werte in die Praxis zu überführen?«

Tatsächlich ist das wirklich Mächtige an Agile nicht, dass es konkrete und umsetzbare Praktiken bietet oder durch inspirierende Prinzipien geleitet wird, sondern dass es zwangsläufig beides beinhaltet. Agile verlangt, dass wir unsere Ideale und unsere Aktionen eng aufeinander abstimmen, was uns wiederum zwingt, einige recht knifflige Fragen dazu zu stellen, warum wir die Dinge tun, die wir als Einzelpersonen, Teams und Organisationen tun.

Für diejenigen, die Agile als universelle Lösung für leicht zu erzielende operative Gewinne sehen, ist dies oftmals eine unangenehme Überraschung. Selbst wenn wir uns Agile in der Hoffnung nähern, mehr Arbeit in weniger Zeit zu leisten, sehen wir uns häufig der Herausforderung gegenüber, mehr von uns selbst einzubringen – mehr Energie, mehr Offenheit, mehr Bereitschaft, ehrlich über schwierige Fragen nachzudenken. Wie der Name schon andeutet, erwartet Agile von uns, bereit zu sein, unsere Annahmen infrage zu stellen und unsere Meinung zu ändern, was keine leichte Aufgabe ist.

In den etwa zehn Jahren seit Beginn meiner Beschäftigung mit Agile habe ich gesehen, wie sich ähnliche Geschichten in Dutzenden sehr unterschiedlicher Organisationen entwickelt haben. Ich habe mit Produkt- und Ingenieurteams bei Finanzdienstleistungsunternehmen zusammengearbeitet, die agile Praktiken in der Hoffnung eingeführt hatten, besser mit einer sich schnell ändernden Welt Schritt halten zu können. Allerdings mussten diese Teams erkennen, dass die Trägheit, die sie ihren Führungskräften und ihrer Branche zugeschrieben hatten, weitgehend das Ergebnis ihrer eigenen Angst vor Veränderungen war. Ich habe mit Marketingteams von Fortune-500-Konsumgüterunternehmen zusammengearbeitet, die agile Praktiken in der Hoffnung eingeführt hatten, eher wie Spitzentechnologie-unternehmen zu arbeiten. Und diese Teams mussten erkennen, dass sie sich überhaupt nicht der zukunftsweisenden Arbeit bewusst waren, die in den F&E-Abteilungen ihrer eigenen Firmen geleistet wurde. Meine Erfahrungen mit Agile haben mich zu einem wahren Gläubigen gemacht. Allerdings glaube ich nicht, dass Agile eine vorgefertigte Lösung für alle Probleme ist, mit denen moderne Organisationen konfrontiert sind, sondern dass Agile den Teams und Organisationen helfen kann, ihre speziellen Probleme besser zu verstehen und anzugehen.

Warum »Agil im ganzen Unternehmen«

In einem 2011 im Wall Street Journal veröffentlichten Kommentar hat der Risikokapitalgeber Marc Andreessen brillant erklärt, dass »Software die Welt frisst«. Das ist nicht allzu überraschend, denn die agilen Prinzipien und Praktiken, auf die sich so viele moderne Softwareentwicklungsteams stützen, greifen immer mehr um sich. Eine Suche nach »Agiles Marketing« oder »Agiler Vertrieb« oder »Agile Führung« liefert unzählige Artikel, Bücher und Blogbeiträge, die beschreiben, wie sich die Prinzipien und Praktiken von Agile auf eine breite Palette von Geschäftsfunktionen anwenden lassen. Das hängt zum Teil damit zusammen, dass in der Hightechwelt der Softwareentwicklung »Agile« zu einem beliebten Präfix für alle Arten von innovativen Geschäftsaktivitäten geworden ist, so wie es mit »digital« in den späten 1990ern und frühen 2000ern passiert war.

Die Kernideen von Agile über die Softwareentwicklung hinaus zu erweitern, schien ein logischer nächster Schritt zu sein. Wie Kapitel 1 erläutert, waren sich die Gründer der agilen Bewegung durchaus bewusst, dass die Werte und Prinzipien, für die sie sich einsetzten, in modernen Organisationen relevant und anwendbar waren, und zwar weit über Produkt- und Ingenieurteams hinaus. Diese Werte und Prinzipien bieten bestenfalls eine gemeinsame Sprache, die funktionale Silos aufbrechen und Organisationen in kollaborativer, kundenorientierter Arbeit vereinen kann.

In der Praxis besteht jedoch ein erhebliches Risiko, dass das Wachsen von Agile in andere Geschäftsbereiche hinein organisatorische Silos eher verstärkt, als sie aufzubrechen. Jede Funktion in einem Unternehmen verwendet ihre eigene Fachsprache, ihre eigenen spezifischen Werkzeuge und ihre eigenen spezifischen Frameworks und Methoden. Wenn wir zum Beispiel »Agile Softwareentwicklung«, »Agiler Vertrieb« und »Agiles Marketing« als eigenständige und funktionsspezifische Sammlungen von Taktiken und Methoden behandeln, verpassen wir eine entscheidende Gelegenheit, gemeinsam daran zu arbeiten, die Bedürfnisse unserer Kunden zu erfüllen. Mit anderen Worten, wir laufen Gefahr, dass »Agile für X« und »Agile für Y« die Unterschiede zwischen X und Y hervorhebt und verschärft, anstatt verschiedene Funktionen um die gemeinsamen Werte der agilen Bewegung herum zu vereinen.

Deshalb dieses Buch, mit dem ich zwei Fragen beantworten will: Wie können wir die zugrunde liegenden Prinzipien von Agile in einer Weise fassen, in der sie für den Einzelnen über Rollen und Funktionen hinweg gleichermaßen zugänglich und lehrreich sind, und was können wir tatsächlich in unserer alltäglichen Arbeit tun, um diese Prinzipien in die Praxis zu überführen?

In meiner Arbeit als Berater und Trainer habe ich festgestellt, dass die Beantwortung dieser Fragen für Produkt- und Ingenieurteams bei kleinen Start-ups genauso wichtig sind wie für Marketing- und Insights-Teams von Fortune-500-Unternehmen. Die konkreten Ansätze, nach denen diese Teams agile Werte und Prinzipien in der Praxis umsetzen, sind zwangsläufig ziemlich unterschiedlich. Doch auf diesen Werten und Prinzipien aufbauend, entstehen eine gemeinsame Sprache und eine gemeinsame Vision, die über Funktionen, Titel und sogar Organisationen hinausgehen. Agile wird als breite und integrative Bewegung typisiert, in der alle unsere Beiträge und Sichtweisen einen Wert haben. Und es bleiben uns wenige Ausreden, um unsere Anstrengungen aufzugeben, falls wir meinen, dass wir uns nicht in die erhoffte Richtung bewegen, wenn wir Agile »lehrbuchmäßig« realisieren.

In dieser Hinsicht verweist das Wort Agile in diesem Buch auf die Gesamtheit der Praktiken, Prinzipien und Werte, die man gemeinhin mit der agilen Bewegung verbindet. Viele der Praktiken, die dieses Buch beschreibt, stammen von spezifischen agilen Methoden der Softwareentwicklung, sind aber verallgemeinert worden, um den weiter gefassten umgangssprachlichen Gebrauch des Begriffs widerzuspiegeln. Um die agile Bewegung über Produkt- und Ingenieurteams hinaus zu erweitern, ist es meiner Erfahrung nach wesentlich praktikabler, einen Ansatz nach dem Muster »Das ist auch ...« zu verwenden (zum Beispiel: »Das ist auch etwas, das wir tun können, um agile Werte in die Praxis umzusetzen.«) als einen Ansatz nach dem Schema »Das ist eigentlich ...« (wie in: »Das ist eigentlich Teil dieser agilen Methode und nicht jener agilen Methode.«). Schließlich besteht unser Ziel darin, unsere Arbeitsweise zum Besseren zu ändern, das heißt praktisches Handeln über eine theoretische Debatte zu stellen.

Für wen dieses Buch gedacht ist

Dieses Buch richtet sich an jeden, der davon überzeugt ist, dass Kundenorientierung, Zusammenarbeit und Offenheit für Veränderungen im Mittelpunkt moderner Organisationen stehen sollten.

Mit den Worten eines seiner Mitbegründer (http://bit.ly/2DX9x8v) wurde die agile Bewegung gegründet auf »einer Reihe von Werten, die auf Vertrauen und gegenseitigem Respekt basieren und Organisationsmodelle fördern, die auf Menschen, Zusammenarbeit und dem Aufbau solcher organisatorischer Gemeinschaften beruhen, in denen wir arbeiten möchten«. Diese Werte und die Praktiken, die sie verkörpern, können einen dringend benötigten Weg in die richtige Richtung für Organisationen bieten, die mit Hierarchien und Silos sowie routinemäßigen und restriktiven Prozessen kämpfen.

Dieses Buch soll einen ganzheitlichen, umsetzbaren und zugänglichen Überblick über das »Warum«, »Wie« und »Was« von Agile geben. Es umreißt die Prinzipien, Praktiken und Erfolgssignale, mit denen jeder das Beste von Agile in seine Organisation einbringen kann, unabhängig von Rollen, Teams und Funktionen. Dies ist das Buch, das ich Führungskräften in die Hand geben wollte, wenn sie mir sagen: »Ich habe gehört, dass uns dieses Agile zu einer schnelleren und innovativeren Organisation machen kann«, und das Buch, das ich den Mitarbeitern in Marketing-, Vertriebs- und Beratungsrollen geben möchte, wenn sie sagen: »Wir produzieren keine Software, und ich weiß nicht so recht, wie Agile für uns arbeiten könnte.«

Speziell für Führungskräfte in Organisationen hoffe ich, dass dieses Buch ein Gefühl für Offenheit, Reflexion und harte Arbeit vermitteln kann, sodass sie schließlich die Prinzipien von Agile wirklich verinnerlichen. Die erfahrene Agile-Praktikerin Lane Goldstone, eine der vielen inspirierenden Personen, die ich für dieses Buch interviewt habe, formulierte es so: »Wenn dieses Buch auch nur eine Führungskraft dazu bringt, fürsorglicher und humaner beim Einsatz von Agile zu sein, wird es meiner Meinung nach ein Erfolg sein.«

Wie ich dieses Buch geschrieben habe

Dieses Buch begann mit Gesprächen – vielen Gesprächen – zwischen mir und Agile-Praktikern aus Dutzenden verschiedener Unternehmen, Branchen und Rollen. Einige arbeiten in der Fertigung, einige im gemeinnützigen Bereich, andere im Marketing und wieder andere im Vertrieb. Manche sind Vizepräsidenten und Führungskräfte der Vorstandsebene bei multinationalen Unternehmen, andere sind unabhängige Praktiker