Dieses Bild hat ein leeres Alt-Attribut. Der Dateiname ist as.png

Fast jedes Unternehmen betreibt Forschung und Entwicklung (R&D), um innovative Produkte auf den Markt zu bringen. Die Entwicklung innovativer Produkte ist naturgemäß risikobehaftet: da es um Produkte geht, die noch nie zuvor angeboten wurden, ist meistens unklar, ob und zu welchem Grad erwünschte Eigenschaften der Produkte realisierbar sind und wie genau sie sich realisieren lassen. Der Erfolg von R&D hängt also maßgeblich an der Gewinnung und Verwertung von Wissen über die Realisierbarkeit von Produkteigenschaften.

Scrum ist heute mit Abstand die beliebteste Form des agilen Projektmanagements. Einige Hauptmerkmale von Scrum sind stetige Transparenz über den Produktfortschritt, Zielorientierung, einfache Abläufe, flexible Arbeitsweisen und effiziente Kommunikation. Scrum ist ein flexibles Rahmenwerk und beinhaltet nur eine Handvoll Aktivitäten und Artefakte. Scrum lässt absichtlich offen, wie Backlog Items (BLIs) strukturiert sind, was die Definition of Done (DoD) von BLIs ist und wie genau der Refinement-Prozess ablaufen sollte. Diese Aspekte muss ein Scrum Team selbst steuern. Auch durch diese Flexibilität ist Scrum so erfolgreich: Scrum wird in einer Vielzahl von Domänen angewendet und dort mit domänenspezifischen Prozessen oder Artefakten ergänzt .

Auch in R&D ist Scrum fest etabliert. Wie oben beschrieben hängt der Erfolg eines R&D Scrum Teams davon ab, wie effizient das Team Wissen gewinnt und verwertet. Zur Wissensgewinnung haben sich im Scrum Kontext sogenannte Spikes etabliert. Spikes sind BLIs, in denen Wissen über die Machbarkeit und den Aufwand von Produkteigenschaften gewonnen wird, ohne die Eigenschaften zu realisieren. In diesem Post wollen wir aufzeigen, worauf es bei der Umsetzung von Spikes in Scrum ankommt und wie ein Scrum Team sicherstellen kann, dass das aus Spikes gewonnene Wissen optimal verwertet wird. Wir illustrieren diese Good Practices mit konkreten Beispielen aus 1,5 Jahren Scrum in einem Forschungsprojekt mit EnBW.

Inhaltsverzeichnis

Spikes
Good Practice: Regeltermin für die „Spike-Pflege“ im Backlog
Good Practice: Laborbuch
DoR und DoD für Spikes: Hypothesis-first learning
Schlussfolgerung

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

Spikes

Eine breit etablierte Methode zur Wissensgewinnung in Scrum sind sogenannte Spikes – BLIs, in denen die Machbarkeit und der Aufwand von Produkteigenschaften eingeschätzt werden, ohne die Eigenschaften zu realisieren. Die Idee von Spikes entstammt dem eXtreme Programming (XP).

Die Wissensgewinnung durch Spikes dient dem Abbau von übermäßigem Risiko. Der Anteil von Spikes am Backlog sollte also proportional zum aktuellen Risiko bei der Produktentwicklung sein. In einem R&D Scrum Team kann es viele offene Fragen und Risiken geben und Spikes können mehr als die Hälfte eines Sprints ausmachen, wie z.B. zeitweise im Google AdWords Scrum Team. Ein übergroßer Anteil von Spikes hemmt allerdings die Produktivität eines Teams, weil zu viel Zeit mit Wissensgewinnung und zu wenig Zeit mit der Umsetzung des Produkts verbracht wird. Die Priorisierung von Spikes gegenüber regulären BLIs ist also ein wichtiger Faktor für den Erfolg von R&D Scrum Projekten.

