Workshop Agiles Systems Engineering: Schnelle SEBRAS

Als Mitglied der GfSE-Arbeitsgruppe AgileSE war ich letzte Woche beim Präsenz-Workshop in Hamburg mit dabei. Solche Treffen sind wertvoll, weil sie etwas leisten, das in Online-Calls fast immer zu kurz kommt: echtes gemeinsames Denken an unfertigen Ideen. Und mit netten Menschen Zeit verbringen.

Die Agenda war dicht, und nicht alle Themen eignen sich für einen Blogpost. Deshalb beschränke ich mich hier auf die Punkte, die für meine Leser besonders relevant sind.

Arbeitsgruppe AgileSE

AgileSE ist eine Arbeitsgruppe der GfSE und beschäftigt sich seit Jahren mit der Frage, wie sich Systems Engineering mit agilen Denk- und Arbeitsweisen sinnvoll verbinden lässt. Das Feld ist nicht neu, aber es bleibt schwierig. Gerade deshalb ist es gut, dass es solche Gruppen gibt, die nicht nur Konzepte sammeln, sondern sie auch gemeinsam abgleichen.

Die Gruppe hat aktuell 73 Mitglieder. Aktiv mitarbeitend ist, wie so oft, nur ein kleinerer Teil. Das ist kein Problem, sondern eher normal. Entscheidend ist, dass es einen harten Kern gibt, der Themen weiterträgt, Diskussionen strukturiert und Impulse setzt.

Inhaltlich war der Workshop breit aufgestellt. Im Mittelpunkt standen SEBRAS, das Thema „System as Code“, der Blick auf angrenzende Disziplinen sowie die übergreifende Frage, wie Agile Systems Engineering mehr Reichweite und Relevanz bekommen kann.

Hier nun einige Highlights aus dem Workshop:

SEBRAS

SEBRAS ist ein Versuch, sich von dem klassischen agilen Denkmustern zu lösen und gleichzeitig die Aspekte von Systems Engineering einzubeziehen.

SEBRAS: Systems Engineering for Business Reactivity and Agility with Stripes

Ein zentraler Gedanke hinter SEBRAS ist, dass der Begriff „Sprint“ für viele Teams praktisch verbrannt ist. Zu viel Ballast, zu viele schlechten Erfahrungen, zu viele Rituale ohne Wirkung. Der Begriff „Stripe“ versucht, etwas Ähnliches neu zu fassen, aber mit mehr Eigenständigkeit und weniger mechanischer Prozesskopie. Dazu kommt die Idee der „Dorsal Stripe“, also einer verbindenden Struktur, die Kohärenz schafft, ohne alles zentral zu kontrollieren.

Der Ansatz ist im Moment noch klar ein Denkmodell und kein Framework. Genau das ist auch gewollt. Das halte ich für sinnvoll, denn viele Initiativen werden zu früh in starre Formen gegossen und verlieren dabei ihre eigentliche Stärke.

Für mich war vor allem der Abgleich mit Product Velocity spannend. Mein eigenes Ziel in der Diskussion war schlicht zu prüfen, ob es hier einen grundlegenden Konflikt gibt oder ob die Denkmodelle miteinander kompatibel sind. Das Ergebnis war erfreulich unspektakulär: Da Stripes derzeit noch relativ abstrakt sind, gibt es an dieser Stelle keinen echten Widerspruch. Beide Perspektiven beschäftigen sich mit Fluss, Autonomie, Kopplung und der Frage, wie komplexe Entwicklung organisatorisch tragfähig gemacht werden kann.

Spannend war auch die Diskussion darüber, wie ein Stripe konkret organisiert werden soll. Genau hier zeigt sich aber auch die aktuelle Schwäche des Modells. Vieles ist noch offen. Das ist ein Risiko, weil offene Modelle schnell so anschlussfähig werden, dass sie am Ende alles und nichts bedeuten. Es war auch nicht wirklich klar, wie Interessenten überhaupt mit Stripes loslegen können. Diese Spannung war im Workshop deutlich spürbar.

Dorsal Stripe Anti-Patterns

Ein weiterer Diskussionsstrang drehte sich um Anti-Patterns rund um die Dorsal Stripe. Das fand ich besonders wertvoll, denn im Product Velocity führe ich über 100 Anti-Patterns auf . Solche Formate helfen, nicht nur attraktive Zielbilder zu zeichnen, sondern auch bekannte Fehlentwicklungen explizit zu benennen. Das ist oft produktiver als die nächste Idealarchitektur auf dem Whiteboard.

Zum Schluss ging es noch um ein mögliches Buchprojekt zu SEBRAS. Auch das war keine operative Planung, sondern eher eine offene Diskussion. Wer liest heute überhaupt noch Bücher? Welche Formate funktionieren noch? Muss es wirklich ein klassisches Buch sein, oder sind andere, leichtere Formate sinnvoller? Die Fragen sind berechtigt. Gerade in solchen frühen Phasen ist das wichtiger als vorschnell ein Manuskript zu produzieren.

Agile Systems Engineering in den Mainstream bringen

