Moin.

Im Allgemeinen finden wir Demokratie toll. In Unternehmen ist davon nicht viel zu merken. Vorgesetzte werden selten von den Mitarbeiterinnen und Mitarbeitern gewählt. Und abgewählt werden sie schon gar nicht. Und wie sieht es eigentlich im Hinblick auf Demokratie im Team aus?

Formal sind in den meisten Teams alle Mitglieder gleichberechtigt. Die Realität sieht meist anders aus: Es gibt Rollen, Zuständigkeiten und unterschiedliche Machtverhältnisse. Davon ist manches unausgesprochen und Teil der Teamkultur. Wenn daraus schlechte Entscheidungen entstehen, kann es sich lohnen, die Entscheidungshoheit im Team zu hinterfragen. Wie das geht, zeigt das folgende Beispiel.

Ich habe als Teamcoach mit einem Team in der Frontendentwicklung zusammengearbeitet. In der Kennenlernphase habe ich erste Gespräche mit allen Teammitgliedern geführt. Dabei habe ich auch gefragt, was gut und was schlecht läuft. Von den meisten Gesprächspartnern habe ich die Rückmeldung bekommen, dass sie das Framework für die Frontendentwicklung nicht mögen. Es ist proprietär und es gibt keine aktuelle Doku. Eine bessere Alternative sei beispielsweise Angular. In einem Gespräch ging es so weit, dass der Entwickler darüber nachdachte, zu kündigen. Seine Sorge war, dass er sein Können und damit seinen Marktwert verlieren würde, wenn er noch ein paar Jahre in diesem Umfeld arbeitete. Ich teilte seine Einschätzung.

Nun stellt sich natürlich die Frage, weshalb das Team mit diesem ungeliebten Framework arbeitete. Handelte es sich um eine Vorgabe des Unternehmens? Gab es technische Abhängigkeiten, die einen Wechsel unmöglich machten?

Selbstentwicklung als Ballast

Nein, nichts davon. Der Grund, der mir genannt wurde, lautet: Das eingesetzte Framework war die Selbstentwicklung eines Teammitglieds. Für den weiteren Verlauf nenne ich diese Person „Bob“. Mehrere Ansätze, Bob dazu zu bringen, ein anderes Framework zu verwenden, haben nichts gebracht; so wurde es mir zumindest erzählt.

Abgesehen von Bob waren alle Teammitglieder externe Entwickler. Ich hatte den Verdacht, dass es die Haltung „Der Kunde ist König“ gab und man glaubte, als Dienstleister kein Mitspracherecht zu haben. Um das zu hinterfragen, habe ich das Thema in einer Retrospektive in den Mittelpunkt gestellt: „Wie treffen wir in unserem Team Entscheidungen?“

Ich stelle die Frage nicht im luftleeren Raum, sondern bevorzugt anhand von aktuellen, relevanten Beispielen. Dazu frage ich das Team als Erstes: „Welche Entscheidungen, die in der Vergangenheit getroffen wurden oder regelmäßig getroffen werden, beeinflussen Euch und die Arbeit des Teams am meisten?“ Die Antworten teile ich in zwei Gruppen: Dinge, die außerhalb des Teams von anderen Personen und Dinge, die innerhalb des Teams entschieden werden. Nur über die zweite Gruppe lohnt es sich zu sprechen, wenn man konstruktive Ergebnisse erhalten möchte und nur das Team anwesend ist.

Typische Beispiele für Antworten sind: Welche Datenbank verwenden wir? Welches Repo verwenden wir? Wie sehen unsere Coding-Regeln aus? Welche Testabdeckung wollen wir erreichen? Wie sieht unser Branching-Workflow aus?

Ob das Team zu diesem Zeitpunkt auch die konfliktbehafteten Entscheidungen anspricht, lässt sich natürlich nicht vorhersagen. Im Fall meines oben genannten Teams kam das problematische Thema auf den Tisch: „Welches Frontend-Framework verwenden wir?“

Sobald die Themen bekannt und priorisiert sind, ordne ich sie in eine Tabelle ein, die wie folgt aussieht.

In der ersten Spalte stehen die Dinge, deren Entscheidungshoheit zu klären sind. Die weiteren Spalten stehen für verschiedene Entscheidungswege. Wird ein Thema nur von einer Person entschieden oder braucht es Einstimmigkeit im Team? Ist eine einfache oder eine absolute Mehrheit erforderlich? Oder genügt eine (einfache) Mehrheit, solange niemand ein Veto einlegt?

Im weiteren Verlauf geht das Team in zwei Schritten, Zeile für Zeile, durch. Der erste Schritt dient dazu, den Status quo zu ermitteln: „Wie entscheiden wir das Thema bisher?“ (Ist-Zustand) Zur Antwort markiert jedes Teammitglied die Spalte, die seiner Meinung nach den bisherigen Entscheidungsmodus darstellt.

In meinem obigen Beispiel sah die Tabelle nach diesem Schritt wie folgt aus.

Alle fünf Teammitglieder waren sich einig: Die Frage, welches Frontend-Framework zum Einsatz kommt, wurde und wird nur von einer Person entschieden (markiert durch die bleibenden Punkte). Der zweite Schritt ist der spannende: Wie wollen wir das Thema in Zukunft entscheiden? (Soll-Zustand)

Bei dieser Frage habe ich folgendes Ergebnis erhalten:

Zur Überraschung aller Beteiligten war sich das Team auch hier einig: Welches Framework zur Anwendung kommt, ist eine Teamentscheidung. Mehr noch: Ein Veto einer einzelnen Person würde eine Mehrheitsentscheidung blockieren.

