Team Alignment mit OKR

Team Alignment bezeichnet die gemeinsame Ausrichtung aller Teammitglieder auf geteilte Ziele, damit lokale Entscheidungen ohne ständige Rückfragen bei Führungskräften getroffen werden können. Konkrete Metriken, etwa die Anzahl durchgebrochener Defekte oder Kundenfeedback-Kennzahlen, machen Fortschritt sichtbar. Drei bis fünf solcher Metriken gelten als sinnvolle Orientierung.

Das Wichtigste in Kürze

• Alignment bedeutet, sich über gemeinsame Ziele und deren Priorität zu einigen, damit Teams kleine Entscheidungen lokal und ohne Rückfrage nach oben treffen können.
• Drei bis fünf Metriken pro Ziel sind eine sinnvolle Größenordnung, wobei neben zielführenden Metriken immer auch Gesundheitsmetriken das Bild balancieren müssen, damit niemand blind auf eine einzige Kennzahl hin optimiert.
• Metriken dürfen nicht zum Selbstzweck werden: Wer nur noch eine Zahl erreichen will, verliert das eigentliche Ziel aus den Augen, nämlich zufriedene Kunden mit fehlerarmen Produkten.
• Ziele verlieren im Alltag ihre Wirkung, wenn niemand sie aktiv hochhält; das kann jede Person im Team tun, nicht nur die Führungskraft, zum Beispiel im informellen Gespräch.

Was bedeutet Alignment in der Softwareentwicklung?

Alignment heißt Abstimmung über das, was wirklich wichtig ist. In vielen Unternehmen zieht eine Ecke nach links, die andere nach rechts, besonders auf der mittleren Führungsebene, wo auch Karrieredenken hineinspielt. Alignment richtet die Kräfte auf gemeinsame Ziele aus.

Urs Reupke trennt Alignment sauber von Fokus. Alignment liegt vor, wenn sich alle über die Herausforderung einig sind: dass sie wichtig ist, dass sie angegangen werden muss und auf welche Weise. Fokus folgt danach, wenn sich das Team auf eine konkrete Lösung konzentriert und sie durchzieht.

Der eigentliche Hebel liegt im Verhältnis von oben und unten. Wenn die großen Ziele geklärt sind, können die kleinen Entscheidungen lokal getroffen werden. Ein Tester muss dann nicht bei jeder Frage zum Projektleiter laufen: ob sich ein Fehler näher anschauen lohnt, ob noch Budget da ist. Die Antwort ergibt sich aus dem Ziel.

Warum spätes Kundenfeedback ein Qualitätsproblem ist

Kundenzufriedenheit lässt sich oft erst lange nach der Veröffentlichung messen, und das ist zu spät. Das Produkt ist gebaut, ausgeliefert, dann schreibt jemand auf Reddit oder Facebook, das Ding sei nicht der große Wurf. In diesem Moment hilft kein Wunsch mehr, früher in Qualitätssicherung investiert zu haben.

Der Ausweg liegt in untergeordneten Zielen und Metriken, die ein Ergebnis früher anzeigen. Wer Kundenzufriedenheit steigern will, braucht Signale während der Entwicklung, nicht erst danach. Sonst ist der Börsenkurs schon im Keller, wenn die Rückmeldung kommt.

Ein konkretes Beispiel aus der Testarbeit: weniger Defekte, die innerhalb eines Sprints oder eines Monats aus der Entwicklung bei der Testgruppe ankommen. Das ist eine untergeordnete Metrik, die früher steuert. Aus ihr folgt eine andere Haltung im Testen.

Wie kann ich als Software-Tester mit den Entwicklern so zusammenarbeiten, dass sie es gleich richtig bauen? Qualität rein testen, statt hinterher Fehler raus testen. — Urs Reupke

Das ist im Kern die Frage, die agile Tester seit Jahren beschäftigt. Neu ist hier, dass sie mit Metriken unterlegt wird.

Welche Metriken eignen sich für zielgetriebenes Arbeiten?

