OKR & Scrum: Die richtige Priorisierung der IT-Ressourcen durch OKRs und Scrum im IT Backlog-Prozess.

Zu wenig IT-Ressourcen? Diese Problemstellung scheint heute in nahezu allen Unternehmen gleich, völlig unabhängig von der Branche! Knappe Ressourcen verzögern den reibungslosen Ablauf vieler Projekte. Meist sind die Ressourcen in der IT-Abteilung der Engpass, durch den die meisten Projekte des Unternehmens beeinflusst werden. Die Priorisierung der Projekte in der IT wird somit meist zur Priorisierung der Themen des gesamten Unternehmens. In einer Engpass orientierten Betrachtung ist es daher wichtig, diese Beziehung deutlich zu machen und die Prioritäten entsprechend auf Ebene des gesamten Unternehmens zu definieren. Andernfalls entsteht der Eindruck, dass alle Bereiche an der IT-Abteilung zerren und diese entweder nicht hinterher zu kommen scheint, oder die Ressourcen nach Belieben verteilt werden. Dabei entspricht das in der Regel nicht der Realität. Die Ressourcen sind einfach zu knapp, um allen Anforderungen gerecht zu werden. Vor allem fehlt es aber an einem klaren Prozess für die Priorisierung. Die Frage wie Scrum in Kombination mit OKRs helfen kann, die richtigen Prioritäten für IT-Projekte zu finden, soll dieser Artikel beantworten.

Vom Grundsatz her ist das Thema eigentlich recht einfach: Knappe Ressourcen werden dort am sinnvollsten zuerst eingesetzt, wo die Differenz zwischen Nutzen und Aufwand am Größten ist. Einfach ausgedrückt: Was am meisten bringt und am wenigsten Aufwand macht, wird zuerst erledigt. Um diese Frage allerdings sinnvoll beantworten zu können, müssen mehrere Dinge vorgegeben werden:

• Der konkrete Umfang sollte klar umrissen sein, so dass alle Beteiligten über das Gleiche sprechen.

• Der Aufwand muss zunächst mit einer recht „groben" Granularität abgeschätzt sein.

• Der Nutzen sollte in unterschiedlichen Dimensionen klar formuliert sein.

• Die unterschiedlichen Arten an Ressourcen sollten differenziert betrachtet werden, um den spezifischen Engpass zu identifizieren.

Um die knappen IT Ressourcen bestmöglich zu priorisieren haben wir einen Backlog-Prozess entwickelt, der OKRs und Scrum miteinander verbindet und über alle Abteilungen hinweg die Themen auf Company-Ebene priorisiert. So können sich die einzelnen Teams darauf einstellen, welche Themen mit Priorität im Rahmen der nächsten OKR-Runde angegangen werden - und welche nicht. Die Themen werden in den OKR-Sets der IT sowie der jeweiligen Teams verankert. Darüber hinaus definieren die Teams natürlich auch weiterhin in ihren jeweiligen OKR-Sets welche Ziele unabhängig von IT-Ressourcen erreicht werden sollen.

Die Grundidee ist recht simpel: Alle potentiellen Key Results werden mit Initiativen hinterlegt und auf Epic-Ebene - oder ggf. noch stärker konsolidiert - in den Dimesionen Aufwand und Nutzen bewertet. Der Backlog aus allen potentiellen Initiativen und ggf. auch Maßnahmen wird nach dem Delta zwischen Ertrag und Aufwand sortiert, und die Dinge mit dem höchsten Impact und dem geringsten Aufwand werden zuerst angegangen. Dabei zeigt die zu verarbeitende Komplexität innerhalb eines Quartals an, welche Themen innerhalb einer OKR-Itteration mit hoher Wahrscheinlichkeit angegangen werden - und welche nicht. Die Wahrscheinlichkeit wird hierbei maßgeblich von der Genauigkeit der Schätzung der Komplexität und der Geschwindigkeit der Teams beeinflusst. Ein weiterer Einflussfaktor ist darüber hinaus die Konsequenz, mit der der Backlog Prozess in den jeweiligen Scrum Sprints eingehalten wird.