Angesichts der bisherigen Erzählung war ich (und einige Entwickler) von verhärteten Fronten ausgegangen. Durch die einfache Übung, die auch unter dem Namen Team Decision Matrix bekannt ist, kam das Team ins Gespräch und es eröffnete sich die Möglichkeit, ein (neues) Framework auszuwählen, das das Team gemeinsam als zukunftstauglich einstufte.

Erst lesen, dann hören

Im Podcast Escape the Feature Factory greife ich ausgewählte Themen des Blogs auf und diskutiere sie mit einem Gast. Durch den Austausch lerne ich eine zweite Perspektive kennen. Wenn Du auch daran interessiert bist, findest Du den Podcast bei Spotify, Deezer, Amazon Music, und Apple Podcasts. Wenn Du die Themen, die ich im Blog anspreche, in Deiner Firma verbessern möchtest, komm’ in unsere Leadership-Community für Softwareentwicklung.

(rme)

Aktuelle KI-Agenten versprechen, in der Softwareentwicklung vollständig autonom zu agieren. Aber sind sie auch so weit, dass sie es hinsichtlich Know-how mit Entwicklerinnen und Entwicklern aufnehmen können?

Nein, sagt eine Studie „Challenges and Paths Towards AI for Software Engineering“, an der Forscherinnen und Forscher der Cornell University, des Computer Science and Artificial Intelligence Laboratory (CSAIL) des Massachusetts Institute of Technology, der Stanford University und der UC Berkeley beteiligt waren. Aktuelle LLM-Modelle haben noch nicht den Punkt erreicht, dass man mit ihnen so zusammenarbeiten kann wie mit einem Kollegen aus Fleisch und Blut.

Hoher Komplexitätsgrad als Stolperstein

Viele KI-Tools sind mittlerweile so leistungsstark geworden, dass sie Developern einen echten Mehrwert bringen. Komplexe Coding-Aufgaben können sich für Kollege KI jedoch laut der Studie als Stolperstein herausstellen. Darunter fallen etwa Aspekte wie das Kontextverständnis für sehr umfangreiche Codebasen, höhere logische Komplexitätsgrade sowie die Fähigkeit, Codestrukturen so zu planen und umzusetzen, dass ihre Qualität auch langfristig auf dem gleichen Niveau bleibt.

Ein Beispiel für eine komplexe Coding-Aufgabe ist die Behebung eines Speichersicherheitsfehlers. Effektives Bugfixing setzt voraus, dass Entwicklerinnen und Entwickler nicht nur die Fehlerstelle im Code ausfindig machen, sondern darüber hinaus auch dessen Semantik und Funktionsweise verstehen. Mitunter fallen auch unerwartete Zusatzarbeiten an. So könnte es ein Speicher-Bug zum Beispiel erforderlich machen, die ganze Speicherverwaltung zu ändern.

Betraut man ein KI-Tool mit derselben komplexen Aufgabe, könnte es ähnlich gute Arbeit leisten wie eine Entwicklerin oder ein Entwickler. Garantiert ist das allerdings nicht. Genauso gut könnte es auch passieren, dass die KI über den Fehler oder dessen Ursache halluziniert, irrelevante Verbesserungsvorschläge macht oder unverhältnismäßig große Codekorrekturen durchführen will.

Effektivere Mensch-KI-Kommunikation

Programmieraufgaben lassen sich über eine effektivere Kommunikation zwischen Mensch und Maschine am besten lösen. Bei der Softwareentwicklung gehe es darum, ein gemeinsames Vokabular und ein gemeinsames Verständnis für ein Problem zu finden. Das gelte auch für die Art und Weise, wie man es dann codeseitig lösen will.

Eine KI tut sich nach wie vor schwer damit, die Architektur eines Systems in allen seinen Facetten zu erfassen beziehungsweise zu reproduzieren. Das liege auch an den aktuellen KI-Schnittstellen, die im Gegensatz zu den Möglichkeiten, die Menschen haben, um miteinander zu kommunizieren, noch recht begrenzt sind.

Besseres Verständnis durch Nachfragen

Die Kommunikationsbarrieren zwischen Mensch und Maschine könnten sich laut Studie abbauen lassen, wenn KI-Systeme lernen, bei vagen Anweisungen oder unklaren Szenarien proaktiv um zusätzliche Informationen zu bitten. So ließe sich auch Code-Kontext verständlich machen, den Developer zwar im Kopf haben, der sich über herkömmliche KI-Agenten aber nur schwer vermitteln lässt.

Solche direkten Hinweise können bei KI-Systemen nicht nur Unsicherheiten vermeiden, sondern sie auch in die Lage versetzen, die Absichten von Entwicklerinnen und Entwicklern besser zu erfassen. Umgesetzt werden könnten sie durch fortschrittliche KI-Agenten wie zum Beispiel AlphaEvolve von Google DeepMind, das selbstständig Algorithmen entwirft und bewertet.

(who)

In dieser Episode spricht Richard Seidl mit Christian Brandes und Jonas Poller über Testen mit natürlicher Intelligenz. Zwei Fundstücke aus der Praxis geben den Ton an: ein Brutto-Netto-Flickflack, der Preise um einen Cent verschiebt, und ein Crash, der nur beim Einfügen am linken Feldrand auftritt. Daraus entfalten sie Fragen nach dem Verhältnis von Testing, Checking und Digging und nach der Kreativität von KI. Sie diskutieren, wie Teams Agilität, Qualitätskultur und persönliche Neugier verbinden, um bessere Produkte zu bauen.

Bei diesem Podcast dreht sich alles um Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste schauen sich Dinge an, die mehr Qualität in die Softwareentwicklung bringen.

Die aktuelle Ausgabe ist auch auf Richard Seidls Blog verfügbar: „Testen mit Natürlicher Intelligenz – Christian Brandes, Jonas Poller“ und steht auf YouTube bereit.

(mai)