On Lean and Agility

Grafik: Wikimedia Commons / Craig Chelius - CC BY 3.0

Die Geschichte der Agilität ist voller Missverständnisse, besonders dann wenn es darum geht, wie das, was wir heute die agile Bewegung nennen, entstanden ist. Das liegt zum Teil einfach daran, dass die "agiler Vor- und Frühgeschichte" der 80er und 90er Jahre mittlerweile schon etwas länger her ist, zum anderen aber auch daran, dass sie sich zu Beginn in den Schatten abgespielt hat, ohne Namen und ohne Bekanntheit. Und an dieser Stelle wird es interessant.

Bevor wir dazu kommen aber kurz zu den beiden verbreitetsten Missverständnissen über die Entstehung des agilen Produkt- oder Projektmanagements: das erste ist, dass sie 2001 in Snowbird, Utah entstanden sind, als dort das Manifest für agile Softwareentwicklung verfasst wurde. Das zweite erkennt zwar an, dass Frameworks wie Scrum, Crystal und XP deutlich älter sind als das Manifest, geht aber davon aus, dass ihre Erfinder erst in Snowbird ihre Gemeinsamkeiten erkannten (und einen Namen dafür suchten).

Dass die Wahrheit nochmal anders geartet war, kann man im Podcast The Pragmatic Engineer erfahren, genauer gesagt in der Episode TDD, AI agents and coding, in der Kent Beck zu Gast ist, der Erfinder von XP (Extreme Programming) und der erste Unterzeichner des agilen Manifests. Neben XP-Praktiken und seinen Erfahrungen mit dem Einsatz von künstlicher Intelligenz teilt er auch Geschichten rund um die Verfassung des besagten Manifests, unter anderem, das dieses einem bestimmten Zweck diente.

Und damit kommen wir zurück zur Zeit, in der die agile Bewegung keinen Namen und keine Bekanntheit hatten, denn laut Beck sollte die Zusammenkunft in Snowbird genau das ändern. Es war nämlich kein gegenseitiges Kennenlernen, das dort stattfand (fast alle Beteiligten kannten sich bereits) und auch kein Erarbeiten von Gemeinsamkeiten (das war bereits früher passiert, u.a. bei einer gemeinsamen Hurtigruten-Kreuzfahrt einiger Teilnehmer). Es ging um Marketing und Brand Building.

Die angehenden Verfasser des agilen Manifests waren sich bewusst, dass sie bereits über eine kleine aber treue Gruppe von Anhängern verfügten, der Grossteil ihrer Zielgruppe (Software-Entwickler und IT-Manager) aber noch nicht bereit war, sich auf die neuen Arbeitsweisen einzulassen. In Anlehnung an das Technology Adaption-Modell aus dem Buch Crossing the Chasm suchten sie nach einem Weg, um die Lücke zwischen den ersten Anhängern und der Mehrheit der Anwender zu überwinden.

"Agile" oder die anderen in Snowbird erwogenen Namen, wie "Adaptive" oder "Lightweight" waren bewusst gedacht als einfache, attraktive und wirkmächtige "Dachmarken", mit deren Hilfe es einfacher werden sollte, die verschiedenen dahinterstehenden Frameworks bekannt und populär zu machen und so dafür zu sorgen, dass möglichst viele Softwareentwickler zu deren Anwendern werden konnten, wollten und in ihren Firmen auch durften.

Die Ironie dieser Geschichte liegt darin, dass der gewählte Vermarktungsansatz am Ende zu erfolgreich war - zumindest in der rückwirkenden Betrachtung von Kent Beck. Dadurch, dass fast ausschliesslich die positiven Effekte im Mittelpunkt der Aussendarstellung standen, wollten plötzlich auch Menschen und Organisationen dieses Label tragen, die die notwendigen Kriterien gar nicht erfüllten. Hierin liegt sicherlich einer der Ursprünge von Cargo Cult Agile und dem agil-industriellen Komplex.

Wie es besser gegangen wäre hat im Übrigen ebenfalls Kent Beck gezeigt, und auch darüber berichtet er im Pragmatic Engineer-Podcast. Für sein eigenes Framework Extreme Programming hat er einen Namen gefunden, der einerseits gut vermarktbar ist, andererseits aber klar macht, dass es anspruchsvoll und anstrengend sein kann, so zu arbeiten. Man kann lange darüber spekulieren, welchen Weg die agile Bewegung wohl gegangen wäre, wenn man sie auf diese Weise vermarktet hätte.

