OKR – Mini How-To

Wie funktionieren OKR? Aus den Google-Handreichungen und anderen Quellen destilliert:

  • „Objectives“ beschreiben das „Was“:
    • Drücken Ziele und Absichten aus
    • Sind aggressiv aber realistisch
    • Sind greifbar objektiv und eindeutig – es sollte durch einen rationalen Beobachter erkennbar sein, ob das „Objective“ erreicht wurde.
    • Es muss einen erkennbaren Wert für die Systel haben.
  • „Key Results“ beschreiben das „Wie“:
    • Drücken messbare Meilensteine aus, ihre Erreichung tragen zum Fortschritt der Bestandteile eines Objectives sinnvoll bei.
    • Beschreiben Ergebnisse, keine Aktivitäten.
    • Enthalten Belege für deren Erreichung
    • Sind die KR alle erreicht, so ist das Objective erreicht
  • Es gibt 2 Arten von OKRs: Verpflichtete (Commited) und Ehrgeizige (Aspirational). Verpflichtete OKRs müssen zu 100% erreicht werden, bei ehrgeizigen ist eine Erfüllung von etwa 70% zu erwarten.
  • Klassische Fallen und Fehler im Schreiben von OKRs:
    • Verpflichtende und ehrgeizige OKRs werden nicht unterschieden
    • Business-as-Usual OKRs
    • Schüchterne ehrgeizige OKRs
    • Sandbagging
    • Who-cares-Objectives / Objectives mit niedrigem Wert
    • Unzureichende Key-Results

Product Owner = On-Site Customer?

Bei einem IT-Dienstleister, der Softwareprojekte für Kunden durchführt, höre ich immerwieder den Satz im Rahmen von Scrum-Projekten: „Der ProductOwner muss vom Kunden kommen.“ Auch wenn dies teilweise richtg sein mag, so verwehre ich mich gegen die starke Pauschalität dieser Aussage.

Der ProductOwner ist dafür verantwortlich, was gebaut wird. Er bestimmt die Fachlichkeit der Anwendung und priorisiert, welche Anforderungen wichtig sein. Er hilft bei Klärung fachlicher Fragen. Vieles davon ist sicherlich bei einem PO, der vom Kunden der Software kommt, gut aufgehoben. Insbesondere die fachlichen Fragen sind oft so speziell, dass ein PO von Kundenseite hier eindeutig Vorteile bietet.

Aber es gibt auch Gegenbeispiele; Microsoft Word beispielsweise, hier wäre ein PO, der von einem bestimmten Verlag kommt, eine PO, die Autorin eines Buches wäre, ein PO aus einem Sekretariat oder eine PO aus einem Übersetzungsbüro keine gute Idee. Denn dann würde die Software vielleicht genau für diese Person oder eventuell sogar für diesen Anwendungsfall geeignet sein, das Produkt würde aber sicherlich nicht in allen diesen Bereichen eingesetzt werden. Hier sind die Nutzer „nur“ Stakeholder der Software, ein ProductOwner muss die Interessen der Nutzer gegeneinander abwägen und teilweise auch hinten anstellen.

Meiner Meinung nach sollte es nicht unbedingt der Default sein, dass „der PO von Kundenseite kommen muss“. Scrum nennt auch explizit diese Rolle ProductOwner, nicht „On-Site Customer“, wie er in eXtreme Programming existiert!

Um erfolgreich zu sein, so der Scrum Guide, müssen die Entscheidungen des PO in der Organisation respektiert werden. Hier kann auch ein Knackpunkt liegen, wenn der PO von Kundenseite kommt. Denn eine kundenseitige PO ist beispielsweise Governance-Vorgaben nicht unterworfen, die für einen Betrieb der Software nötig sein können.

Keine Lösung ist es zumindest, einen „internen PO“ und einen „externen PO“ nebeineinander zu stellen!