Ein Thema zog sich praktisch durch den gesamten Workshop: Warum gibt es so viele gute Aktivitäten rund um Agile Systems Engineering, aber so wenig davon wird wirklich Mainstream? Das ist aus meiner Sicht eine der entscheidenden Fragen. Warum hat Agile Systems Engineering bis heute nicht den Status erreicht, den beispielsweise Git, CI/CD oder agile Softwareentwicklung längst haben? Viele gute Ideen existieren nebeneinander, aber nur wenige werden in der Breite übernommen. Genau das ist das Problem.

Für mich persönlich ist das auch einer der Gründe, warum ich mit Product Velocity bewusst den Kontakt zu anderen Communities suche. Wenn Agile Systems Engineering relevant werden soll, dann nicht als Selbstzweck innerhalb einer kleinen Fachblase, sondern als anschlussfähige Antwort auf reale Probleme in Produktorganisationen. Geschwindigkeit, Lernfähigkeit, Integrationsfähigkeit und Architekturarbeit sind keine Spezialthemen. Sie gehören in den Kern moderner Produktentwicklung.

Ein klares Ergebnis aus dieser Diskussion war: Wir brauchen mehr Struktur. Gute Inhalte reichen nicht. Solange kein tragfähiges Modell existiert, wie solche Initiativen organisatorisch, wirtschaftlich und kommunikativ weitergetragen werden, hängt alles an einzelnen motivierten Personen. Und sobald diese aufhören zu schieben, fällt das Thema wieder in sich zusammen. Deshalb ist als nächster Schritt die Entwicklung eines Business Canvas geplant.

System as Code

Der Slot zu „System as Code“ wurde von Tim Weilkiens angestoßen, unter anderem auf Basis eines Blogposts von Steve Massey Accelerating Hardware Engineering Through Agile Practices.

Das Thema trifft einen Nerv. Es geht letztlich um die Frage, wie weit sich Prinzipien aus „Infrastructure as Code“ oder „Software as Code“ auf Systementwicklung und Hardwareentwicklung übertragen lassen. Werkzeuge wie SysGit (von Steve Massey) oder auch Syside zeigen, dass hier gerade eine neue Werkzeugklasse entsteht. Das ist nicht einfach nur eine bessere Modellierungsoberfläche, sondern ein anderer Zugriff auf Änderbarkeit, Kollaboration und Nachvollziehbarkeit.

Die Diskussion im Workshop drehte sich unter anderem um die Frage, wie Modelle in solchen Umgebungen eigentlich geteilt und integriert werden sollen. Über APIs? Über textuelle Repräsentationen? Über beides? Genau an solchen Stellen wird es interessant, weil hier nicht nur Tool-Fragen verhandelt werden, sondern Grundsatzentscheidungen über Arbeitsweisen.

Ein klares Ergebnis gab es in diesem Slot nicht. Das haben wir aber auch nicht erwartet: Es war eine gute Diskussion an einem Thema, das noch nicht ausdefiniert ist und gerade deshalb relevant ist.

Blick über den Tellerrand

Ebenfalls wertvoll war der explizite Blick über die eigene Community hinaus. Agile Systems Engineering kann nicht stärker werden, wenn es nur mit sich selbst spricht. Deshalb fand ich die Einbindung angrenzender Perspektiven besonders sinnvoll: Produktmanagement, SECF, Automatisierung und auch Product Velocity.

Die Parkscheibe

Nicht alles im Workshop war schweres Grundsatzdenken. Joachim Pfeffer hatte vor einiger Zeit auf LinkedIn seine bekannte Parkscheiben-Anekdote erzählt. Er bekam ein Strafticket, weil Mercedes nicht-konforme Parkscheiben an Kunden ausgeliefert hat.

Daraus ist dann eine kleine SE-Parkscheibe mit Spickzettel geworden, die er verlost hat. Kai Kreisköther, einer der Gewinner, war beim Workshop anwesend, und die Übergabe fand direkt vor Ort statt. Solche kleinen Dinge machen Gruppen greifbar und geben ihnen Charakter.

Joachim Pfeffer im Interview: Tempo und Qualität durch agile Produktentwicklung

Fazit

Ich nehme aus dem Workshop vor allem zwei Dinge mit. Erstens: Es gibt viele gute Gedanken, aber noch zu wenig Konkretes. Zweitens: Genau deshalb sind solche Treffen wichtig. Sie helfen, lose Ideen zu schärfen, Begriffe zu klären und gemeinsame Anschlussfähigkeit herzustellen.

Und ganz unabhängig vom Inhalt gilt ohnehin: Austausch in Person ist einfach etwas anderes. Es war eine starke Runde, mit vielen klugen Perspektiven und einer guten Mischung aus Ernsthaftigkeit und Leichtigkeit.

Ich freue mich jedenfalls schon auf die nächsten Gelegenheiten zum Weiterdenken und Wiedersehen, unter anderem bei : Conquering Complexity (April 27–29), ReConf (May 7/8), Mesconf (June 8/9) und MBSE Summit.