Conways dunkler Spiegel

Conway’s Law sollte allen von uns ein Begriff sein. Zur Auffrischung:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

Ursprünglich eine soziologische Beobachtung über die Arbeit von Komitees als die Softwareentwicklung noch in den Kinderschuhen steckte – 1967 – wird es bei uns inzwischen anders zitiert …

Conway’s Law im Mayflower-Umfeld

Die Qualität der Software in einem Unternehmen hat die Qualität der Kommunikation in selbigem als Obergrenze.

Es ist einfach zu sehen, warum: Politische Grabenkämpfe, harte Kurswechsel, Personalwechsel ohne saubere Übergaben. Jedes Unternehmen hat Narben und diese Narben sind im Code sichtbar.

Vereinzelt gibt es Firmenkulturen die so toxisch sind, dass produktive Arbeit häufig nur zufällig passiert – als harter Einsatz von Individuen gegen die Widerstände in der eigenen Firma. Gerade als Programmierer kann man hier leicht in eine Opferhaltung geraten, kann man doch nur sehr indirekt Einfluss auf die Kultur eines Kunden nehmen. Aber …

Dies ist kein pessimistischer Artikel!

Zunächst: Legacy-Code ist Code, der Geld verdient; nur so konnte er so lange überleben, um Legacy zu werden. Ganz gleich wie furchtbar er aussieht, in ihm steckt Wert, den ein erfahrener Entwickler hervorbringen kann. Dasselbe gilt auch für Unternehmen.

Ein Blick in den Spiegel

Niemand will in einem toxischen Umfeld arbeiten. Der erste Schritt etwas daran zu ändern, ist Einsicht.

Der Schritt von Unconscious Incompetence zu Conscious Incompetence kann genau die Qualität der Codebasis sein (und was sie über das Unternehmen aussagt): Sind wir schnell gewachsen? Mussten wir harte Kompromisse machen? Haben wir es noch nicht geschafft, als Team zusammenzufinden? In welche Richtung gehen wir eigentlich?

Softwareentwicklung als Raketenstart

Softwareentwicklung bringt viele Werkzeuge mit, die erstaunliche positive Seiteneffekte in diesem Bereich haben.

Product Owner

Es fängt mit einem guten Product Owner an. In Unternehmen, in denen Einfluss aus mehreren Richtungen auf das Entwicklungsteam genommen wird, um bestimmte Themen voranzubringen, kann alleine schon diese zentrale Anlaufstelle eine massive, positive Veränderung sein.

Ein guter Teil der agilen Softwareentwicklung ist vor allem auch das sichtbar machen von Wissensarbeit. Jeder kann sehen, woran gerade gearbeitet wird; jeder kann zum Product Owner kommen wenn der Backlog ‚falsch‘ priorisiert ist. Tickets bewegen sich von links nach rechts auf den Board, was Vertrauen schafft. Doch mehr dazu gleich.

Event Storming

Wer noch nie bei einem Event Storming dabei war, kann sich nicht vorstellen, wie viele Einblicke ein solcher Workshop liefern kann. Es werden explizit technische und nicht-technische Mitarbeiter für mehrere Stunden in einen Raum gesteckt, so dass sie ein vollständiges Bild davon bauen können, was die Software ist, was sie abfangen und können soll, wie sie mit dem Unternehmen interagiert und wo sie hin soll. Ein besseres Werkzeug dafür, Fachsilos aufzulösen, gibt es nicht.

Domain-Driven Design

Domain-Driven Design … für viele eine neue Idee, obgleich das Buch dazu 2004 herauskam. Vereinfacht heißt es, dass die Sprache zwischen Fach und Technik vereinheitlicht wird. Anstelle von AbstractAccountCustomerFactories reden Entwickler plötzlich von Rechnungen, mit Posten und einem Empfänger. Eine Rechnung kann z. B. bezahlt oder storniert werden.

Hier finden die Softwareentwickler ihre Wirksamkeit. Kommunikationshürden werden aus dem Weg geräumt. Entwickler und Facharbeiter können sich sehr konkret und spezifisch austauschen, wie die Software funktionieren soll.

Betriebsblindheit

Ein Aufprallen verschiedener Arbeitskulturen … Betriebsblindheit ist ein weit verbreitetes Phänomen. Die Dinge sind so, wie sie sind – weil sie schon immer so waren. Oftmals kann das Aufprallen eines externen agilen Teams sehr viele Kontraste aufzeigen.