Bild: Wikimedia Commons / Japanische Akademie der Wissenschaften - CC BY 4.0

Manchmal kommen die tragischen Entwicklungen schnell und unverhofft. Nur zwei Tage nachdem ich sein bahnbrechendes Paper The New New Product Development Game empfohlen habe ist Ikujirō Nonaka gestorben, einer der grossen Vordenker der Methoden, die wir heute ale Agil bezeichnen würden. Was dadurch in Erinnerung gerufen wird: leider müssen wir uns in den nächsten Jahren auf weitere derartige Trauer-Nachrichten einstellen - und die werden Folgen haben.

Zur Einordnung: grossteils aufbauend auf das oben erwähnte Paper sind die meisten agilen Vorgehensmodelle (Scrum, XP, IT-Kanban, Agile Testing, etc) zwischen den späten 80er und frühen 2000er Jahren entstanden. Da ihre Erfinder bereits damals über einige Jahre oder sogar Jahrzehnte Berufserfahrung verfügten, sind sie mittlerweile in ihren 60ern, 70ern oder 80ern angekommen. Und obwohl sie hoffentlich noch lange leben werden - nicht jeder dürfte 90 werden, so wie Nonaka.

Das ist deshalb von Bedeutung, weil diese Vordenker bisher durch ihre öffentlichen Meinungsäusserungen ein Korrektiv zu den verbreiteten esoterischen oder komerziell getriebenen Fehldeutungen ihrer Arbeit bilden konnten, legitimiert dadurch, dass sie schliesslich selbst am Besten sagen können, was sie mit ihren Ansätzen beabsichtigt haben und was nicht (das bekannteste Beispiel dafür dürfte ihre einhellige Ablehnung des Scaled Agile Framework / SAFe sein).

Mit dem absehbaren Verschwinden dieser Stimmen (das auch bereits durch einen altersbedingten Rückzug aus der Öffentlichkeit geschehen kann) dürfte es in der Zukunft immer weniger mit einer derartigen Autorität ausgestattete Widersprüche gegen absichtliche oder versehentliche Verfremdungen der agilen Ideen und Prinzipien geben. Und noch bedenklicher: kommerzielle Organisationen wie Scrum Alliance, SAFe, Kanban University und PMI werden diese Autorität vermutlich für sich beanspruchen.

Um so wichtiger wird es werden, die von den agilen Pionieren verfassen Originalquellen (von denen es aufgrund der Entstehung der Agilität in den Schatten ohnehin viel zu wenige gibt) in Erinnerung zu behalten und als Massstab für die Bewertung neuer Entwicklungen zu benutzen, von der Forschung Nonakas und Takeuchis über die frühen Vorträge auf den OOPSLA- und Agile-Konferenzen bis zu den Büchern und Artikeln der Verfasser des Manifests für agile Softwareentwicklung.

Die grosse Herausforderung dabei wird es sein, derartig auf den Schultern der Riesen zu stehen, dass deren Absichten gewahrt bleiben, ohne dass es zu einer rückwärtsgewandten Erstarrung der damit verbundenen Methoden kommt. Andererseits - verglichen mit dem, was zwischen den späten 80er und frühen 2000er Jahren geleistet wurde, ist das eine fast schon einfache Aufgabe. Und noch haben wir genug Zeit um uns von den agilen Vordenkern inspirieren zu lassen.

Sobald ein agiles Framework ein gewisses Alter überschritten hat, entstehen in der Regel nach und nach verschiedene Varianten, die anfangs noch aufeinander aufbauen, später aber parallel zueinander existieren. Das ist bei Scrum und bei Kanban so gewesen, und es ist auch bei Objectives und Key Results (OKR) so. Da die neueren OKR-Varianten sich z.T. zu erstaunlich schwerfälligen Prozessframeworks entwickelt haben, lohnt ein Blick zurück - denn eigentlich ist es ursprünglich anders gedacht gewesen.

