Ward Cunningham: Gemeinsames Verständnis schaffen

10 Min. Lesezeit

Er machte Verständnis zu etwas, das Teams bauen können

Das Muster hinter den bekannten Ideen

Die Softwaregeschichte liebt saubere Etiketten. Erfinder des Wiki. Urheber der Metapher technischer Schulden. Schöpfer der CRC-Karten. Mitgestalter von Extreme Programming. Unterzeichner des Agilen Manifests.

Alles wahr. Und doch ein wenig irreführend.

Interessant ist nicht, dass eine Person eine beeindruckende Liste von Beiträgen angehäuft hat. Interessant ist, dass diese Beiträge immer denselben Fehler angreifen: Wichtiges Verständnis wird eingeschlossen. Es steckt im Kopf eines Entwicklers, in einem Dokument, das niemand gefahrlos bearbeiten kann, in einem Architekturdiagramm, das die Produktion schon belügt, oder in einem Managementbericht, der so lange poliert wurde, bis keine Unsicherheit mehr übrig ist.

Cunningham wählte immer wieder eine andere Form. Machen Sie das Medium einfach. Legen Sie es zwischen die Menschen. Lassen Sie sie es verändern, während sie noch lernen. Halten Sie die Kosten einer Korrektur niedrig.

Das klingt beinahe altmodisch in einer Branche, die gerade von Plattformen, Betriebsmodellen und KI-Systemen fasziniert ist, die das Wissen einer Organisation aufnehmen sollen. Der teure Teil war aber nie das Speichern. Es ging darum, genug gemeinsames Verständnis zu schaffen, damit Menschen die nächste gute Entscheidung treffen können.

CRC-Karten legen Design auf den Tisch

1989 veröffentlichten Cunningham und Kent Beck A Laboratory for Teaching Object-Oriented Thinking. Der Aufsatz stellte CRC-Karten vor: gewöhnliche Karteikarten mit einem Klassennamen, ihren Verantwortlichkeiten und ihren Zusammenarbeitspartnern.

Es gab keine Modellierungssuite. Keine Repository-Verwaltung. Keinen Zertifizierungspfad. Eine Karte kostete fast nichts, ließ sich über einen Tisch schieben, umschreiben, aufteilen, gruppieren oder wegwerfen, ohne dass ein Führungsgremium erst das Rechteck genehmigen musste.

Diese physische Einfachheit war wichtig. Die Karten gaben einem Team ein Vokabular, um über einen Entwurf zu sprechen, ohne das Gespräch in Syntax zu ertränken. Menschen konnten ein Szenario durchspielen, die Karte eines Objekts aufnehmen, merken, dass es zu viele Verantwortlichkeiten hatte, und einen Zusammenarbeitspartner schaffen, wenn der Entwurf das verlangte. Unbekanntes wurde zu freien Stellen auf dem Tisch statt zu peinlichen Lücken in einem polierten Diagramm.

Die Methode verweigerte auch erfundene Vollständigkeit. Beck und Cunningham rieten, Objekte als Antwort auf gegenwärtige Anforderungen zu schaffen, nicht für mythische künftige Bedürfnisse. Diese eine Einschränkung beseitigt eine heroische Menge Architekturtheater. Sie hält Design an Evidenz gebunden und macht die nächste Entscheidung umkehrbar.

Cunningham beschrieb CRC-Sitzungen später als einen Weg, Programmierentscheidungen gemeinsam durchzuarbeiten. Das ist der tiefere Beitrag. Das Ergebnis war nicht der Stapel Karten. Es war das gemeinsame mentale Modell, das beim Verschieben entstand.

Das Wiki beseitigte die Veröffentlichungshürde

Cunningham begann 1994 mit der Programmierung von WikiWikiWeb und stellte es im März 1995 als Teil des Portland Pattern Repository ins Netz. Das Design war fast beleidigend freizügig: Eine Seite besuchen, sie im Browser bearbeiten, einen Link anlegen und das Material besser hinterlassen, als man es vorgefunden hat.

Unternehmenssysteme für Wissen funktionieren meist andersherum. Eine kleine Gruppe veröffentlicht die offizielle Wahrheit. Alle anderen konsumieren sie, bemerken die Fehler, arbeiten um sie herum und schaffen irgendwann eine zweite, inoffizielle Wahrheit im Chat. Bis das offizielle Dokument aktualisiert ist, vertrauen die Menschen, die die Arbeit machen, ihm nicht mehr.

Das Wiki beseitigte die Distanz zwischen Leser und Autor. Es behandelte Wissen als etwas, das eine Gemeinschaft pflegt, nicht als etwas, das eine Autorität abschließt. Wikipedia machte dieses Modell später weltweit bekannt, doch sein Wert innerhalb von Softwareteams ist genauso wichtig. Runbooks, Designnotizen, Muster, Entscheidungen und betriebliche Erkenntnisse werden besser, wenn die Person, die einen Fehler entdeckt, ihn sofort beheben kann.