„Aha, es geht also auch anders!“ Ich spreche hier in sehr allgemeinen Zügen, weil es oftmals um eine Schubkarre voller kleiner Details geht. Und bei jedem Unternehmen um andere! Mit den Worten von Tolstoy: „Alle glücklichen Familien gleichen einander, jede unglückliche Familie ist auf ihre eigene Weise unglücklich.„

Die geheime Zutat ist Vertrauen

Wenn die Umgebung gegen die Softwareentwicklung arbeitet, hat das – meiner Erfahrung nach – meistens Misstrauen als Ursache. Die Leute wollen wissen, dass es vorangeht, also gibt es Statusmeetings und -reports. Die Entwickler sollen arbeiten, also sollen Tickets in Realzeit geschätzt und Stunden auf sie gebucht werden. Umgekehrt jedoch möchte niemand für irgendetwas verantwortlich sein. Wer die Verantwortung für etwas hat das fehlschlägt, wird schließlich bestraft.

Vertrauen muss erarbeitet werden. Es fällt nicht vom Himmel. Auf der anderen Seite beginnt jedes Vertrauensverhältnis mit einem Wagnis. Jeder neue Mitarbeiter ist ein Risiko. Jede neue Aufgabe ist ein Risiko. Meine Empfehlung ist, bei diesen Risiken sparsam mit Mitigations-Strategien zu sein, um das Vertrauensverhältnis nicht im Keim zu ersticken. Letzten Endes funktioniert agile Softwareentwicklung nur mit einem hohen Maß an Eigenverantwortlichkeit.

Die andere Geheimzutat ist psychologische Sicherheit

Google hat eine firmeninterne Studie gemacht, um herauszufinden, welche Eigenschaften ihre produktivsten Teams haben. Interessanterweise hing es weniger von der Fachkompetenz der Teammitglieder ab, sondern hauptsächlich von „psychologischer Sicherheit“. Kann ich laut etwas falsches sagen, ohne Status zu verlieren? Kann ich Unwissenheit zugeben und Fragen stellen, ohne dass ich meinen Job gefährde?

Es klingt banal, es kostet wenig, aber für die Teamkultur macht es einen Unterschied von Tag und Nacht. 

Achtung, YouTube!

Datenschutz ist uns wichtig! Daher müssen wir noch kurz etwas los werden … Um das Video direkt auf dieser Seite angezeigt zu bekommen, musst Du leider folgende Cookies akzeptieren: statistik, Marketing.

Man muss es wollen

Es ist schwer in den Spiegel zu schauen und anzuerkennen, was man sieht. Vor allem in Großkonzernen kaskadiert Misstrauen gerne nach oben. Und Code ist so schön unsichtbar! Alles was man sieht ist eine hübsche, grafische Oberfläche und ja, die Applikation ist gerade etwas langsam, aber wir arbeiten mit Hochdruck daran!

Es ist leicht, sich die Realität schön zu reden, es ist schwierig, sich aus dieser Situation zu entkoppeln und das zu tun, was nachhaltig zum Erfolg führt. Aber: Vertrauensverhältnisse kaskadieren ebenfalls und Erfolge sprechen für sich. Je mehr man liefert, desto mehr Freiheit von Misstrauen kann man sich erkaufen.

Positive Veränderungen passieren immer in kleinen Inkrementen. Wenn man Alignment in eine klare Richtung hat, mit vielen schaffbaren Zwischenschritten – ich verweise hier geschickt auf Objetive and Key Results, die nicht nur bei Google, sondern auch bei Mayflower gute Ergebnisse erzielt haben (passende Trainings von Mayflower) – kann zu nachhaltigen, guten Ergebnissen führen. auch kurzfristig.

Kein Allheilmittel

Ein sauber aufgezogenes Softwareprojekt ist sicher nicht das Allheilmittel, kann aber ein sehr wirksamer Neubeginn sein (Daher auch unser Firmenname, Mayflower: Auf zu neuen Ufern!). Wir könnten unserer Firmenvision

Wir führen Unternehmen in die Zukunft, mit moderner Technologie und agiler Organisation

allerdings nicht gerecht werden, wenn wir glaubten, dass derartige Veränderungen nicht nötig, positiv und realistisch sind.