Ein weiterer wichtiger Faktor ist die Definition von Qualitätskriterien für Spikes. Konkret kann ein Scrum Team eine Definition of Ready (DoR) und eine Definition of Done (DoD) für Spikes etablieren. Die DoR legt fest, welche Kriterien ein Spike erfüllen muss, um bearbeitet zu werden; die DoD bestimmt welche Kriterien erfüllt sein müssen damit ein Spike abgeschlossen werden kann. Beide Definitionen beeinflussen die Qualität und Menge des erzeugten Wissens und dessen Verwertbarkeit im Scrum Prozess. Die DoD ist ein obligatorischer Bestandteil von Scrum. Die Einführung einer DoR liegt hingegen im Gestaltungsspielraum des Scrum Teams und ist auch nicht immer nützlich.

Anlass für einen Spike ist fast immer ein akutes und konkretes Risiko bei der Produktentwicklung. Erkenntnisse aus einem Spike können aber über den konkreten Anlass des Spikes hinaus wertvoll sein und langfristig bei Entscheidungen in der Produktentwicklung helfen. Um eine Langzeitwirkung zu entfalten, müssen Erkenntnisse aus Spikes vom Team geeignet aufbewahrt werden.

Die Anwendung von Spikes in R&D Projekten wirft also mindestens drei Fragen auf:

Wie werden Spikes untereinander und gegenüber anderen BLIs priorisiert?
Wie werden DoR und DoD für Spikes formuliert?
Wie wird das in Spikes gewonnene Wissen aufbewahrt?

Die Literatur über Scrum lässt diese Fragen weitgehend offen. In einem mehrjährigen R&D Forschungsprojekt mit EnBW konnten wir verschiedenen Antworten auf die Fragen anwenden und damit Erfahrungen sammeln. Dabei haben wir zwei Good Practices entwickelt, die wir in diesem Blogpost vorstellen: (1) ein Regeltermin zur „Spike-Pflege“, d.h. zum Schärfen konkreter Hypothesen in Spikes und (2) ein leichtgewichtiges Laborbuch zur Protokollierung von Erkenntnissen. Die beiden Praktiken ergänzen wir außerdem durch eine passende DoR und DoD.

Good Practice: Regeltermin für die „Spike-Pflege“ im Backlog

Das Refinement ist eine fortlaufende Aktivität des gesamten Scrum Teams. Dabei werden BLIs aus dem Backlog für die Bearbeitung vorbereitet: BLIs werden präziser reformuliert, in unabhängige BLIs aufgeteilt und in konkrete Arbeitsschritte zerlegt. Viele Scrum Teams nutzen einen Regeltermin, um das Refinement gemeinsam durchzuführen und dabei ein gemeinsames Verständnis des Backlogs zu erlangen.

Unserer Erfahrung nach ist ein gemeinsames Refinement ein häufiger Entstehungsort für Spikes. Denn wenn das Team über das Backlog diskutiert, fallen ungeklärte Fragen und Risiken auf. Offene Risiken in einem BLI äußern sich oft darin, dass das Team Schwierigkeiten hat eine konkrete DoD festzulegen und dass die Aufwandsschätzungen der Teammitglieder stark auseinandergehen. Auch bestimmte Formulierungen von Teammitglieder können auf Risiken hinweisen, z.B.:

„Keine Ahnung, ob das geht.“
„Ich weiß noch nicht, wie ich das machen soll.“
„Da muss ich mich erstmal einlesen.“

Nach der Identifizierung eines Risikos muss das Team entscheiden, ob das Risiko so groß ist, dass es mit einem Spike reduziert werden sollte. Der Spike wird dann im Backlog als BLI-Entwurf angelegt. Um den regulären Refinement-Termin nicht zu sprengen, empfehlen wir, frisch angelegte Spikes nicht in diesem Termin zu refinen und zu priorisieren. Stattdessen empfehlen wir, dass sich das Team regelmäßig ein bis zwei Tage nach dem regulären Refinement trifft, um „Spike-Pflege“ zu betreiben. In der Zwischenzeit können die Spike-Entwürfe auch einzelnen Teammitgliedern zugeteilt werden, die diese dann für den Spike-Pflege-Termin vorbereiten, z.B. durch Sammlung konkreter Hypothesen und Ideen für Experimente.

