Gerade dann wenn die Bedeutung eines Begriffs für alle Beteiligten scheinbar selbstverständlich ist lohnt sich ein näherer Blick. Das gilt natürlich auch für die Fachsprache die sich über die Jahrzehnte im Rahmen der agilen Arbeitsweisen entwickelt hat. Ein Fall an dem sich das aufzeigen lässt ist der Sprint. Je nach Kontext können sich hinter diesem Wort stark unterschiedliche Ausprägungen verbergen, derer man sich bewusst sein sollte wenn man es benutzt.

Die in der Realität am häufigsten anzutreffende Variante lässt sich am besten als "Endspurt" beschreiben. Nach längeren Anforderungserhebungs- und Planungsprozessen geht es hier nur noch darum das definierte Ergebnis in kurzen Schüben umzusetzen (häufig anzutreffen in SAFe). Sinn macht ein derartiges Vorgehen vor allem dann wenn die Anforderungen und Nutzerbedürfnisse relativ klar und stabil sind, die Umsetzung aber technisch oder organisatorisch anspruchsvoll ist. Der Inspect & Adapt-Zyklus dient dann nur noch der Überprüfung und Anpassung des Umsetzungsvorgehens. Das mit diesem Ansatz verbundene Risiko ist, dass er entgleisen kann wenn die Anforderungen sich ändern.

Auch der umgekehrte Fall existiert, es sind die so genannten "Design Sprints". In ihrer bekanntesten Variante enthalten sie nicht nur das blosse Anforderungsdesign sondern auch die Erstellung erster Prototypen oder Vorführ-Versionen und deren Validierung an einer echten Anwender-Zielgruppe. Sobald diese positiv reagiert erfolgt die Übergabe an die eigentliche Umsetzung. Sinn macht ein derartiges Vorgehen vor allem dann wenn die Anforderungen und Nutzerbedürfnisse noch unklar oder instabil sind. Der Inspect & Adapt-Zyklus dient vor allem dem Erstellen und Verwerfen von Bedarfs- oder Anwendungs-Hypothesen. Das mit diesem Ansatz verbundene Risiko ist, dass seine Ergebnisse sich als nur schwer umsetzbar herausstellen können.

Der dritte Typ entspricht den Sprints in Scrum oder den Iterationen in Extreme Programming. Der Anspruch dieses Ansatzes ist, auf der Basis einfach formulierter Anwender-Bedürfnisse sowohl das Design als auch die Umsetzung einer Funktionserweiterung in einem (!) Intervall umzusetzen. Sinn macht dieses Vorgehen wenn sowohl die Anforderungen und Nutzerbedürfnisse als auch die Bedingungen der Umsetzung sich ändern können. Der Inspect & Adapt-Zyklus sollte alle dieser Aspekte berücksichtigen. Das mit diesem Ansatz verbundene Risiko ist, dass er bei vielen Abhängigkeiten und hohem Abstimmungsbedarf unverhältnismässig viele Ressourcen für diese Themen verwendet.¹

Was anhand dieser verschiedenen Ausprägungen erkennbar ist: abhängig von Verständnis und Erfordernissen kann sich jeweils etwas Unterschiedliches hinter dem scheinbar klaren Begriffs des Sprints verbergen (dazu kämen noch Antipattern wie z.B. der Konzeptions-Sprint", der "Test-Sprint" oder der "Gewaltmarsch"), es macht also grossen Sinn sich zu vergewissern welches im eigenen Fall vorliegt.