DevOps: Der standardisierte Release-Prozess

Im letzten Beitrag haben wir über die Wichtigkeit von Product Roadmaps gesprochen und wie trotzdem die Agilität bewahrt werden kann. In dem heutigen Beitrag geht es um die diesbezügliche Team-Synchronisation, Tool-Unterstützung und standardisierte Release-Prozesse.

1. Team-Synchronisation
2. Tool-Unterstützung
3. Standardisierter Release-Prozess

1. Team-Synchronisation

Zu jedem Release empfiehlt sich hier eine Runde mit allen Product Ownern, um einen detaillierten Blick auf die To dos der nächsten beiden Sprints zu werfen. So ergeben sich dann kurzfristig Abhängigkeiten und Synergieeffekte. Zu diesem „Roadmap-Sync-Termin“ können natürlich auch andere Mitarbeiter, die nicht aus der Produktentwicklung selbst kommen, eingeladen werden. Denn jeder darf bei der Priorisierung der Produktentwicklungsthemen mitmachen oder auf dem Laufenden bleiben. Erfahrungsgemäß werden auf diese Weise neue Aspekte und Feedbacks mit eingebunden. In der Realität ist es jedoch oft so,

dass viele Mitarbeiter zu sehr in ihrem operativen Geschäft gefangen sind und somit schlichtweg keine Zeit übrig ist, um sich mit der Produktentwicklung zu beschäftigen. Ein Punkt, für den ich persönlich noch keine gute Lösung gefunden habe.

Parallel haben wir einen „technischen Release Sync-Termin” etabliert, bei dem die nächsten beiden Releases aus technischer Sicht beleuchtet werden, um Abhängigkeiten schon frühzeitig zu erkennen. Natürlich werden in diesen Terminen auch Retrospektiven durchgeführt, um aus den Dingen, die eben besonders gut oder eben besonders schlecht gelaufen sind, zu lernen.

Klingt nach viel Overhead? Das mag sein. Aber wir reden ja nicht nur über Growth Hacking oder agile Produktentwicklung für Start-ups, sondern ebenso für größere Unternehmen. Dass dort eine Abstimmung notwendig ist, sollte jedem klar sein, der schon einmal in einem Unternehmen gearbeitet hat.

2. Tool-Unterstützung

Wir sind Nerds – wir lieben natürlich Tools. Aber etwas vorweg, das sich bei meinen Teams immer bewährt hat: Kein Tool der Welt ersetzt das persönliche Gespräch, und zwar unabhängig davon, ob im Eins-zu-Eins-Gespräch oder im Team. Nicht vergessen!

Als abteilungsübergreifendes Projekt-Management-Tool haben wir von Atlassian das Tool Jira eingeführt und dann laufend erweitert um die Module Jira Agile (Scrum Support), Jira Zephyr (Testmanagement) und Confluence (Wiki und Chat). Als Team-Chat sind wir mit Hipchat gestartet und wechseln derzeit auf Slack. Wiederum vor allem für die Abstimmung innerhalb von Teams ein guter Fortschritt, auch wenn wir intern leider noch eine Hipchat-Fraktion und eine Slack-Fraktion haben, was natürlich keinen Sinn macht. Zwei unterschiedliche Team-Kommunikations-Tools sind kontraproduktiv. Das ist ein gutes Beispiel dafür, dass man die Produkt-Teams nicht immer selbst entscheiden lassen sollte, welche Tools sie am besten bei der täglichen Arbeit unterstützen und welche nicht.

Insgesamt war die Tool-Einführung bei Trusted Shops ein voller Erfolg, da die Teams die Kommunikation und Abstimmung über Jira und Co. lieben. Das ist der Erfolgsfaktor für diese Art von produktivitätssteigernden Tools. Die User müssen die Tools gern nutzen, sonst schreiben sie wieder endlose E-Mails an riesige Empfängerkreise.

3. Standardisierter Release-Prozess

Die Produkt-Teams bei Trusted Shops arbeiten jetzt schon seit 2013 in Sprints von zwei Wochen. In dieser Zeit gab es nur ein einziges geplantes Release, welches wir ausfallen lassen mussten. Der Grund war allerdings relativ simpel: das hohe Traffic-Aufkommen in der Vorweihnachtszeit. Das ist natürlich ein spezielles Problem der E-Commerce-Branche – zudem ein Luxusproblem, wenn der Traffic sich geplant vervierfacht. Allerdings ist das Risiko eines Releases in der Hochphase des Weihnachtsgeschäfts tatsächlich sehr hoch, da wir einen Fehler oder gar eine Downtime unserer Widgets, die in über 20.000 Online-Shops eingebunden sind, den Kunden gegenüber nicht verantworten können.

Umso wichtiger ist ein perfekt eingespielter und standardisierter Ablauf des Release-Prozesses, teamübergreifend. Gute und regelmäßige Kommunikation, eine bestenfalls nahezu 100-prozentige Abdeckung durch automatische Tests sowie zumindest eine Annäherung an die Prinzipien von Continuous Integration und Continuous Delivery gelten hinsichtlich der Releasequalität und -geschwindigkeit als die wichtigsten Erfolgsfaktoren.

Die Releasequalität ist für ein junges Start-up sicherlich gar kein großes Thema, da Legacy-Code quasi noch nicht wirklich existiert. Auf einer grünen Wiese zu starten, ist heute mit den vorhandenen Tools relativ simpel.

Für gewachsene IT-Systeme mit mehreren Dutzend eincheckenden Entwicklern, diversen Entwicklungsumgebungen, Programmiersprachen, Repositories, Branches, Staging-Servern und Co. ist die Automatisierung des „heiligen“ Release-Prozesses jedoch ein bisschen aufwendiger.

Umso wichtiger ist es, den Release-Prozess kompromisslos zu vereinheitlichen. Dies funktioniert auch hier nur mit Release-Manager, der ausschließlich an der Releasequalität sowie der Releasegeschwindigkeit gemessen wird. Kein leichtes Unterfangen, da die Faktoren Geschwindigkeit und Qualität sich in der Regel nicht besonders mögen. Aber genau dort liegt die Herausforderung für den übergreifenden Release-Manager.

Beitragsbild by qimono
https://pixabay.com/en/idea-empty-paper-pen-light-bulb-1876659/