Projektmanagement: Mehr Demokratie im Team wagen

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)