Die Priorisierung folgt dem Mantra „Es entscheidet sich!“. Das bedeutet konkret, dass es nicht mehr darum geht wer recht hat, sondern was richtig ist. Das „Richtige“ leitet sich dabei aus Fakten ab und wird nicht aufgrund eines Bauchgefühls entschieden. Es geht also nicht mehr darum, dass Gremien-Entscheidungen über die Priorisierung der Maßnahmen treffen, sondern viel mehr darum, dass die Einschätzung der Fakten, die zur Annahme für Kosten und Nutzen führen, von einem Kreis an Experten aus unterschiedlichen Blickwinkeln bewertet wird. Dadurch soll erreicht werden, dass die Trefferwahrscheinlichkeit für die Prognose steigt. Die jeweilige Priorität einer Maßnahme ergibt sich also automatisch auf Basis der zugrunde liegenden Logik und der Inputs in dem Prozess. Man kann also nicht mehr über die Prioritäten diskutieren, sondern nur noch über deren Einflussfaktoren. Durch die wiederkehrende Bewertung von Initiativen auf Basis der gleichen Dimensionen entwickelt sich ein entsprechendes Gefühl für die bessere Einschätzung der Faktoren. Zudem lassen sich Themen untereinander in Relation setzen, um ein besseres Gefühl zu gewinnen.

All dies dient nicht der Schaffung eines bürokratischen Systems, sondern vielmehr zur Steigerung der Wahrscheinlichkeit, die wichtigsten Dinge mit den knappen Ressourcen anzugehen. Dadurch, dass die Entscheidungen konkret formuliert und auf Basis von Fakten getroffen werden ergibt sich ein höheres Maß an Zuversicht, die richtigen Dinge zu tun. Dies führt zu einer konsequenteren Umsetzung der Themen, die begonnen wurden, da die „Angst etwas zu verpassen“ deutlich reduziert wird. Alle vorliegenden Alternativen wurden strukturiert, bewertet und die größten Hebel ausgewählt. Unserer Beobachtung nach bringt dieser Prozess deutlich mehr Ruhe in den gesamten Entwicklungsprozess, was wiederum zu deutlich besseren Ergebnissen führt. Bei gleichzeitig entspannteren und zufriedeneren Mitarbeitern. Schließlich gibt es wenig was mehr frustriert, als ständig die Richtung ändern zu müssen!

Damit eine nahezu automatische Priorisierung stattfinden kann sind mehrere Dinge erforderlich:

1. Die Bewertungskriterien müssen klar definiert sein. Dazu zählen auch mögliche Bewertungskrietrien in Form von Normierungen usw.. 

2. Die Kriterien müssen für jede Initiative bewertet sein. Es kann sich nur eine sinnvolle Priorisierung ergeben, wenn alle Dimensionen in die Betrachtung eingeflossen sind.

3. Die Gewichtung der einzelnen Kriterien untereinander muss anhand der aktuellen Strategie des Unternehmens richtig kalibriert worden sein.

