dot.research - Teamentwicklung mit dem dot.benchmark

Niklas Leicht
03. März 2022

Teamentwicklung mit dot.benchmark messen

Seit über einem Jahr begleiten wir unsere Kunden mit dem dot.benchmark. Das Erheben des aktuellen Standes ist der initiale erste Schritt, der bereits einige Erkenntnisse liefert, doch richtig spannend wird es dann, wenn es daran geht den Fortschritt nach einiger Zeit zu messen. In diesem Blog möchte ich zwei Beispiele vorstellen.

Ausgangslage - Wie ist die Situation?

Um unsere Arbeit und die Wirksamkeit des dot.benchmark zu illustrieren, möchte ich an dieser Stelle auf ein konkretes Beispiel aus unserem Beratungsalltag zurückgreifen. Es handelt sich dabei um ein reales Beispiel und alle Grafiken sind direkt und ungeschönt aus dem dot.benchmark entnommen.

Ein grosses Team mit mehr als 20 Teammitgliedern betreibt und entwickelt die grösste und wichtigste Kundenapplikation des Unternehmens. Das Team arbeitet nach Scrum.

Das Team ist in einer Projektorganisation eingebettet und setzt Anforderungen von diversen Stakeholdern um. Da es kein klassischen Produkt-Team ist, müssen Anforderungen, die von den Stakeholder in Auftrag gegeben (und gezahlt werden), zwingend umgesetzt werden. Das Team selbst hat daher nur sehr wenig Einfluss auf die Priorisierung. Der Scrum-Prozess ist entsprechend schwierig umzusetzen, da Sprints kaum planbar sind und immer wieder viele Stories unfertig in die nächste Iteration verschoben werden müssen. Zeremonien wie das Daily werden durch die Teasmgrösse extrem behäbig und bringen nur wenig Mehrwert.

Dies zeigt auch die initiale Bestandsaufnahme durch den dot.benchmark, bei der mehr als 20 Personen ihre Einschätzung abgegeben haben:

Die Schwächen werden durch den dot.benchmark schnell aufgedeckt. Der Produktfokus ist niedrig und auch bei den agilen Methoden ist sich das Team einig, dass diese nicht zum Kontext des Teams passen. Gleichzeitig sehen wir, dass das Team auch in unserem dot.benchmark in allen Dimensionen (graue Linie: 100% = Durchschnittswert aller anderen Teams) unterdurchschnittlich abschneidet.

high-altitude-mountain-tour-g129b05047_1920

Prozess - Was haben wir gemacht?

Potentiale identifizieren

Mit dieser Ausgangslage erhielten wir die Möglichkeit das Team zu begleiten und gezielt zu entwickeln. In einem ersten Workshop wurden die Ergebnisse des dot.benchmark analysiert und mit Hilfe eines Causal-Loop-Diagramms die Ursachen herausgearbeitet. Das Ergebnis: Das Team hat wenig Selbstbestimmung und ist enorm abhängig von äusseren, nicht beeinflussbaren Faktoren (sowohl technisch als auch fachlich) und der Scrum-Prozess ist nur "übergestülpt" und sorgt für Probleme und durch unklare Prozesse auch zu zwischenmenschlichen Spannung, obwohl das Team im Allgemeinen gut und gern miteinander zusammenarbeitet. In einem nächsten Workshop wurden dann gemeinsam Massnahmen erarbeitet, welche dabei helfen sollen, die erkannten Probleme zu adressieren.

Die Massnahmen zielten vor allem darauf ab, Dinge zu ändern, die das Team selbst beeinflussen kann. Auf Grund der Gegebenheiten wurde schnell klar, dass man am Produktfokus nur wenig ändern kann und somit wurde der Fokus auf den Zusammenarbeitsprozess gelegt. Daher war die grösste und wichtigste Massnahme auch den vorhandenen Scrum-Prozess kritisch zu hinterfragen und Alternativen zu diesem zu entwickeln, welche besser zu den Gegebenheiten des Teams (grosses Team, wenig Selbstbestimmung beim Backlogmanagement und der Priorisierung) passen.

Potentiale aktivieren

Schnell wurde klar, dass es ein Vorgehensmodell braucht, welches sich vor allem daran orientiert die anstehende Arbeit transparent zu machen und möglichst zügig anfallende Arbeiten abzuschliessen. Das Team entschied sich nach einer Gegenüberstellung möglicher Vorgehen für ein Experiment, in welchem Kanban eingeführt werden sollte.

Experiment heisst bei uns nicht das allgemein gültige "rumtüfteln" oder ausprobieren, sondern mehr die Definition im wissenschaftlichen Sinne. Wir wollten alle Rahmenparameter konstant halten, um zu prüfen, ob und welche Veränderungen sich durch diese getätigte Aktion ergeben. Zu einem Experiment gehören darüber hinaus auch klare Ziele, Verantwortlichkeiten und Hypothesen, also Annahmen, auf die sich das Experiment stützt und welche es zu verifizieren gilt. Selbstverständlich hat ein Experiment auch eine begrenzte Dauer, in welcher wir die Änderungen prüfen möchten. Dies alles bilden wir mit einem Canvas ab, bei dem diese und noch mehr Parameter festgehalten werden.