Natürlich können Spikes auch außerhalb eines gemeinsamen Refinement Termins entstehen, z.B. während der Umsetzung eines BLIs. Auch dann bietet es sich an, die Spikes als Entwürfe zu sammeln und dann im nächsten Spike-Pflege-Termin nachzuschärfen. So geraten die Anlässe der Spikes nicht in Vergessenheit, führen aber auch nicht zu Scope Creep im aktuellen Sprint.

Im Spike-Pflege-Termin müssen die gesammelten Spikes schließlich refined und im Backlog priorisiert werden. Unserer Erfahrung nach haben die meisten Spikes einen direkten Bezug zu einem oder mehreren BLIs – nämlich die BLIs bei deren Umsetzung es akut Risiken gibt. In diesem Fall ist die Priorisierung einfach: man nutzt die bestehende Priorisierung der BLIs und fügt jeden Spike vor seinem zugehörigen BLI in die Liste ein.

Good Practice: Laborbuch

Zur Aufbewahrung des gewonnenen Wissens aus Spikes schlagen wir ein leichtgewichtiges Laborbuch vor. Das Laborbuch dokumentiert für jeden Spike folgende Aspekte in jeweils 1-2 Sätzen:

Problemstellung: Welches akute Risiko in der Produktentwicklung soll entschärft werden? Welche Fragen müssen dafür geklärt werden?
Hypothesen: Aufstellung möglichst konkreter Hypothesen, die sich entweder recherchieren oder experimentell prüfen lassen.
Erkenntnisse: Zusammenfassung der experimentellen Ergebnisse oder der Recherche.
Konsequenzen: Bedeutung der Erkenntnisse für das Produkt. Z.B. „Produkteigenschaft X kann mithilfe von Y erreicht werden, mit Z aber nicht.“
Relevante Links, z.B. zu detaillierten experimentellen Ergebnissen und BLIs

Entscheidend für den langfristigen Mehrwert des Laborbuchs sind dessen Vollständigkeit und Kompression. Vollständigkeit heißt, dass die Ergebnisse sämtlicher Spikes im Laborbuch landen; Kompression heißt, dass nur die wesentlichen Erkenntnisse und Konsequenzen für das Projekt kurz und knapp in das Laborbuch eingetragen werden. In dieser Qualität kann das Laborbuch als Nachschlagewerk in Diskussionen eingesetzt werden.

Im Projekt mit EnBW haben wir das Laborbuch als eine Wikiseite im Projektwiki des Teams umgesetzt. Die Einträge auf der Seite haben wir absteigend chronologisch sortiert, d.h. das Wissen aus den aktuellen Spikes stand ganz oben. Wir haben das Laborbuch ca. ein Jahr lang angewendet und konnten in dieser Zeit keinerlei Skalierungsprobleme wahrnehmen. Das Laborbuch genoss als Wissensquelle im Team ein hohes Ansehen und wurde regelmäßig in Diskussionen eingesetzt.

DoR und DoD für Spikes: Hypothesis-first learning

Kommen wir nun zu unserer letzten Empfehlung: einer konkreten Definition von DoR und DoD für Spikes, die auf die beiden vorigen Good Practices abgestimmt ist.

Die DoR legt fest, welche Kriterien Spikes erfüllen müssen, bevor sie in einen Sprint aufgenommen und bearbeitet werden können. Wie erwähnt ist die DoR nicht Teil von Scrum, sondern eine häufig genutzte Erweiterung. Manche Scrum Experten sehen die DoR kritisch, weil sie dazu führen kann, dass wichtige BLIs aus „Schönheitsgründen“ nicht in einen Sprint aufgenommen werden. Wir schlagen deshalb einen Kompromiss vor: wichtige BLIs werden immer in den nächsten Sprint aufgenommen, aber die bearbeitende Person ist dafür verantwortlich, dass das BLI vor der Bearbeitung die DoR erfüllt. Das heißt, die Erfüllung der DoR-Kriterien ist der erste Arbeitsschritt jedes BLIs.

