Cloud-native ist ein Softwareansatz zum Erstellen, Bereitstellen und Verwalten moderner Anwendungen in Cloud-Computing-Umgebungen. Wer Cloud-native geht, verspricht sich höhere Innovationsfähigkeit und schnellere Anpassungsfrequenzen.
Viele zur Zeit populäre Themengebiete wie Team Topologies, aber auch bewährte Themenfelder wie Domain-driven Design (DDD) begrüßen grundsätzlich Cloud-native-Umgebungen.
Cloud-native Umgebungen und agile Arbeitsweisen scheinen gut zusammenzupassen. Doch ist das wirklich so?
Dieser Artikel geht der Frage nach, ob sich etwas in der agilen Arbeitsweise oder den Skillsets und der Aufgabengebiete der agilen Rollen (Product Owner, Scrum Master) verändern sollte.
Denn du möchtest ja das volle Innovations-Potenzial von Cloud-native für deine Organisation nutzen können.
Prinzipien und Reifegrade
Cloud-native zieht eine Weiterentwicklung der Arbeitsweisen nach sich.
Cloud-native verbindet fünf Prinzipien (Skalierbarkeit, Resilienz, Managebarkeit, Beobachtbarkeit, Automatisierung) für die Erstellung moderner Software-Anwendungen und fünf Reifegrade (Aufbau, Betrieb, Skalierung, Verbesserung, Optimierung) in Bezug auf mehrere Aspekte (Mitarbeiter, Prozesse, Richtlinien, Technologien, Geschäftsnutzen).
Für diesen Artikel möchte ich den Blick auf Mitarbeiter und Prozesse im Kontext von Agilität / agilem Arbeiten richten. Vielleicht wird ja eine kleine Serie daraus, denn das Thema ist noch nicht umfassend betrachtet worden – gib mir gerne Feedback, ob dir der Artikel weitergeholfen hat.
Auswirkungen von Cloud-native
Disziplinen wie DevOps und Techniken wie Continuous Delivery helfen, Software schneller bereit zu stellen und damit frühzeitiger Nutzerfeedback zu bekommen. Doch Cloud-native ist weit mehr als eine funktionierende CI/CD-Umgebung.
Cloud-native zu werden hat Auswirkungen. Am besten verdeutlicht das folgende Tabelle:
| Bereich | Agile | Cloud-native |
|---|---|---|
| Culture | Iterative | Collaborative |
| Product / Service Design | Feature-driven | Data-driven |
| Team | Cross-functional Teams | DevOps / SRE |
| Process | Agile (Scrum/Kanban) | Design Thinking + Agile + Lean |
| Architecture | Client-Server | Microservices |
| Maintenance | Altering | Full observability & self-healing |
| Delivery | Continuous Integration | Continuous Delivery |
| Provisioning | Konfigurations-Management | Orchestration (Kubernetes) |
| Infrastructure | VMs (einzelne Tiere) | Containers / hybrid cloud (Herde) |
In vielen agilen Umgebungen findet man eine ganze Reihe an Komponenten, die bereits in der „Cloud-native“-Spalte der Tabelle zu finden sind, so zum Beispiel Continuous Delivery oder Orchestrierung mittels Kubernetes.
Betrachten wir also die einzelnen Elemente, das Delta in der Veränderung und was das im agilen Kontext bedeuten kann. Grundsätzlich ist es wichtig, auch immer den eigenen (Organisations-)Kontext zu berücksichtigen. Denn nicht immer steckt in „DevOps“ das drin, was mit DevOps grundsätzlich gemeint ist.
Voraussetzungen, um Cloud-native zu werden
Wir schauen gezielt auf die Veränderungen in den Bereichen Kultur, Produkt/Service-Design, Team und Prozess. Und ziehen dann Schlüsse, welche Veränderungen auf die Rollen Scrum Master und Product Owner zukommen.
Denn: Cloud-native zieht eine Weiterentwicklung der Arbeitsweisen nach sich.
Kultur
Es gibt eine Veränderung von iterativer zu kollaborativer Arbeitsweise. Doch was ist damit gemeint?
In einer iterativ getriebenen Umgebung gibt es zum Beispiel regelmäßige Meetings und klar definierte Verantwortlichkeiten in einem Team. Bei Erfüllung eines Tasks findet eine Weitergabe an das nächste Team in der Produktions-Pipeline statt. Dies ist insbesondere bei Komponenten-Teams der Fall.
Beim Übergang zu einer Cloud-native Umgebung ist es wichtig, dass hier eine Veränderung in folgende Richtungen stattfindet:
- Es gibt breite high-level-Ziele. Die Teams finden selbst den besten Weg und die besten Feature-Ideen heraus, um diese Ziele zu erreichen. Der Fokus der Teams liegt darauf, kleine, selbst definierte Ziele schnell zu erreichen.
- Fehler, die in den Software-Systemen passieren, werden als Option gesehen. Dabei ist es wichtig, daraus zu lernen (beispielsweise mit Blameless Post Mortems).
- Gut zu wissen: Das Herausarbeiten und Realisieren eigener Ideen für das Produkt ist dabei auch ein Zeichen in Richtung einer „product-driven organization“, geleitet von den Zielen für das Produkt.
Produkt-/Service-Design
In einer iterativ getriebenen Umgebung fokussieren sich die Teams beim Produkt-/Service-Design auf feature-getriebene Entwicklung. Es gibt Produkt-Roadmaps, regelmäßige Feature-Releases bei hoher Zuverlässigkeit und Vorhersagbarkeit.
Scrum als Rahmenwerk ist in Cloud-native-Umgebungen überflüssig geworden.
Wer schon Richtung Cloud-native unterwegs ist, wird es vielleicht möglich machen können, dass auf Anfrage des Kunden (Nutzers) eingeplante Features unter Umständen vorgezogen werden können. Eben weil zum Beispiel neue Daten-Erkenntnisse eine frühere Lieferung dieser Funktion(en) notwendig machen.
Aber auch wenn ein Feature live gestellt wird, so stellen Teams im Monitoring fest, ob das Feature oder Release eine echte Verbesserung zum vorherigen Stand darstellen.
Team
Auch hier gibt es Veränderungen beim Weg in Richtung Cloud-native.
In einer agilen Umgebung gibt es cross-funktionale Teams. Möglicherweise muss noch ein Handoff Richtung Operations-Team gemacht werden, wenn neue Releases anstehen. Teams sind unabhängig voneinander. Innerhalb des Teams gibt es eine hohe soziale Dichte und wenig Austausch mit anderen Teams.
Cloud-native-Umgebungen führen dazu, dass das Team die Funktionen nicht nur entwickelt, sondern auch eigenständig live nimmt. Es gibt kein Handover mit separaten „Ops-Abteilungen“. Die Teams kommunizieren untereinander via APIs über die Public Cloud.
Team-Strukturen, wie wir sie aus dem Buch Team Topologies kennen, etablieren sich. Es gibt Plattform-Teams, die grundlegende Infrastruktur-Produkte im Selfservice für andere Teams bereitstellen.
Die soziale Dichte erhöht sich zwischen den Teams, es findet mehr Austausch statt. Gleichzeitig ist die hohe Unabhängigkeit und die Fähigkeit, eigene Features selbst live zu nehmen, sehr hoch ausgeprägt. Releases finden mehrfach am Tag oder in der Woche statt, da die Abhängigkeiten zu anderen Teams aufgehoben wurden.
Prozess
Wer kennt das nicht: In agilen, iterativen Umgebungen fokussieren wir uns auf die Lieferleistung von neuen Funktionen. Für das schnelle Beheben von Fehlern ist wenig Zeit. Hier sehen wir häufig auch Organisations-Strukturen und Stakeholder, die einen hohen Schwerpunkt auf das Liefern von Funktionen setzen. Schliesslich soll schnell geliefert werden.
Cloud-native ermöglicht eine Kultur, in der schnelles Experimentieren bevorzugt wird. Aufgrund der wenigen Abhängigkeiten und der hohen Selbst-Verantwortung für das Ausliefern von Funktionen / neuen Releases und der Nutzung von Cloud-technologien (Microservices, Functions) wird schnelles Experimentieren tatsächlich ermöglicht.
Scrum kommt aus einer Zeit, als es weder Continuous Delivery noch richtige Continuous Integration oder gar Microservices gab. Mit Cloud-native ist es Zeit, den Einsatz der eingesetzten Werkzeuge zu überdenken.
Wird Scrum nun überflüssig?
Es ist die Mischung aus Kulturveränderung, näher an die ursprüngliche DevOps-Kultur, der Reduktion bzw. Auflösung von Abhängigkeiten (hallo SAFe Framework!) und dem Einsatz moderner Technologien, die eine Veränderung im Prozess nach sich ziehen und so erst die volle Innovationskraft entfalten.
Es benötigt keine Standardisierung auf gemeinsame Prozesse oder übergeordnete Framework-Container wie z. B. SAFe. Die Teams arbeiten unterschiedlich und sind völlig frei in der Auswahl ihres Vorgehens.
Die Entwicklungsprozesse sind sehr stark automatisiert, so dass auch kleine Teams eine sehr hohe Wirkkraft haben.
Veränderungen für agile Rollen
Betrachte ich die bisherigen Veränderungen für die vorangegangenen Stages, so komme ich zum Schluss, dass sich einiges für agile Rollen ändern muss.
Mehr Tech-Know-how: Aus unseren Projekten, Consultings und Trainings wissen wir, dass sich bereits viele agile Rollen Tech-relevantes Know-how angeeignet haben, um in den Gesprächen im Team „mitspielen“ zu können.
Cloud-native beschleunigt diesen Wandel. Es reicht nicht mehr aus, von Microservices zu sprechen, ohne konkret zu wissen, was damit gemeint ist und welche technologischen Zusammenhänge bestehen.
Rahmenwerke wie Scrum werden in cloud-native-Umgebungen weniger genutzt. Denn dort, wo ich in der Lage bin zigfach am Tag auszuliefern, benötige ich den umgebenden Sprint-Container nicht mehr. Es findet ein Wandel hin zu Frameworks wie IT-Kanban oder andere, selbstorganisierte Varianten und eigene Team-Prozesse statt. Diese setzen den Fokus auf starker Automatisierung und hohe, experimentell-datengetriebene Vorgehensweisen.
Was nun folgt bedeutet nicht, dass Scrum Master und Product Owner programmieren können müssen!
Von Scrum Master …
Scrum Master werden sich hier anpassen müssen. Der etablierte Werkzeugkoffer von Methoden wird nicht mehr ausreichen. Die eigene Orientierung fällt zurück. Diese unterstützende Rolle wird in manchen Kontexten außerhalb des Teams wandern und sich darauf fokussieren, übergreifenden Austausch zu ermöglichen. Ein stärkerer Fokus auf Stakeholder-Management ist dabei ebenso wichtig wie die Fähigkeit, Teamübergreifend Kommunikation zu enablen.
Damit dieser übergreifende Austausch stattfinden kann und nicht „blind im Nebel“ herumgestochert wird, muss diese Rolle nicht nur das Cloud-native Vokabular beherrschen, sondern auch die Zusammenhänge verstehen und ein Gespür für die eingesetzten Technologien haben. IT ist anders – fachorientiert und -fokussiert.
Somit steigt die Akzeptanz der agilen Rolle, wenn hier „mitgeredet“ werden kann. Natürlich ist das auch in nicht-Cloud-native-Umgebungen sinnvoll.
Doch auf dem Weg nach Cloud-native bzw. in solchen Umgebungen sind diese Fähigkeiten essenziell, damit die agile Rolle des Scrum Masters (Flow Master, Agile Master, …) einen guten Wertbeitrag liefern kann.
… bis zum Product Owner
Als Product Owner benötige ich ebenfalls das Tech-Grundverständnis und die damit einhergehenden Zusammenhänge und Entwicklungen, um das volle Potenzial für das Produkt entfalten zu können.
Das bedeutet nicht nur ein entsprechendes Upskilling des Product Owners bezüglich Technologie. Sondern auch die stärkere Einbindung der Entwickler in die Product Discovery und Produkt-Strategie, um die Wertschöpfung für das Produkt weiter zu maximieren. Unser Training „Become a Product Leader“ geht genau auf solche Aspekte ein.
Gerade weil in Cloud-native Umgebungen eine sehr hohe Unabhängigkeit, mitunter völlig freie Technologie-Wahl in den einzelnen Teams, und starke Automatisierung vorherrscht, ist der Product Owner mehr denn je gefragt, den Rest des Teams stark in die Produkt-Strategie einzubinden.
Es ist sogar schon die Rede vom „AI Product Owner“, der völlig andere Fähigkeiten und Skills benötigt. Hierzu wird es noch einen separaten Beitrag geben.
Noch einmal: Das bedeutet nicht, dass Scrum Master und Product Owner programmieren können müssen!
Technologie-Verständnis ist jedoch ein weiterer Skill-Pfad, auf dem sich diese Rollen bewegen müssen, um die Wirkung zu maximieren und den Wandel mit zu ermöglichen.
Wird Scrum nun überflüssig?
Je intensiver ich mit mit dem Thema Cloud-native und seinen Auswirkungen auf agile Rollen auseinander setze, desto mehr komme ich zum Schluss:
Ja, Scrum als Rahmenwerk ist in Cloud-native-Umgebungen überflüssig geworden.
Was nicht überflüssig geworden ist, ist eine agile Arbeitsweise. Das bedeutet:
- Die Arbeit in Teams organisieren (flow efficiency)
- Visual Work Management (z. B. durch Kanban Boards)
- Je älter ein Workitem ist, desto mehr sollten wir uns die Frage stellen „Sollen wir das immer noch tun?“
- Cycle Time messen. Ist das Team glücklich damit? Ansonsten z. B. in einer Retro besprechen
- Weitere Elemente aus dem IT-Kanban hinzufügen: Replenishments häufiger als 2-wöchentliche Sprint-Planung
Agile Rollen wie Scrum Master wird es weiter geben. Vielleicht muss der Rollenname überdacht werden. Auf die Veränderung von Aufgaben und Skills bin ich bereits weiter oben eingegangen.
Zusammenfassend: Scrum kommt aus einer Zeit, als es weder Continuous Delivery noch richtige Continuous Integration, oder gar Microservices gab. Mit Cloud-native ist es Zeit, den Einsatz der eingesetzten Werkzeuge zu überdenken.
Noch mehr Anknüpfungspunkte
Auf unserer Themenseite zu Cloud-native haben wir dazu viele Informationen aus der technischen Seite dargestellt. Und wenn du Ende Juni Zeit hast: Am 22. Juni um 10:10 Uhr halte ich den Vortrag „Wie Cloud-native alles verändert“ auf dem Scrum Day 2023 in Filderstadt.
Melde dich doch einfach bei uns, und diskutiere mit uns deine Cloud-native Problemstellung.
Björn Schotte
#software #leadership #stakeholdermanagement
Ich bin Geschäftsführer der MAYFLOWER GmbH. Als Consultant und Techie berate ich Product Owner und (Top-)Management in Fragen der Digitalen / Agilen Transformation, helfe bei Leadership-Themen und coache und trainiere zu Themen wie OKR, Kanban, Product Leadership und Software-Modernisierung. Alles in Bezug zu guter Software-Architektur und Enablement in der Cloud.
Was sollte ich jetzt also tun?
Wenn du Scrum Master oder Product Owner bist: Werde dir bewusst, welche Veränderungen es in deiner Rolle benötigt. Sprich mit dem Team darüber. Mach dir in einer Selbsteinschätzung Gedanken dazu, wie dein Ist-Stand zum Beispiel in Bezug auf Technologie-Know-how ist.
Lightning Talks/Brownbag Sessions sollte es bereits in deinem Team geben: Dort ist die ideale Gelegenheit, dich zu diesen Themen aufschlauen zu lassen.
Wenn du in einer Führungsrolle bist und Scrum Master oder Product Owner führst, mach diese Thematik Gegenstand eurer regelmäßigen Checkins. Lass deinen direct report eine Selbsteinschätzung erstellen und diskutiert darüber, wie hier eine Weiterentwicklung stattfinden kann. Für Product Owner bietet sich auch das Product Owner Evolution Modell (POEM) oder das Product Flywheel an, bei dem zum Beispiel die Achse „technologische Fähigkeiten“ hinzugefügt werden kann.
Wir von MAYFLOWER sind im Herzen ein Tech-Unternehmen. Unsere Product Owner können im Rahmen des Product Owner as a Service dabei unterstützen, den Shift zu gehen. Wenn du vorerst nur ein Training möchtest, dann komm in das „Become a Product Leader“ Training.
Im Team mit unseren Consultants aus den Bereichen Product, Agile/Org und Cloud helfen wir Euch dabei, nicht nur organisatorisch nach Vorne zu kommen, sondern auch technologisch.
Schreibe einen Kommentar