Canvas Experimente_A01024_1-jpg

Welche Rolle haben wir dabei gespielt?

Unser Ziel ist es, Teams zu befähigen ihr volles Potential abzurufen. Das gelingt uns am besten, wenn wir als externe Coaches dabei sind und das Team unterstützen die definierten Ziele zu erreichen. Extern meint dabei, dass wir kein Teil des Teams sind oder werden, denn dann verlieren wir a) unsere Objektivität und haben b) auch andere Interessen und Ziele, die wir verfolgen. Weiterhin liefern wir dem Team keine vordefinierten Lösungen, die wir dann auch noch selbst umsetzen. Was das heisst?

Im konkreten Fall haben wir mit einem Kernteam in insgesamt acht Schritten das Kanban-System von Grund auf designed und definiert. Dabei war unsere Rolle klar als Prozess-Moderator und Coach definiert. Wir haben die Kanban-Expertise vermittelt und den Lösungsraum aufgezeigt. Alle weiteren Entscheidungen werden letztlich vom Team selbst getroffen. Wir haben nur interveniert, wenn bspw. Lösungsideen aus dem Team gegen Kanban und die dahinterliegenden Prinzipien verstösst.

Ergebnis - Wie sieht es jetzt aus?

So eine grosse Veränderung in der täglichen Arbeit braucht natürlich eine gewisse Zeit, bis sich etwaige Veränderungen bemerkbar machen und sichtbar werden. Nach ca. neun Monaten in denen der Kanban-Prozess eingeführt und kontinuierlich verbessert und auf die Bedürfnisse des Teams angepasst wurde, kam die Stunde der Wahrheit: Hat sich etwas für die Teammitglieder verändert und wie schätzen sie das Team jetzt ein?

Das Ergebnis hat sogar uns erstaunt. Das Team hat sich nach eigenen Angaben(!) in allen Bereichen erheblich verbessert. Am signifikantesten ist der Unterschied bei den agilen Methoden ausgefallen - genau dort wo unser Experiment angesetzt hat. Spannend zu beobachten ist an dieser Stelle aber, dass es aber nicht nur dort, sonder vor allem auch im Bereich der Teamdynamik- und des Teamumfeldes zu deutlich besseren Einschätzungen kommt? Aber wieso ist das so?

Unsere Hypothese: Zusammenarbeit wird nicht über "Kultur-Workshops" oder das Aufstellen von "Team-Regeln" erreicht, sondern durch eine Verbesserung der Verhältnisse, in welchem das Team arbeitet!

Wir wissen, dass diese Aussage vermutlich einige Organisationsberater*innen und "Culture-Coaches" empört und wir möchten solchen Massnahmen auch nicht ihre Existenzberechtigung absprechen, aber wenn das Ziel ist, dass Menschen besser und effizienter miteinander arbeiten, dann ist "darüber reden" nicht immer die beste Wahl. Ich muss es dem Team einfacher machen gut zusammen zu arbeiten. Wenn ich es schaffe, einen klaren Zusammenarbeit-Prozess zu implementieren, in welchem die Grundprinzipien der Agilität (Transparenz, Inspektion, Adaption) gelebt und entsprechen prozessual gefördert werden, reduziere ich automatisch einige potentielle Konfliktherde im Team. Oftmals führen nämlich ineffiziente oder unklare Prozesse zu Reibung und damit Konflikten. Zudem merken die Teammitglieder selbst, dass ihr Output nicht zufriedenstellend ist, was natürlich ebenfalls für Konflikte sorgen kann.

Mehr zum Denkmodell Haltung-Verhalten-Verhältnisse findest du hier.

dot_blog_content_kunden

Fazit

Es funktioniert! Seit mehr als einem Jahr begleiten wir Teams mit dem dot.benchmark - mal mit mehr, mal mit weniger Begleitung unsererseits. Neben der ständig wachsenden Datenbank an Teams, sind einige Teams schon so lange dabei, dass wir auch Daten über die Zeit erheben und auch wenn das jetzt nach viel Marketing-Sprech klingt: Die Ergebnisse sprechen für sich. Die Vergleichscharts sehen in der Regel immer gleich aus, wenn wir den dot.benchmark einsetzen und anschliessend das Team befähigen dürfen die identifizierten Herausforderungen mit geeigneten Massnahmen anzugehen.

Damit eignet sich der dot.benchmark nicht nur ausgezeichnet für uns als Tool in unserer täglichen Arbeit, sondern auch als ideales Instrument für Servant Leader, Agile Coaches, Release Train Engineers oder Scrum Master, die ihre Teams evidenzbasierten und effizient auf die nächste Stufe heben möchten.

Möchtest du den dot.benchmark für dein Team ausprobieren? Kein Problem! Wir bieten mit dem dot.benchmark Preview eine leichtgewichtige und kostenfreie Lösung zum Kennenlernen an!

dot benchmark

dot.benchmark Preview

Jetzt den dot.benchmark online kostenlos für einen Monat testen.

dot.benchmark Preview anmelden

Keine Kommentare bis jetzt

Lass uns wissen, was du darüber denkst.

Vielleicht gefallen dir auch

diese Artikel Agile Coaching

Newsletter Anmeldung