Brauchbar ist fast alles, was in einem Buch der Produktmetriken steht, ergänzt um Geschäftskennzahlen. Urs nennt Pirate Metrics mit Stationen wie Acquisition und Retention, dazu klassische Qualitätsmetriken: Anzahl gefundener Defekte, Anzahl durchgebrochener Defekte, Anzahl von außen gemeldeter Defekte, aufgeschlüsselt nach Kritikalität oder Priorität. Auch Umsatz oder gewonnene Abonnenten gehören dazu.

Wichtiger als die Auswahl ist die Reihenfolge im Kopf. Du legst zuerst fest, welches Ziel du erreichen willst. Dann bestimmst du die Metriken, an denen du erkennst, dass du es erreicht hast. Und diese Metriken sollten möglichst schon während der Entwicklung sichtbar werden, damit sie dein Handeln leiten.

Drei bis fünf Metriken sind eine gute Handvoll. Mehr macht das Bild unscharf.

Zielmetriken brauchen Gegengewichte

Eine reine Optimierung auf ein einziges Ziel führt in die Irre. Das Bild dafür ist eine Fahrt nach Paris. Die Kilometer bis zum Ziel sind eine Metrik. Genauso relevant ist, wie viel Sprit noch im Tank ist und wie wach der Fahrer ist. Wer nur geradeaus schaut, bleibt irgendwann auf der Strecke stehen.

Diese zweite Sorte nennt Urs Gesundheitsmetriken. Sie gelten unabhängig vom konkreten Ziel und bleiben über Ziele hinweg bestehen. Sie balancieren, damit ein Team nicht alles dem einen Ziel opfert.

Das absurde Extrem macht es klar: Wäre das oberste Ziel, keine Defekte mehr in Produktion zu lassen, wäre die einfachste Lösung, die Produktion einzustellen. Es muss immer ein Gegengewicht geben.

Wie ihr Ziele im Alltag nicht aus den Augen verliert

Der größte Feind eines gesetzten Ziels ist der Alltag. Das kennt jeder vom Vorsatz, ab dem 2. Januar ins Fitnessstudio zu gehen. Drei Wochen hält das, dann wird der Hund krank, dann das Kind, dann man selbst, und Ende März fragt man sich, warum man den ganzen Monat nicht da war.

Die Gegenmaßnahme ist Führung, und Führung kann jeder ausüben. Viel davon passiert in der Kaffeeküche. Ein Satz reicht oft: Wir hatten uns auf dieses Ziel geeinigt, ich sehe dich gerade etwas anderes tun, haben wir das gemeinsame Ziel noch? Das Ziel hochhalten und sich trauen, es anzusprechen, wenn es aus dem Blick gerät.

Wer sich mit Gewohnheiten beschäftigt hat, kennt die Regel: lass eine Gewohnheit nicht mehr als einmal durchrutschen. Beim zweiten Mal wird das Durchrutschen selbst zur Gewohnheit.

So baust du die Erhebung schlank

Einmal pro Woche die Zahlen zusammentragen reicht meist. Macht man es öfter, entsteht viel Formalismus, alle starren auf Tabellenblätter und nichts bewegt sich. Ein verlängertes Daily kann der Rahmen sein.

In diesem Termin trennst du zwei Dinge: die Metriken, die auf das Ziel zeigen, und die, die anzeigen, ob ihr ansonsten auf dem richtigen Weg seid. Daten eintragen, mit der Vorwoche vergleichen, weiter. Der Aufwand muss klein bleiben, sonst stellt man sich selbst ein Bein.

Wenn die Zahlen sich nicht bessern, hilft Innehalten statt Aktionismus. Wo seid ihr falsch abgebogen, und wo ist die nächste Ausfahrt zurück auf den Weg? Im Team-Kontext sind Ziele meist durchdacht genug, dass man sie selten wirft. Häufiger gilt: das Ziel war richtig, ihr müsst es nur wieder ins Auge fassen.

