Release Management resp. generell Release von Software und Features in agilen Organisationen - ob nach Scaled Agile Framework (SAFe) oder nicht - ist ein Thema, das zu vielen Diskussionen führt und zu dem sehr unterschiedliche Meinungen existieren. Wir zeigen in diesem Artikel unsere Sicht zu diesem Thema auf.
Autonomie und Abhängigkeiten
Einerseits hat eine agile Organisation und agile Entwicklung zum Ziel, den einzelnen Teams möglichst viel Autonomie und Entscheidungskompetenz zukommen zu lassen. Alles, was dezentral geregelt werden kann, soll auch dort entschieden, geregelt und umgesetzt werden. Diese Ambition ist ein Leitfaden für die internen Prozesse, die Organisation interdisziplinärer Teams und die Architektur.
In grossen Unternehmen mit einer komplexen System- und Prozesslandschaft und mit hoher Wahrscheinlichkeit einigen monolithischen Legacy-Applikationen ist diese Ambition jedoch kaum unmittelbar zu erreichen. Selbst wenn die Architektur perfekt ist und die Systeme modular und entkoppelt sind, können systemübergreifende Geschäftsprozesse trotzdem noch zu Abhängigkeiten zwischen den Teams führen und damit die Autonomie der Teams einschränken.
Release Management und Scaled Agile Framework
Genau hier kommt nun das Release Management ins Spiel. Um die Freigabe von Anpassungen in Produktion zu alignieren und zu koordinieren, braucht es das Release Management. Es unterstützt die Product Owners, Release Train Engineers und Solution Train Engineers bei dem Releasing.
Der Release Prozess ist gemäss Definition von SAFe von der Entwicklung entkoppelt und soll dem Business die Fähigkeit geben, on Demand zu releasen. Daher kann auch nicht einfach gesagt werden, was in einem PI umgesetzt wird, wird anschliessend released. Das schränkt zu stark ein und bringt keinen grossen Fortschritt im Vergleich zu den früheren phasen-basierten Entwicklungsprozessen. Das Release Management definiert den schlankestmöglichen Prozess, den es braucht um aus einem Increment eine Releasable Solution zu erstellen.
Minimal nötige Koordination
Selbst in einem Umfeld welches den Teams völlige Autonomie ermöglicht, kann es immer noch Gründe für eine übergreifende Release Koordination geben. Dies kann z.B. eine Marketing Kampagne sein, die auf allen Systemen zur gleichen Zeit aufgeschaltet werden muss oder ein Rebranding eines Unternehmens, das auch koordiniert und aligniert erfolgen muss. Release Management hat also auch seine Daseinsberechtigung in agilen Unternehmen.
Aber was ist dann anders? Der Unterschied zu ‚früher‘ ist, dass nur koordiniert werden soll, was wirklich auch muss. Die Ambition muss immer die sein, dass so autonom wie möglich released werden kann. Zudem nimmt mit dem agilen Ansatz das Release Management nicht mehr die zentrale, steuernde, kontrollierende und überwachende Rolle ein, sondern entwickelt sich zu einer Dienstleistung, die die Product Owner, Release Train Engineers und Solution Train Engineers unterstützen soll.
Trennung Release und Deployment
Als Hinweis möchten wir noch erwähnen, dass wir unter Releasing das Freischalten einer Funktionalität oder sonstiger Änderung in Produktion verstehen. Das Deployment soll immer dezentral möglich sein und darf und soll nicht eingeschränkt werden. Idealerweise deployen die Teams kontinuierlich und das Releasing besteht ‚nur’ noch in der Freischaltung der Änderung. Dazu gibt es Möglichkeiten wie zum Beispiel Feature Toggles. Das Handling von Feature Toggles ist nicht trivial und bedarf genauso wie Source Code eines Prozesses für QA und Version Management.
Links
Folgende vier Links empfehlen wir zu diesem Thema:
- Feature Toggles
- Continuous Integration
- Release on Demand (SAFe)
- Continuous Integration vs. Continuous Delivery vs. Continuous Deployment
Kontakt
Was ist Ihre Meinung dazu? Gerne diskutieren wir dies mit Ihnen, unsere Kontaktdaten sind auf unserer Webseite zu finden unter http://avega.ch/#contact.