Diese Offenheit war keine Nachlässigkeit. Sie war eine Wette darauf, dass sichtbare, umkehrbare Änderungen und aktive Beteiligung besseres gemeinsames Wissen hervorbringen als eine Veröffentlichungswarteschlange. Viele Organisationen bevorzugen noch immer die Warteschlange. Sie fühlt sich kontrolliert an, bis die wunderschön kontrollierte Seite jemanden zum falschen Schalter in der Produktion schickt.

Technische Schulden verteidigten das Lernen

In seinem Erfahrungsbericht von 1992 über das WyCash-Portfolioverwaltungssystem beschrieb Cunningham ein Produkt, das aus einem funktionierenden Prototypen schrittweise gewachsen war. Kunden lernten. Der Markt veränderte sich. Die Entwickler überarbeiteten reife Teile des Systems wiederholt, damit der Code weiter ausdrückte, was sie nun verstanden.

Die berühmte Metapher erscheint in diesem Zusammenhang. Ersten Code auszuliefern kann das Lernen beschleunigen, so wie ein Kredit eine Investition beschleunigen kann. Der Handel bleibt nur vernünftig, wenn das Team die unreifen Teile zügig umschreibt. Bleiben sie unkonsolidiert, zahlt jede spätere Änderung Zinsen in Form von Verwirrung, Spezialisierung und Angst.

Die Managementkultur hat die Wendung seither zu einem beruhigenden Substantiv verstümmelt. Jede Doppelung, veraltete Abhängigkeit, fehlende Tests und unangenehme Module landen im Eimer der technischen Schulden. Das Etikett klingt finanzkundig, also wächst das Backlog mit dem Anschein verantwortungsvoller Buchhaltung.

Cunninghams Fassung war schärfer. Die Schulden entstehen, weil die Umsetzung dem Verständnis vorausgeeilt ist. Rückzahlung heißt, die Software so zu verändern, dass sie ausdrückt, was das Team gelernt hat. Das braucht die Befugnis, Code wieder anzufassen, nicht nur ein Dashboard, das schätzt, wie schuldig sich alle fühlen sollen.

Die Metapher gab auch Verantwortlichen im Geschäft und Entwicklern eine Sprache, die sie gemeinsam sprechen konnten. Tempo jetzt kann vernünftig sein. Später nicht für dieses Tempo zu zahlen, ist kein Tempo. Es ist die Entscheidung, jede künftige Änderung schwerer zu machen.

Extreme Programming machte Feedback zur Arbeitspraxis

Cunninghams Arbeit mit Beck und anderen prägte die Praktiken und die Gemeinschaft rund um Extreme Programming. Er hatte bereits erlebt, wie Paare an einer Smalltalk-Maschine arbeiteten, die Kontrolle wechselten, dasselbe Problem prüften und folgenschwere Entscheidungen gemeinsam trafen. Die Zusammenarbeit war keine Übung für die Stimmung. Sie war ein Weg mit hoher Bandbreite für Urteilsvermögen.

Dasselbe Muster zeigt sich in inkrementellem Design, Refactoring, gemeinsamer Verantwortung, automatisierten Tests und häufigen Releases. Halten Sie das Los klein. Machen Sie den aktuellen Stand sichtbar. Lassen Sie eine andere Person die Entscheidung hinterfragen, bevor sie zur Folklore erstarrt. Verändern Sie die Software, wenn neues Wissen das Modell verändert.

2001 unterzeichnete Cunningham mit sechzehn anderen in Snowbird das Manifest für Agile Softwareentwicklung. Was folgte, war vorhersehbar: Ein Argument für Menschen, Zusammenarbeit und funktionierende Software wurde zu einer Branche aus Rollen, Zeremonien, Skalierungsdiagrammen und Reifegradbewertungen.

Wards eigene Arbeit ist ein nützliches Gegenmittel gegen diese Drift. CRC-Karten waren wertvoll, solange Menschen sie bewegten. Ein Wiki war wertvoll, solange Menschen es bearbeiteten. Technische Schulden waren nützlich, wenn Teams sie zurückzahlten. XP zählte, wenn Software Nutzer erreichte und die Realität in die nächste Entscheidung zurückfloss.

Ein Ritual, das die Arbeit nicht mehr verändert, ist keine Disziplin. Es ist Kulisse.

Gemeinsames Verständnis ist ein betrieblicher Vermögenswert

Hier hört Cunninghams Arbeit auf, Softwaregeschichte zu sein, und wird zu einem Problem für die Führung.

Ein Unternehmen kündigt ein Projekt zur Workflow-Automatisierung an. Der Betrieb kennt die Ausnahmen. Die Finanzabteilung weiß, welche Zahlen aufgehen müssen. Ein Anbieter kennt die Plattform. Entwickler wissen, wo die Integrationen brechen werden. Das Management kennt das beabsichtigte Geschäftsergebnis. Alle haben ein Stück. Niemand besitzt das Gespräch, das diese Stücke zu einem System macht.

