„Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” ist eines der zwölf Prinzipien des agilen Manifests für Softwareentwicklung. Man könnte also je nach Auslegung dessen, was „couple of months“ bedeutet, ableiten, dass alles unter einer gewissen Anzahl von Releases pro Jahr keine agile Entwicklung mehr ist. Das mag vielleicht ein Indikator sein, Sie sollten sich jedoch auch bewusst machen, ob in Ihrem konkreten Kontext überhaupt die Notwendigkeit, Möglichkeit und Sinnhaftigkeit für eine solche Releasefrequenz besteht. Die Frage nach der Zweckmäßigkeit haben wir bereits im ersten Beitrag unserer Serie adressiert und im letzten Beitrag sowie in einem Fachartikel sind wir auf eine in vielen Bereichen essenzielle Voraussetzung für Releases eingegangen, die Dokumentation – oder genauer gesagt einen Ansatz („Continuous Documentation“), um diese aktuell und in einem releasefähigen Zustand zu halten. In diesem Beitrag möchten wir nun auf die aus unserer Erfahrung heraus wichtigsten Punkte eingehen, die bei der Releaseplanung im Rahmen einer Produktentwicklung zu berücksichtigen sind.

Der zentralste Punkt in der technischen Entwicklung und gleichzeitig eines der maßgeblichen Unterscheidungsmerkmale zwischen der agilen Softwareentwicklung und agilem Systems Engineering ist die Beteiligung unterschiedlicher Gewerke und damit einhergehend der Notwendigkeit die Entwicklungsaktivitäten dieser zu synchronisieren (siehe Abbildung 1). Das Ziel: Das Release eines integrierten Gesamtproduktes. Was gibt es dabei zu beachten bzw. welchen Hilfsmitteln können Sie sich in diesem Kontext bedienen?

Wichtig ist, dass alle Gewerke ein gemeinsames Ziel verfolgen, daher ergibt es Sinn, ein gemeinsames MVP (Minimal Viable Product) auf Produktebene zu definieren. Dieses gemeinsame MVP erlaubt bzw. erleichtert den einzelnen Gewerken Ihre spezifischen Entwicklungsaktivitäten daran auszurichten und die konkreten Aufgaben zu priorisieren und untereinander abzustimmen. Wie der Name des MVP bereits impliziert, ist es wichtig, dass Sie sich bewusst machen, dass es sich um ein Minimal Viable Product nicht etwa um ein Minimal Viable System handelt. Berücksichtigen Sie daher nicht nur das System bei der Planung der entsprechenden Aktivitäten, sondern auch notwendige Tätigkeiten, die über die einzelnen Gewerke hinausgehen. Darunter fallen z.B. die übergreifende Produktdokumentation, die Integration als solche sowie die Verifikation und Validierung auf System- und Produktebene. Berücksichtigen Sie diese Tätigkeiten auch entsprechend in Ihrem Product Backlog, denn auch hier handelt es sich um ein Product, nicht etwa um ein System Backlog. So sollten Sie alle notwendigen Tätigkeiten für das Release des Gesamtproduktes in Ihrem Backlog berücksichtigen – auch beispielsweise die Produktion und Logistik – und die Priorisierung auf den unteren Ebenen entsprechend der Priorisierung der Produktebene ableiten. Um keine wesentlichen Tätigkeiten zu vergessen, sollten Sie Definitions of Ready sowie Definitions of Done auf den unterschiedlichen Architekturebenen definieren, deren Inhalte sich dementsprechend unterscheiden und auf die entsprechende Ebene sowie die relevanten Gewerke zugeschnitten sind.

Ausgehend von der Definition Ihres MVP oder MMP (Minimal Marketable Product) können Sie nun in die Planung der dafür notwendigen Tätigkeiten gehen. Seien Sie sich bewusst, dass nicht jedes Inkrement marketable sein muss, sondern mehrere Inkremente zu einem vermarktbarem Release zusammengefasst werden können. Wir empfehlen Ihnen hierfür eine Rückwärtsplanung ausgehend vom geplanten Releasetermin des MVPs/MMPs. Es ist durchaus üblich, dass die Releasezyklen der Hardware die Releasetermine des Produkts maßgeblich prägen. Zur Visualisierung kann eine Roadmap hilfreich sein. So haben Sie die Möglichkeit sowohl Abhängigkeiten zwischen den Gewerken und Aktivitäten auf derselben Ebene als auch Abhängigkeiten zwischen höheren und niedrigeren Ebenen zu berücksichtigen und kenntlich zu machen. Das Gesamtprodukt lässt sich z.B. erst integrieren, wenn die einzelnen Komponenten in integrationsfähiger Qualität zur Verfügung stehen. Machen Sie sich bewusst, welches Ziel Sie mit der Roadmap verfolgen und arbeiten Sie ggf. mit unterschiedlichen Roadmaps bzw. unterschiedlichen Sichten auf dieselbe Roadmap abhängig von ihrem Zweck. Für eine langfristige Planung kann beispielsweise die Abbildung einer höheren Abstraktionsebene Sinn ergeben, wohingegen für die Planung eines einzelnen Releases die Betrachtung einer niedrigeren Abstraktionsebene Sinn ergibt, um dort z.B. Abhängigkeiten zwischen den einzelnen Gewerken abzubilden. 

Sie sind interessiert an mehr Details und Good Practices zum Thema Releaseplanung im agilen Systems Engineering oder agilem Systems Engineering im Allgemeinen? Dann besuchen Sie einfach unser neues Training „Agiles Systems Engineering“, in dem Sie mehr zu möglichen Lösungsansätzen aus der Welt des agilen Systems Engineering erfahren und mit unseren Experten diskutieren können.