Wie immer bei derartigen Übersichten ist auch diese hier subjektiv, sie umfasst aber meiner Meinung nach die wichtigsten Spielarten und Entwicklungsstufen, bzw. die wichtigsten Vordenker. In der Realität dürften darüber hinaus noch zahlreiche Abwandlungen und Mischtypen anzutreffen sein, diese Liste hier dürfte aber die relevanten umfassen (wenn ich etwas übersehen haben sollte, freue ich mich über einen Hinweis, der hier abgegeben werden kann). Aber zur Sache, hier sind die Evolutionsstufen:

MBOSC (Management by Objectives and Self-Control)

Eine Früh- oder Vor-Version der heutigen OKRs, beschrieben in den 50er Jahren von Peter Drucker in seinem Buch The Practice of Management. Mit dezentraler Planung, Trennung von abstrakten Zielen und konkreten Ergebnissen und mit Zyklen von weniger als einem Jahr waren die Grundzüge der heutigen Praktiken bereits enthalten. Unter dem Namen Management by Objectives (MBO) wurde Druckers Ansatz leider später zu einem jährlichen Kontroll- und Budgetierungsinstrument verfremdet (siehe hier).

Ursprüngliche OKRs (Intel MBOs)

Die Ursprungsversion, entwickelt in den 70er Jahren von Intel-CEO Andy Grove und beschrieben in seinem Buch High Output Management. Grove definierte neben den abstrakten Zielen (Objectives), den konkreten Ergebnissen (Key Results) und den kurzen Zyklen (maximal ein Jahr) kaum Vorgaben zur Umsetzung, entwickelte aber schon die Idee "kaskadierender Objectives", die auf den unteren Hierarchie-Ebenen in Teilziele heruntergebrochen werden, und von denen jede eigene Key Results hat.

"Die" OKRs (Google OKRs)

Die Variante, die berühmt geworden ist. Der ehemalige Intel-Mitarbeiter John Doerr führte die OKRs bei Google ein, wo sie um weitere Teile ergänzt wurden, u.a. um die Begrenzung des Zyklus auf ein Quartal, um die Differenzierung in "committed" und "aspirational OKRs", die Einführung gemeinsamer OKRs für mehrere Teams und um eine nachträgliche Bewertung in Ampelfarben. Das von vielen anderen Firmen kopierte Google OKR Playbook findet sich abgedruckt in Doerrs Buch Measure What Matters.¹

Silicon Valley OKRs

Die verschiedenen Unternehmen des Silicon Valley, die als erste den OKR-Ansatz von Google übernommenen haben, haben ihn mit der Zeit ebenfalls weiterentwickelt. Die bekanntesten Praktiken findet man zusammengefasst in Cristina Wodkes Buch Radical Focus, zu ihnen gehört u.a. die Beschränkung auf nur ein einziges, nach Möglichkeit firmenweites Objective pro Zyklus,² die dezentrale Erarbeitung der Key Results durch die Teams und die Einführung regelmässiger OKR-Meetings.

Scrumifizierte OKRs

Wer auf die Idee gekommen ist, die OKR-Meetings analog zu denen aus Scrum zu organisieren, lässt sich vermutlich nicht mehr feststellen, aber er hat einen Trend gesetzt. OKR-Plannings, OKR-Dailies/Weeklies, OKR-Reviews und OKR-Retrospektiven sind mittlerweile weit verbreitet, und für die Organisation und Moderation dieser Termine gibt es einen an den Scrum Master oder Agile Coach angelehnten OKR Master oder OKR Coach.³

Agile Industrial Complex OKRs

Dass angessichts dieser Geschichte einer immer stärkeren Formalisierung auch das Kommerzialisierungs-Potential gestiegen ist, dürfte wenig überraschen. Der agil-industrielle Komplex hat seit ca 2020 auch die OKR-Idee mit weiteren Regeln, Rollen, Formulierungs-Templates, prozessunterstützender Software und Ähnlichem überflutet, die dann in den Trainings und Zertifizierungsprüfungen auftauchen können. Genau wie im Fall von Scrum und Kanban übrigens mit teuren aber meistens überschaubaren Ergebnissen.

Gerade vor dem Hintergrund dieser letzten "Evolutionsstufe" ist es nicht verwunderlich, dass OKRs vor allem in grossen Organisationen eher als Management-Mode wahrgenommen werden und weniger als etwas Sinnvolles. In derartigen Fällen können die hier verlinkten Grundlagen-Bücher gegebenenfalls Klarheit bringen. Aus ihnen lässt sich erkennen, was der eigentliche Kern der Idee ist, und bei was es sich um Overhead handelt, der auch weggelassen werden kann.