In der Praxis hat es sich als hilfreich erwiesen, dass jede Initiative durch ein gewisses Standardtemplate beschrieben wird. Der Inhalt des Templates beschreibt das Vorhaben, das konkrete Ziel, die benötigten Ressourcen (aus Sicht des Anfordernden und später als „Preisschild" auf T-Shirt Size Level), die Beteiligten nach dem RACI-Modell sowie die konkrete Strategie, auf die die Initiative einwirkt.

An dieser Stelle lohnt es sich darauf einzugehen, dass sich nicht jeder Nutzen in harten Euros beziffern lässt. Zumindest nicht mit einer ausreichend hohen Vorhersagewahrscheinlichkeit und überschaubarem Aufwand für die Erhebung des Effekts. Man sollte also vermeiden die Kosten und den Nutzen einzig und allein auf die Dimension Euro zu reduzieren. Wir haben gute Erfahrungen damit gemacht hier ein gewichtetes Punktebewertungsverfahren anzuwenden und sowohl für die Kosten-, als auch für die Nutzendimension mehrere Werte zu definieren, die entsprechend einer Normierung bewertet werden. Konkret kann man auf der Nutzen-Ebene die „Leading KPIs“ adressieren, wie zum Beispiel Reichweite, aber auch Themen wie Markenbekanntheit oder Trust können eine Rolle spielen. Einsparungspotentiale über Reduktionen von Prozesskosten können Dimensionen sein, die einen Nutzen ausdrücken, auch wenn dieser erst mittelbar auf den Kunden wirkt. Auf der Aufwandsseite lassen sich sowohl personelle, als auch finanzielle Ressourcen adressieren. Darüber hinaus sollten durchaus auch weichere Faktoren wie Komplexitätssteigerung in Form von Prozesskosten usw. Berücksichtigung finden. Spannend kann es auch sein eine Risikoabschätzung mit in die Gewichtung einzubeziehen. 

Im ersten Schritt soll ein ausgewogenes Verhältnis zwischen Vorbereitung und erster Bewertung eingehalten werden. Es geht nicht darum, bürokratische Systeme zu erzeugen, die jegliche Innovation verlangsamen. Die Erfahrung zeigt aber, dass es nicht sinnvoll möglich ist, beispielsweise den Nutzen oder die Kosten einer App zu diskutieren, wenn die App und deren Hintergrund nicht weiter spezifiziert ist. Dies führt im Kontext von OKRs regelmässig dazu, dass eine Umsetzung nicht realistisch eingeschätzt werden kann, da der Umfang und die erhoffte Wirkung unklar ist. Die Summe mehrerer solcher Themen führt dazu, dass keine Einschätzung über die erforderlichen Ressourcen vorgenommen werden kann und somit keine Aussage über die Themen innerhalb einer OKR-Iterration möglich ist. Daher braucht es ein Mindestmaß an standardisiertem Anforderungsprofil, um die Themen bewertbar zu machen. Der Prozess sieht vor, dass die Anforderungen mit einer groben Aufwandsschätzung auf Ebene sogenannter "T-Shirt Sizes“ (S, M, L, XL) vorgenommen wird. Erst wenn eine Priorisierung in ein OKR-Set vorgenommen worden ist, wird mehr Aufwand in die detaillierte Planung und die granulare Schätzung der Themen investiert.

Der IT Backlog-Prozess ist als dauerhafter Prozess aufgesetzt, so dass nicht kurz vor Start einer OKR-Iterration viele Themen bewertet werden müssen, sondern die Bewertung dauerhaft während des Quartals geschieht. Initiativen, die mit einem vollständigen Template in den Prozess eingebracht werden, können innerhalb von rund zehn Werktagen mit einer Einschätzung für den Aufwand auf T-Shirt Size versehen werden. Die ausführliche Schätzung etc. erfolgt erst dann, wenn das Thema in die OKR-Iterration eingeplant worden ist. Sollte der Backlog-Prozess ein Thema identifizieren, welches sich aufgrund der Schätzungen der Priorität in die aktuelle Iterration einfügen könnte, kann das Thema in den nächsten Scrum Meetings gesondert betrachtet werden, um ggf. eine genauere Betrachtung zu rechtfertigen. Andernfalls folgt es dem Standardprozess und wird in der nächsten OKR-Runde berücksichtigt.

Die Betrachtung der Engpässe sollte auf Basis unterschiedlicher Ressourcen geschehen, sodass der jeweilige kritische Pfad identifiziert werden kann. Unter Umständen sind nur einige wenige IT-Ressourcen der konkrete Engpass und es können mehrere Themen problemlos parallel bewältigt werden. Konkret sollte die Priorisierung für die jeweiligen Engpässe vorgenommen werden. Unkritische oder identisch vorhandene IT-Ressourcen werden über die zu verarbeitende Komplexität gesteuert.

Konkret lässt sich der Prozess beispielsweise in Confluence und Jira sehr gut transparent abbilden. Geplante Initiativen werden inhaltlich in Form eines Blueprints auf einer Confluence-Seite beschrieben und mit den entsprechenden Stakeholdern abgestimmt. Wenn der Umfang und der erwartete Nutzen soweit definiert sind, kann die IT eine Einschätzung zum erwarteten Aufwand geben. Alle Themen sind transparent auf einer Übersichtsseite aufgelistet, so dass klar ersichtlich ist, wann welches Thema eingereicht wurde und welche Aufwände grob geschätzt worden sind. Daraus lässt sich eine erste Sortierung ableiten, die eine Indikation ergibt, welche Themen in die nächste OKR-Periode einfließen könnten.

Wir führen immer wieder die Diskussionen, dass der Prozess zwar gut, für die eigene Firma aber zu „wenig agil“ sei - schließlich müsse man in der agilen Softwareentwicklung ja auch agil bleiben und nicht erst Themen nach drei Monaten in die Umsetzung bringen. Grundsätzlich von der Idee her richtig. Allerdings bedeutet Agilität nicht, dass die Themen nicht entsprechend vorbereitet werden müssen. Bei aller Agilität ist es meist nämlich genau das, was auf der Strecke bleibt. Unklar definierte Themen werden angefangen ohne Schätzung für Aufwand und Erwartung auf einen Nutzen. Was dann dabei heraus kommt, bleibt oft dem Zufall überlassen. Wenn man die Entscheidungen mit der entsprechenden Detailtiefe trifft, dann spricht auch nichts dagegen mal während eines Quartals die Prioritäten zu ändern und sinnvolle Themen schneller in die Umsetzung zu bringen - solange es sich dabei um die Ausnahme und nicht um die Regel handelt. Diese können dann quasi nachweisen, warum sie unter den besprochenen Aspekten sinnvoll schneller in die Umsetzung kommen. Unsere Beobachtungen zeigen, dass dies in der Realität oft gar nicht so oft der Fall ist. Bis die Themen inkl. aller erforderlicher Spezifikation und Abstimmung wirklich in die Umsetzung gehen können, sind schnell ein paar Wochen vergangen. Behält man bei der Betrachtung im Hinterkopf, dass ein Quartal rund über 60 Arbeitstage verfügt, dann startet die Umsetzung realistisch meist nicht viel später als bei einer „spontanen“ Umsetzung. 

Umfangreiche Prozesse wie der Backlog-Prozess richten sich natürlich eher an mittlere oder größere Organisationen, in denen die Koordination der Projekte über Ebenen hinweg sowieso mit einem gewissen Aufwand - und damit auch zeitlichen Versatz - versehen ist. Kleinere Organisationen können die gleiche Systematik anwenden, verlieren aber kaum in der Umsetzungsgeschwindigkeit.

Ein Hinweis in Bezug auf die verwendete Organisationsform sollte an dieser Stelle nicht unbeachtet bleiben. Der hier vorgestellte Backlog-Prozess richtet sich vor allem an Organisationen, die funktional aufgestellt sind. Somit sind die IT-Ressourcen in einer Abteilung gebündelt und stellen einen zentralen Engpass dar. Ein Ausweg aus diesem Problem stellen crossfunktionale Organisationsformen dar, die davon ausgehen, dass ein Team über alle Ressourcen verfügt, die es zur Erreichung seiner Ziele benötigt. In dieser Organisationsform ist es im Idealfall nicht erforderlich, dass eine Abstimmung der knappen Ressourcen zwischen den Teams untereinander erfolgt. Vielmehr ist das Team selbst für ein spezielles Produkt beispielsweise mit einer Anzahl an Entwicklungsressourcen ausgestattet und kann unabhängig von anderen Themen die eigenen Ziele festlegen, die auf die Ressourcen abgestimmt sind. Dies entspricht einer produktorientierten Unternehmensform, die bereits im Vorfeld die Ressourcenentscheidung auf Basis einzelner Produkte oder Teilbereiche trifft. Die Bereiche können danach eigenständig über den Einsatz der Ressourcen bestimmen. Zumindest in Bezug hierauf gibt es dann kaum noch Abstimmungsbedarf. Die Umsetzung dieser Organisationsform bedingt allerdings auch, dass die Produkte entsprechend in der Lage sind autark verändert zu werden. Klassische, monolithische Software-Architektur beispielsweise ist hier natürlich wenig hilfreich.

Weitere Aspekte des Zusammenspiels von Scrum und OKRs werden in unserem Online-Kurs behandelt. Wer Lust hat die eigenen Prozesse für die Priorisierung der IT relevanten Themen einmal diesem Backlog-Prozess gegenüber zu stellen, kann dies beispielsweise unkompliziert im Rahmen einer Office Hour mit einem unserer OKR-Coaches tun!