Die übliche Antwort sind mehr Übergaben. Anforderungen werden gesammelt, normalisiert, genehmigt, mit Tickets versehen, umgesetzt, getestet und vorgeführt. Jede Phase erzeugt Belege dafür, dass ihre eigene Phase stattgefunden hat. Das gemeinsame Verständnis existiert trotzdem nicht.

Cunninghams Werkzeuge legen eine weniger glamouröse Antwort nahe: Bringen Sie die Menschen und das sich entwickelnde Modell an denselben Ort. Verwenden Sie eine Sprache, die alle hinterfragen können. Arbeiten Sie konkrete Szenarien durch. Machen Sie Entscheidungen sichtbar. Lassen Sie neue Evidenz das Modell verändern. Halten Sie die Umsetzung nah genug, damit das Gespräch zu funktionierender Software werden kann, bevor das institutionelle Gedächtnis die schwierigen Teile herausredigiert.

Darum ist auch Softwarefluss kein Prozesstheater. Fluss ist die Bewegung des Lernens durch Entscheidungen bis in die Produktion. Ein Board voller wandernder Tickets kann perfekt mit Wissen in Silos koexistieren.

Einfach heißt nicht beliebig

Cunningham wird eng mit der Disziplin verbunden, das Einfachste zu tun, das möglicherweise funktionieren kann. Vorhersehbar wird der Slogan oft benutzt, um oberflächliches Denken zu entschuldigen.

Sein Gesamtwerk weist in die entgegengesetzte Richtung. Einfachheit schuf Raum für Korrektur. Karteikarten konnten sich ändern, weil sie billig waren. Wiki-Seiten konnten besser werden, weil Bearbeiten unmittelbar war. Inkrementelle Software konnte sich anpassen, weil das Team das Gelernte konsolidierte. Pairing funktionierte, weil zwei Menschen am Ort der Entscheidung synchron blieben.

Beliebige Arbeit versteckt Komplexität und überlässt sie jemand anderem. Einfache Arbeit legt die wesentliche Entscheidung offen und entfernt alles, was das Team daran hindert, sie erneut zu prüfen.

Dieser Unterschied zählt mit KI-gestützter Entwicklung noch mehr. Eine plausible Umsetzung zu erzeugen ist billig. Gemeinsames Vertrauen aufzubauen, dass sie die richtige Geschäftsregel ausdrückt, zum umgebenden System passt, die Produktion übersteht und veränderbar bleibt, ist es nicht. Schnellerer Output erhöht den Wert von Cunninghams alter Frage: Können die Menschen, die dieses System verantworten, es noch gemeinsam verstehen und verbessern?

Was Ward Cunningham uns noch lehrt

Cunninghams bleibende Lektion ist kein Werkzeug. Wikis können zu Friedhöfen werden. Karten können zu Workshop-Requisiten werden. Agile kann zu dem Prozesstheater werden, das es ersetzen wollte. Selbst technische Schulden können zu einem Euphemismus für Kapitulation werden.

Die Lektion ist ein Gestaltungstest für Zusammenarbeit:

• Können die Menschen, die die Arbeit machen, das gemeinsame Modell direkt verändern?
• Können sie eine Idee an einem konkreten Szenario prüfen, bevor sie teuer wird?
• Kann neues Wissen die Umsetzung ohne politische Kampagne verändern?
• Kann eine andere Person verstehen, warum die Entscheidung getroffen wurde?
• Kann das Team eine falsche Idee entfernen, ohne Löschen als Scheitern zu behandeln?

Wenn die Antwort nein ist, rettet keine weitere Plattform die Organisation. Der Engpass ist eine als Prozess verkleidete fehlende Erlaubnis, Distanz oder Angst.

Ward Cunningham machte diese Engpässe immer wieder kleiner. Eine Karte auf dem Tisch. Ein Bearbeiten-Link auf einer Seite. Eine Metapher, mit der zwei Gruppen über dieselbe Folge sprechen konnten. Zwei Entwickler an einer Maschine. Kleine Mechanismen, enorme Reichweite.

Er half Teams nicht nur, Wissen zu verwalten. Er zeigte, dass Verständnis wertvoll wird, wenn Menschen es gemeinsam verändern können.

Quellen

• Ward Cunninghams Aufsätze und Vorträge, Cunningham & Cunningham
• A Laboratory for Teaching Object-Oriented Thinking, Beck und Cunningham
• The WyCash Portfolio Management System, Ward Cunningham
• Profil von Ward Cunningham, Computer History Museum
• Ward Cunningham, Autoren des Agilen Manifests
• Inventors and Innovators: Ward Cunningham, Purdue University