Zu den grossen "agilen Trends" der letzten Jahre gehören die Objectives and Key Results (OKRs), eine Methode um persönliche oder übergreifende Ziele, von der man sich einen einfacheren oder besseren Weg zur Agilität erhofft. Die damit erzielten Ergebnisse schwanken allerdings stark, von deutlichen Verbesserungen bis deutlichen Verschlechterungen ist alles dabei. Meine steile These dazu: man kann absehen was davon der Fall sein wird, und dafür muss man nur betrachten wie vorher mit einem anderen Ansatz umgegangen worden ist - dem Management by Objectives (MBO).

Bevor wir darauf eingehen eine kurze Begriffsbestimmung. OKRs wurden von Andrew Grove bei Intel entwickelt und von seinem damaligen Mitarbeiter John Doerr später bei Google eingeführt und dadurch popularisiert. Sie teilen Ziele in qualitative Objectives und quantitative Key Results auf, von denen die ersten abstrakt-übergreifend und die zweiten davon abgeleitet und konkret überprüfbar sind. In der Umsetzung werden Objectives quartalsweise gesetzt und durch Key Results nach und nach erreicht.

Dass dieser Ansatz flexibler (und agiler?) als die sonst üblichen starren Jahresziele ist, liegt auf der Hand, und tatsächlich ist er als bewusste Weiterentwicklung, bzw. Ablösung eines Vorgehensmodells entwickelt worden, mit dem diese in den meisten Fällen umgesetzt werden, eben dem MBO. Grove und Doerr weisen in ihren Büchern High Output Management (Grove, 1983) und Measure what Matters (Doerr, 2017) explizit auf diese Art der Entstehung hin.

[Before the introduction of OKRs], goals were centrally planned and sluggishly trickled down the hierarchy. At others, they became stagnant for lack of frequent updating; or trapped and obscured in silos; or reduced to key performance indicators (KPIs), numbers without soul or context. Most deadly of all, MBOs were commonly tied to salaries and bonuses.

John Doerr: Measure What Matters, S.25

Besonders der letzte Punkt ist dabei erwähnenswert, da er den durch ihre Langfristigkeit immer realitätsferner werdenden MBOs eine destruktive Dynamik hinzufügt: die Koppelung der Zielerreichung an Gehaltsbestandteile. Es ist eine menschliche, bzw. betriebswirtschaftliche Reaktion - um den vollen Bonus ausgezahlt zu bekommen, werden alle Ziele konsequent umgesetzt, und zwar auch dann wenn sie mittlerweile als unsinnig erkannt wurden. Geld sticht Sinn.

Die Rollen sind damit klar verteilt. Alt und neu, überkommen und modern, starr und flexibel, Objectives and Key Results und Management by Objectives. Wie fast immer bei derartig klaren Gegensätzen gilt aber auch hier, dass sie zu einfach sind um wahr zu sein. Betrachtet man das Buch in dem die MBOs erstmals beschrieben wurden, The Practice of Management, geschrieben 1954 vom österreichisch-amerikanischen Ökonomen Peter Drucker, entdeckt man Erstaunliches.

The most effective managers I know [...] have each of their subordinates write a “manager’s letter” twice a year. In this letter to his superior, each manager first defines the objectives of his superior’s job and of his own job as he sees them. He then sets down the performance standards which he believes are being applied to him. Next, he lists the things he must do himself to attain these goals—and the things within his own unit he considers the major obstacles. He lists the things his superior and the company do that help him and the things that hamper him. Finally, he outlines what he proposes to do during the next year to reach his goals.

Peter Drucker: The Practice of Management, S. 343

Mit anderen Worten: das was OKRs ausmacht und es angeblich von den MBOs unterscheidet ist in diesen bereits enthalten. Die dezentrale Planung, die Trennung von Zielen und Ergebnissen, die Möglichkeit zu Anpassungen während des Jahres, all das war von Drucker bereits so angedacht. Und selbst die durch die Knüpfung an Gehaltsbestandteile durchgeführte Steuerung von oben war nicht in seinem Sinn, stattdessen spach er bewusst von Management by Objectives and Self-Control.

