Simpler Ansatz – grosse Wirkung

Business, Entwicklung und Betrieb, oder in ihren englischen Entsprechungen, Business, Development und Operations, bilden die Grundlage der modernen Produktentwicklung in der IT. BizDevOps, wie der Ansatz genannt wird, versucht, die Lücken zwischen dem Business und der IT zu schliessen.

Vor etwas mehr als zehn Jahren etablierte sich das so genannte DevOps-Modell. Auf der Seite der IT wurde hier eine bestehende Lücke geschlossen, die zwischen Entwicklung und Betrieb bestand. Ziel war es, dass neuentwickelte Software und neue Funktionen möglichst schnell veröffentlicht werden konnten.

Dabei gab es häufig aber noch einen Haken. Die aus den Geschäftseinheiten gestellten Anforderungen waren in der Regel ohne Einbeziehung der IT erstellt worden. Dabei wichen die Ideen und Anforderungen der Fachbereiche oft von den Möglichkeiten der IT ab. In der Konsequenz ging der gewonnene Geschwindigkeitsvorteil, der sich aus der engeren Zusammenarbeit von Betrieb und Entwicklung ergeben sollte, wieder verloren.

Um dies zu verhindern, entstand das BizDevOps-Modell. Das Business, also die Fachbereiche mitsamt Vertrieb, rücken näher an die IT, um so die unternehmerischen Visionen in digitale Lösungen zu giessen. Wie dieser Ansatz in der Praxis wirkt, möchte ich an zwei Beispielen aus der Praxis schildern.

Zunächst ein Exempel dafür, wie man es nicht machen sollte: Als ich vor ein paar Jahren frisch die Rolle des Product Owners übernommen hatte, lagen schon bald die Anforderungen von anderen Produktmanagern auf meinem Schreibtisch, die in meiner Applikation umgesetzt werden sollten. Die Produktmanager versicherten mir, dass die Anforderungen über mehrere Monate spezifiziert und ausgearbeitet worden seien, es also keine Probleme damit geben sollte. Also stimmte ich in meiner Unerfahrenheit zu und brachte die Anforderungen in unsere Sprint-Planung ein.

Um es kurz zu machen: Die Anforderungen wurden von den Anwesenden zerrissen. Die auf dem Tisch liegende Spezifikation erschien völlig sinnlos, da die Antragsstellenden unsere Systeme nicht kannten. Damit blieb nichts anderes übrig, als gemeinsam mit den Entwicklerinnen und Entwicklern von vorn zu planen, damit am Ende auch etwas Nützliches entstehen konnte.

Und damit zu einem Beispiel dafür, wie es besser geht: Aus dieser ersten Erfahrung in der neuen Aufgabe habe ich meine Lehren gezogen. Bevor ich eine Anforderung in die Sprint-Planung einbringe, spiegle ich diese zunächst unseren Entwicklerinnen und Entwicklern, unabhängig von ihrem Umfang. In diese Gespräche gehe ich auch nicht mit einer völlig ausgearbeiteten Anforderung. Meist handelt es sich eher um die Vision davon, was diese erfüllen soll. Das spart viel Zeit, Geld und Nerven. Die idealen Besprechungen dauern dann nur zehn Minuten, wenn ich kurz die Anforderung skizziere und einen Lösungsvorschlag mitbringe, können die Entwicklerinnen und Entwickler diesen sofort aufgreifen, aber einen eigenen Vorschlag unterbreiten, wie sich das Ziel einfacher und effizienter erreichen lässt.

BizDevOps ist für mich ein Ansatz bzw. ein Leitfaden, der in verschiedenen agilen Modellen eingesetzt werden kann. Es spielt keine Rolle, ob das Lean, SAFe, Scrum oder Kanban ist. Wichtig ist dabei nur, dass alle Parteien in die Lösungsfindung mit einbezogen werden.