Unser Vorschlag der DoR für Spikes ist simpel: vor Bearbeitung eines Spikes muss der Laborbucheintrag des Spikes möglichst präzise vorausgefüllt werden. Insbesondere müssen die zu untersuchenden Hypothesen klar aufgelistet werden. Im Team mit EnBW haben wir gute Erfahrungen damit gemacht, dass ein Teammitglied vor Bearbeitung des Spikes selbst die Hypothesen formuliert und diese dann von einem anderen Teammitglied kritisch prüfen lässt. Wenn die Hypothesen vollständig, verständlich und klar definiert sind, kann die Bearbeitung des Spikes beginnen.

Der Laborbucheintrag gibt dem Spike einen Rahmen vor. Das ist vergleichbar zum bekannten test-driven development (TDD) in der Softwareentwicklung. Dort wird zuerst mit Unit Tests definiert, was die Software leisten soll, danach wird sie implementiert. Die Erstellung eines Laborbucheintrags vor jedem Spike könnte man analog als hypothesis-driven learning (HDL) bezeichnen: zuerst wird mit Hypothesen definiert, was gelernt werden soll, danach werden die Hypothesen untersucht.

Die Analogie zwischen TDD und HDL eignet sich auch um die Vorteile von HDL zu beschreiben. Genauso wie TDD einen stetigen Anreiz zur Reduktion der Softwarekomplexität setzt, setzt HDL einen Anreiz für einfache und zielgerichtete Experimente. Und genauso wie programmierte Tests in TDD einen Großteil der schriftlichen Dokumentation einer Software ersetzen, so ersetzen die Laborbucheinträge in HDL einen Großteil der schriftlichen Dokumentation des Wissens aus Spikes.

Mindestens so wichtig wie die DoR ist die DoD eines Spikes. Sie legt fest, welche Kriterien erfüllt sein müssen, damit der Spike abgeschlossen ist. Auch diese Kriterien lassen sich am Laborbucheintrag des Spikes festmachen. Konkret schlagen wir vor, dass ein Spike fertig ist, wenn alle im Laborbucheintrag gelisteten Hypothesen bestätigt oder verworfen sind, der Laborbucheintrag geschrieben ist und die Ergebnisse im Team kommuniziert wurden.

Schlussfolgerung

In diesem Blog-Post haben wir einen konkreten Vorschlag gemacht, wie man Spikes in R&D Scrum Projekten einsetzen sollte. Unser Vorschlag befähigt ein R&D Scrum Team dazu, die Realisierbarkeit von innovativen Produkteigenschaften einzuschätzen – rechtzeitig vor der Umsetzung des Produkts und mit angemessenem Aufwand.

Kern unseres Vorschlags sind zwei Good Practices, die sich in unseren eigenen R&D Scrum Projekten bewährt haben: erstens, ein Regeltermin zur Spike-Pflege und zweitens, ein leichtgewichtiges Laborbuch zur Protokollierung von Erkenntnissen. Wir haben gezeigt, wie sich beide Praktiken mithilfe einer simplen DoR und DoD in Scrum einbinden lassen.

Mit den beiden Good Practices befüllen wir eine Lücke in der Scrum Literatur: es gibt bisher kaum konkrete Praktiken zur Erstellung, Priorisierung, Qualitätssicherung und Langzeitverwertung von Spikes. Die vorgeschlagenen Good Practices sind simpel und allgemein genug, um für die meisten R&D Scrum Teams anwendbar und nützlich zu sein. Wir freuen uns, wenn sich andere Scrum Teams davon inspirieren lassen.

Autor

Moritz Renftle
Data Scientist bei scieneers GmbH
moritz.renftle@scieneers.de