Reports and procedures should be the tool of the man who fills them out. They must never themselves become the measure of his performance.

Peter Drucker: The Practice of Management, S. 359

Die Betrachtung des MBO wird damit komplett auf den Kopf gestellt - nicht der Ansatz selbst ist problematisch, sondern seine falsche Umsetzung, nicht er selbst beinhaltet Top Down-Management, fehlende Flexibilität und nicht zielführende Anreizgebung, sondern die Menschen die ihn umsetzen bringen diese Ideen mit und überschreiben damit die in ihrem Ursprung komplett in die andere Richtung orientierten Umsetzungs-Empfehlungen.

Und damit kommen wir zurück zur Eingangs-These: will man voraussagen können wie eine Organisation mit Objectives and Key Results klarkommen wird, muss man eigentlich nur überprüfen wie sie mit Management by Objectives umgeht. Setzt sie dieses wie ursprünglich gedacht ein, werden auch OKRs gut funktionieren, verfremdet sie es bis in ihr Gegenteil wird sie das mit grosser Wahrscheinlichkeit auch mit OKRs tun. Da so ziemlich jede halbwegs grosse Firma bewusst oder unbewusst mit MBO arbeitet, ist das eine erstaunlich effektive Art der Überprüfung.

Irgendwann reichte es ihm. Die Social Media-Plattform, auf der er seit über zehn Jahren zahllose Beiträge gepostet hatte, hatte sich nach einem Management-Wechsel mehr und geändert. Die Usability wurde schlechter, der Diskussionston rauher, die Kommerzialisierungs-Bemühungen aggressiver. Er wollte kein Teil davon sein, also zog er die Konsequenzen: er löschte seinen Account, und mit ihm alle Beiträge die er jemals erstellt hatte.

Um welche Social Media-Plattform es in dieser Geschichte geht kann man sich leicht vorstellen, es ist Twitter, bzw. X nach seiner Übernahme durch Elon Musk. Welcher Nutzer es ist, der seinen Account gelöscht hat, ist dagegen weniger offensichtlich, daher hier die Auflösung: es ist Chet Hendrickson, einer der Pioniere des Extreme Programming und einer der Verfasser des Manifests für agile Softwareentwicklung. Und damit kommen wir zum Thema dieses Beitrags.

Aufgrund ihrer Entstehung "in den Schatten" sind die ersten Jahre der verschiedenen agilen Frameworks (im Wesentlichen die 90er) kaum dokumentiert worden, schliesslich war damals noch nicht absehbar welche Bedeutung sie später bekommen würden. Diese unklare Entstehungsgeschichte hat an vielen Stellen zu Missverständnissen und Fehlinterpretationen geführt, zum Teil auch zu einer missbräuchlichen Begriffsverwendung.

Das Korrektiv zu diesen Tendenzen waren und sind die Urheber der verschiedenen agilen Frameworks selbst, die bis heute regelmässig darauf aufmerksam machen, wie ihre Ideen eigentlich gedacht waren und an welcher Stelle sie von anderen missverstanden und verfälscht werden. Ein Grossteil dieser Zwischenrufe (bzw. zumindest derer die dokumentiert sind) fand und findet auf Twitter/X statt, z.B. zum Ursprung des Begriffs User Story oder zu Missverständnissen um die Story Point-Schätzung.

Quelle: Twitter

Quelle: Twitter

An dieser Stelle wird das Problem erkennbar: viele der Pioniere der agilen Softwareentwicklung sind mittlerweile im hohen Alter angekommen, so dass abzusehen ist, dass ihre korrigierenden Zwischenrufe zurückgehen und irgendwann verstummen werden. Allerdings konnte man bis vor kurzem davon ausgehen, dass ihre Dokumentation auf Twitter/X bestehenbleiben würde, so dass es im Zweifel möglich wäre, auf sie zu referenzieren.

Angesichts der aktuellen Entwicklung bei Twitter/X muss man allerdings befürchten, dass dieses Archiv in seinem Bestand gefährdet ist. Die zu Beginn genannten Beiträge von Chet Hendrickson sind bereits verschwunden, mit Ron Jeffries und Martin Fowler haben schon weitere Pioniere und Verfasser des agilen Manifests ihren Unmut mit der aktuellen Entwicklung bekundet. Und sollte Elon Musks Plan umgesetzt werden, Twitter/X kostenpflichtig zu machen, könnte das zur Löschung weiterer bedeutender Accounts führen, deren Inhaber nicht bereit sind, Geld an ihn zu zahlen.