Das Burn-Down-Chart zeigt das Muster im Kleinen. Lange bleibt die Linie flach, am letzten Tag fällt alles. Mit etwas Erfahrung weiß ein Team, dass es am Ende meist reicht, und kann trotzdem daran arbeiten, dass die Linie eher gleichmäßig nach unten läuft.

Die Metrik darf nie das Ziel ablösen

Am Ende zählt der zufriedene Kunde, nicht die erfüllte Kennzahl. Es bringt nichts, sich zu freuen, dass eine Zahl unter fünf liegt. Ziel ist ein gutes, möglichst fehlerfreies Produkt mit Features, die Nutzer wollen.

Sobald eine Metrik zum Selbstzweck wird, löst sie das Ziel ab. Genau das ist nicht der Sinn. Schon bei der Auswahl der Metriken solltest du darauf achten, dass jede einen Bezug zum Nutzen für den Kunden behält.

Wie ein Team in Eigeninitiative startet

Der erste Rat ist schlicht: einfach machen. Auf Team-Ebene geht selten viel schief, wenn in Sprints oder anderen Iterationen gearbeitet wird. Nach zwei Wochen sitzt man wieder zusammen und sieht, ob der Pfad stimmt. Im schlimmsten Fall sind zwei, drei Stunden investiert, die nichts gebracht haben.

Zwei Dinge erhöhen die Trefferquote. Erstens jemand, der den Prozess moderiert, damit aus unterschiedlichen Vorstellungen ein gemeinsames Ziel wird. Im Idealfall ist das nicht die Führungskraft selbst, weil sonst sofort Statusfragen mitlaufen, sondern ein neutraler Begleiter, gerade bei den ersten Durchläufen. Zweitens das Rad nicht neu erfinden. Es gibt genug Bücher und Übersichten dazu, welche Metriken andere nutzen. Im OKR-Umfeld legt GitLab seine OKRs offen, ein guter Anschauungspunkt dafür, wie so etwas dokumentiert aussieht.

Wenn es funktioniert, mach Werbung dafür. Nichts legitimiert so sehr wie Erfolg. Klappt es nicht, lernen andere daraus, was nicht funktioniert hat. Beides ist Inspect and Adapt: innehalten, neu orientieren, im Kleinen wie im Großen.

Wer gehört ins Team, das die Ziele setzt?

Am liebsten die ganze Produktebene, realistisch der engere Team-Kontext. Wenn ein Programm 100 Personen umfasst, ist das kein Beschluss vom Dienstagabend für den Donnerstag. Für ein Team aber lässt sich die Runde gut zusammentrommeln.

Niemand wird wegen seines Titels oder seiner Spezialisierung ausgegrenzt. Ins Boot gehören die Tester, die Entwickler, Business-Intelligence- und UX-Leute, dazu jemand, der die Stakeholder im Blick hat, und der Product Owner, Service Owner oder Scrum Master, falls vorhanden. Schnell sind das zehn bis fünfzehn Leute, ein noch überschaubarer Kreis. Eine kleinere Gruppe kann eine Entscheidungsvorlage bauen, die größere Runde entscheidet gemeinsam.

Widerspruch gehört dazu und muss ausgehalten werden. Hier hilft eine Unterscheidung: Schadet das Ziel, oder findet ein Einzelner nur ein anderes besser? Im zweiten Fall lässt sich überzeugen oder überstimmen. Und selbst wenn jemand das Ziel für Quatsch hält, ist es oft gut genug, um sich für vier Wochen darauf einzulassen und es auszuprobieren.

Bekannte Ziele der Führungskraft erleichtern lokale Entscheidungen

Die Führungskraft muss bei der Zielsetzung nicht im Raum sitzen, aber ihre übergeordneten Ziele zu kennen, hilft enorm. Wer die Jahresziele oder strategischen Absprachen kennt, kann sie bei eigenen Entscheidungen mitdenken.

Daraus wird eine einfache Leitfrage für den Alltag: Was würde unsere Führungskraft hier entscheiden, und wie handle ich in ihrem Sinn? So lässt sich ein Konflikt von vornherein entschärfen, allein durch das Wissen, das man vorher eingeholt hat.