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)

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)

Tim Klein spricht in dieser Podcastfolge mit Marc Roulet von sevdesk darüber, warum bessere Metriken und Key Performance Indicators (KPIs) den Unterschied machen, wenn es um gute Produktentscheidungen geht. Beide erleben in ihrer Arbeit immer wieder, dass Organisationen Zahlen erheben, die zwar schnell verfügbar sind, aber wenig darüber aussagen, ob ein Produkt wirklich Nutzen stiftet. Marc Roulet ist ein erfahrener Experte im Bereich Analytics und Metriken und bei sevdesk verantwortlich für Data und Analytics. Er hat in ähnlichen Rollen unter anderem auch schon bei eBay, mobile.de und Xing Erfahrungen gesammelt.

Klarheit und Orientierung durch sinnvolle Metriken

Viele Teams orientieren sich an einfachen Kennzahlen wie Story Points oder der Anzahl ausgelieferter Features. Das zeigt den „Fleiß“, im Sinne von Output, sagt aber kaum etwas über die Wirkung aus. Bessere Metriken schauen auf Outcomes und helfen zu erkennen, ob Kundinnen und Kunden tatsächlich profitieren. Wer das ernst nimmt, stellt fest, dass nicht jede neue Funktion Wert für die Nutzer schafft – und dass auch das Weglassen eine wichtige Entscheidung sein kann.

Metriken sind kein starres System, das man einmal definiert und dann abarbeitet. Sie entfalten ihren Wert erst, wenn Teams regelmäßig hinschauen, sie diskutieren und gegebenenfalls anpassen – also aktiv mit ihnen arbeiten. So entsteht ein gemeinsames Verständnis, worauf es wirklich ankommt. Oft geht es darum, Hypothesen zu prüfen: Führt eine bestimmte Änderung tatsächlich zu mehr Nutzung? Verbessert sie ein relevantes Kundenerlebnis? Oder verpufft der Effekt?

Gerade für Product Owner liegt hier eine Chance. Sie sind nah an den Entscheidungen und können dafür sorgen, dass Gespräche über bessere Metriken nicht an der Oberfläche bleiben. Es geht nicht darum, Zahlen zu liefern, die gut aussehen, sondern um eine Grundlage, die schwierige Fragen und Entscheidungen ermöglicht. Was bedeutet Erfolg für unser Produkt? Wie messen wir Fortschritt, der über Auslastung und Geschwindigkeit hinausgeht und in Richtung unserer Produktvision führt?

Wer sich auf diesen Weg einlässt, wird merken, dass bessere Metriken Orientierung geben. Sie bringen Klarheit in Diskussionen mit Stakeholdern, machen Annahmen transparent und helfen Teams, bewusster zu entscheiden. So wird die Produktentwicklung weniger zu einer Abfolge von Aktivitäten und mehr zu einem Prozess von Wertgenerierung, der echten Unterschied macht.

Wer mit Marc Roulet direkt in Kontakt treten und weitere Fragen klären möchte, kontaktiert ihn am besten über sein LinkedIn-Profil.

Weiterführende Links

Die aktuelle Ausgabe des Podcasts steht auch im Blog der Produktwerker bereit: „Die Produktwerker: Bessere Metriken & KPIs für richtige Entscheidungen und mehr Wirkung„.

(mai)