Ob es wirklich so kommen wird? Keiner kann es sagen, aber unwahrscheinlich ist es leider nicht mehr. Was kann man dagegen machen? Nichts, es sei denn man gehört zu den Menschen, die Elon Musk oder die Pioniere der agilen Bewegung beeinflussen können. Sind diese Daten irgendwo gesichert? Nur zum Teil in der Wayback Machine und unzugänglich ("embargoed") in der Library of Congress. Man kann eigentlich nur zusehen und abwarten was passiert.

Zugegeben, wir reden hier von einem Thema, das sehr in Richtung "Special Interest" geht. Aber für die Disziplinen der Technik- und Management-Geschichte und für alle, die daran interessiert sind, wie die verschiedenen agilen Praktiken und Frameworks entstanden sind und ursprünglich gedacht waren, wäre der Verlust der Dokumentation bei Twitter/X wirklich, wirklich schade.

Nachtrag 26.11.2024:

Der oben erwähnte Ron Jeffries, Mitautor des Agilen Manifest, Miterfinder von Extreme Programming, Erfinder der Story Points und einer der ersten Anwender von Scrum hat seinen X-Account gelöscht. Hunderte Erfahrungsberichte, Diskussionsbeiträge und Erklärungen - weg.

Bild: Pexels / Ketut Subiyanto - Lizenz

Obwohl das was wir heute als agile Software- oder Produktentwicklung kennen nach und nach entstanden ist, gab es einige im Rückblick entscheidende Momente. Den etwa, in dem sich zwei Wissenschaftler bei einer Fabrikbesichtigung an ihren Lieblingssport erinnert fühlten, den, in dem einige Software-Entwickler realisierten, dass sie um effektiver zu werden nichts Neues machen mussten, sondern nur Bestehendes häufiger wiederholen, und auch einen weiteren, dessen Anbahnung folgendermassen beschrieben wurde:

I had been working as an agile coach for a few years when a colleague said to me, “You know, there’s a whole world of professional coaching out there. Maybe you should check it out.” This was his diplomatic way of saying, “You call yourself a coach, but you’re really not one.” He was right.

Lyssa Adkins, Coaching Agile Teams, S.121

Die Passage stammt aus einem der klassischen und noch immer wärmstens zu empfehlenden "agilen Standardwerke", Coaching Agile Teams von Lyssa Adkins, und handelt von ihr selbst. Zum hier beschriebenen Zeitpunkt hatte sie bereits seit einiger Zeit agil arbeitende Teams begleitet und war auf der Suche nach einem Begriff, mit dem sich ihr Beruf beschreiben liess, irgendwie bei dem Wort Coach gelandet, das sie als Agile Coach für sich übernahm und durch ihr Buch bekannt machte.

Was sie zu Beginn nicht wusste, und was ihr der in ihrem Buch zitierte namenlose Kollege dezent sagen wollte, war, dass ihr damit ein Irrtum unterlaufen war. Sie hatte zwar einige Aspekte des Coach-Berufs richtig erkannt und zutreffenderweise in ihrem Alltag wiedergefunden, hatte aber damit den Fehlschluss verbunden, dass es sich bei allen von ihr ausgeübten Tätigkeiten um Aspekte des Coachings handeln würde. Tatsächlich hatte einiges davon aber einen ganz anderen Hintergrund.

Ein kurzer Exkurs. Um zu definieren was ein Coach ist (und was er nicht ist) wird er von ähnlichen, bei näherer Betrachtung aber unterschiedlichen Berufen abgegrenzt. Üblicherweise (wie z.B. hier bei der International Coaching Federation) sind das die Berufe des Therapeuten, Beraters, Mentors, Lehrers/Ausbilders und Sport-Trainers.¹ Sie alle haben die Unterstützung anderer Menschen zum Ziel, unterscheiden sich vom Coach aber in einem Punkt: sie haben eine eigene Agenda.

Egal ob es sich um Gesundheit, Prozess-Optimierung, Erfahrungsweitergabe, Wissensvermittlung oder körperliche Fitness handelt - allen ist gemeinsam, dass der Therapeut, Berater, Mentor, Lehrer oder Trainer ein Vorwissen hat, das er für richtig hält und weitergibt. Coaching ist grundsätzlich anders: der Coach richtet sich nach den Wünschen und Bedürfnissen des Coachees,² hift ihm diese umzusetzen und stellt die eigene Meinung in den Hintergrund.

Ende des Exkurses, zurück zu Lyssa Adkins und ihrem Kollegen. Was diesem aufgefallen war ist, dass Adkins in ihrer Beschreibung des Agile Coaches auch Aspekte einschloss, in denen die eigene Agenda explizit nicht im Hinter- sonder im Vordergrund stand, u.a. Mentoring, Beratung, Ausbildung und (Konflikt-)Moderation. Und damit kommen wir zu dem für die agile Software- und Produktentwicklung entscheidenden Moment: sie stimmte ihm zu, behielt den Begriff des Agile Coach aber bei.

A serious point of ethics for professional coaches holds that the coachee’s agenda must be the single guiding light of the coaching relationship. The coach exists solely for the coachee, not so for us. We can’t let the coachee’s agenda rule completely because we must also mix in our agenda: to influence the coachee to use agile well. Again, it’s no big deal; just know that we are coach-like.

Lyssa Adkins, Coaching Agile Teams, S.123

Was sie hier so beiläufig umschreibt liesse sich überspitzt und mit anderen Worten auch so formulieren: "Für unsere Version des Coach-Berufs entfernen wir einen Kernbestandteil dessen was ihn eigentlich ausmacht und ersetzen ihn durch sein Gegenteil. Macht aber nichts, wir machen das ja aus einem guten Grund. Wir sollten uns nur bewusst sein, dass wir keine Coaches im eigentlichen Sinn sind, sondern lediglich Coach-ähnlich." Oder noch drastischer: "Der Agile Coach ist eigentlich gar kein Coach."

Wie oben erwähnt, Coaching Agile Teams ist direkt mit seinem Erscheinen 2010 zu einem Standardwerk geworden und hat den Begriff des Agile Coaches schlagartig bekanntgemacht und popularisiert. Hätte Adkins einen anderen benutzt (in ihrem Buch spricht sie z.B. auch vom Conductor oder Facilitator) würden wir heute möglicherweise vom Agile Conductor oder Agile Facilitator sprechen. Alleine, es war wie es war, und jetzt haben wir einen Beruf der sich Coach nennt, aber eigentlich keiner ist.

Von entscheidender Bedeutung ist das deshalb, weil wir jetzt damit leben müssen, dass das Wort Coach innerhalb der agilen Bewegung eine andere Bedeutung hat als ausserhalb. Alleine das wäre für sich genommen schon eine Kommunikations-Herausforderung, aber an einer zentralen Stelle wird die sogar noch einmal verschärft. Viele Manager lassen sich heute selbst coachen, wissen also was damit eigentlich gemeint ist. Für sie ist der Schluss von Lyssa Adkins Kollege naheliegend: da behauptet jemand, dass er Coach ist, hat aber offensichtlich nicht verstanden was das bedeutet.

Natürlich lässt sich das aufklären, indem man die Begriffsentstehung erläutert und klar macht, dass einem Agile Coach (hoffentlich) bewusst ist, dass er zwar Coaching-Techniken anwendet, sich aber von einem eigentlichen Coach in Zielsetzung und Vorgehen bewusst unterscheidet. Und natürlich sind derartige semantische Feinheiten vielen Menschen einfach egal. Unter dem Strich bleibt aber, das wir mit dem Agile Coach einen missverständlichen Begriff zentral platziert haben und ständig erklären müssen.

Zum Ende eine Klarstellung: sowohl über Lyssa Adkins als auch über ihr Buch kann man nur Gutes sagen. Es ist und bleibt ein Klassiker und ein Meilenstein. Sie hat aber mittlerweile selbst gesagt, dass sie den Begriff des Agile Coach in ihm nicht verwendet hätte, wenn sie geahnt hätte, welche Karriere er machen würde. Aber das ist mittlerweile nicht mehr zu ändern, der Name und der Beruf haben sich etabliert und werden uns vermutlich noch lange begleiten.