Bode Das Triple-A Framework

Wie Scrum Master als Turbo für den Aktienkurs durchstarten
Erstauflage 2025
ISBN: 978-3-938277-10-2
Verlag: Trochos
Format: EPUB
Kopierschutz: 6 - ePub Watermark

E-Book, Deutsch, 220 Seiten

Aufbauend auf den klassischen Säulen des IT-Projektmanagements, allen voran dem Agilen Manifest von 2001 und Software Engineering von 1968, stellt das Triple-A Framework einen weiteren Meilenstein in dessen Entwicklung dar.

Software-Anforderungen sind seit der Jahrhundertwende rapide gewachsen und damit auch der Umfang und die Komplexität ihrer Entwicklung. Scrum Master werden zur treibenden Kraft hinter prosperierenden Marktführern und disruptiven Start-ups. Ob Sie eine erfolgreiche Führungskraft oder ein ambitionierter Neuling sind – dieses Buch ist Ihr Schlüssel zu Spitzenleistungen. Mit dem Triple-A Framework steigern Sie die Produktivität, forcieren Innovationen und senken die Kosten.

Die Softwareentwicklung gleicht heute einem Triathlon, der Kompetenzen in drei Disziplinen erfordert. Das Triple-A Framework vereint diese Elemente und bietet eine einheitliche und effektive Strategie für moderne IT-Landschaften:

• Automation: Beherrschung solider Prozesse, die Qualität und Produktivität auf ein neues Niveau heben.
• Agility: Entwicklung kundenorientierter Produktideen, um sich auf wechselnde Marktanforderungen einzustellen.
• Acting: Beschleunigung disruptiver Innovationen, um technologiegetrieben neue Märkte zu erschließen.

Jede Disziplin erfordert eine spezifische Kombination von Mindset, Methoden und Metriken. Triple-A vereint diese zu einem innovativen, ganzheitlichen Ansatz, der Unternehmen zu neuen Leistungsniveaus antreibt. Er befähigt Softwareteams, in einer zunehmend komplexeren Welt erfolgreich zu sein und die Agilitätskrise in eine Chance für den Fortschritt zu verwandeln. Herausforderungen werden als Katalysatoren für bahnbrechende Innovationen, dynamisches Wachstum und nachhaltigen Erfolg neu definiert.

Zielgruppe

Scrum Master, Developer, Product Owner und alle, die in der Softwareentwicklung tätig sind.

Autoren/Hrsg.

Bode, Ulrich

Leseproben

3 Automation First

Automatisierung bildet die Grundlage für agiles Arbeiten. Teams können nur dann innerhalb der kurzen Iterationen eines Sprints effektiv arbeiten, wenn sie sich auf eine funktionsfähige Automatisierung verlassen können.

Das erste „A“ in Triple-A steht daher für Automatisierung.

3.1. Automatisierung ist die Basis

Was für den Betrachter oft mühelos erscheint, ist in Wahrheit das Ergebnis harter Arbeit: Wenn eine Balletttänzerin anmutig über die Bühne schwebt, liegen unzählige Stunden intensiven Trainings hinter ihr. Begeistert eine Fußballmannschaft mit präzisen Ballstafetten, sind es perfekt einstudierte Spielzüge, die ihr Zusammenspiel so kunstvoll wirken lassen. Und wenn ein Geiger virtuos aufspielt, zeugt dies von jahrelanger, hingebungsvoller Übung. Wahre Meisterschaft gründet auf ausdauernder Routine.

Kata

Eine Kata ist eine Reihe von strukturierten Routinen oder Übungen, die darauf abzielen, die kontinuierliche Verbesserung (Kaizen) und die Beherrschung einer bestimmten Fähigkeit oder eines bestimmten Prozesses zu fördern.

Der Begriff „Kata“ stammt aus dem Japanischen und bedeutet „Form“ oder „Muster“. In der Kampfkunst bezeichnet Kata eine festgelegte Abfolge von Bewegungen, die gegen imaginäre Gegner ausgeführt werden.

Dave Thomas, Mitunterzeichner des Agilen Manifests, hat den Begriff in die Softwareentwicklung eingeführt. Auf codekata.com stellt er entsprechende Übungen zur Verfügung. Ziel ist es, Qualität durch praktische Übungen zu trainieren.

Routinen steigern die Effizienz und schaffen Kapazitäten für Innovationen. Routinen bilden das Fundament für Veränderung. Automatisierung bildet die Grundlage für Agilität.

Developer haben ihre Arbeitsprozesse schon immer rationalisiert, angefangen mit Compilern, Debuggern und Versionskontrollsystemen. Heute nutzen sie modellbasierte Entwicklung, Low Code, generative KI, Platform Engineering und andere Techniken, um die Entwicklung zu beschleunigen und den Aufwand zu minimieren. Dadurch gewinnen sie Zeit für wertschöpfende Innovationen.

3.1.1. Run and Change

Die Automatisierung einer Organisation beschränkt sich nicht nur auf die Softwareentwicklung, sondern kann auch menschliche Tätigkeiten umfassen. Beispielsweise ist die tägliche Buchführung in einer Buchhaltung eine Routinearbeit, die teilweise automatisiert und teilweise durch ein Personal umgesetzt wird. Ist eine Projektorganisation für die Buchhaltung sinnvoll?

Nicht für Routineaufgaben. Es macht keinen Sinn, für jeden Tag ein Ticket „Kreditoren buchen“ zu erstellen. Aber auch in der Buchhaltung gibt es Projekte: Eine neue Software wird eingeführt, Factoring soll genutzt werden oder neue steuerliche Regelungen führen zu Anpassungsbedarf. Für diese Veränderungsarbeit ist eine Projektorganisation sinnvoll. Dann wird das Rechnungswesen von einer Abteilung zu einem Projekt.

Ähnlich bei der Feuerwehr: Niemand käme auf die Idee bei einem Brand den Einsatz erst für den nächsten Sprint einzuplanen, sondern natürlich wird dieser sofort und „routinemäßig“ gelöscht. Wenn aber ein neues Feuerwehrfahrzeug beschafft wird, wenn Übungen und Schulungen durchgeführt werden oder neue gesetzliche Anforderungen umgesetzt werden, dann wird geplant und verändert.

Nicht in den Routinen liegt die Projektarbeit, sondern in der Arbeit an den Routinen. Diese Zweiteilung von Routine und Veränderung ist unter verschiedenen Begriffspaaren bekannt. Diese Begriffspaare stehen aber nicht nebeneinander oder getrennt, sondern bauen aufeinander auf. Die Beziehung zwischen den Begriffspaaren ist nicht horizontal, sondern vertikal.

Veränderung

Change

Transformation

Explore

Dynamik

Scrum

Routine

Run

Transaktion

Exploit

Stabilität

Kanban

3.1.2. Permanenter Wandel

Bimodalität folgt hingegen dem Prinzip „Kern und Peripherie“. Bimodalität meint, dass der Kern einer Organisation stabil ist, während die Peripherie agil arbeitet. Doch die bunte Außenwelt nützt nichts, wenn der träge Kern nicht in der Lage ist, auf radikale Marktveränderungen zu reagieren. Wenn ganze Geschäftsmodelle in kurzer Zeit nicht mehr tragfähig sind, muss sich die ganze Organisation verändern und anpassen, allen voran der Kern. Bimodalität ist keine gute Idee.

Vielmehr muss auch die Linienorganisation in eine Projektorganisation umgewandelt und in einen agilen Rahmen integriert werden. Veränderung wird nicht mehr durch Change-Management von Zeit zu Zeit durchgeführt, sondern durch den agilen Rahmen als permanenter Wandel umgesetzt. Der seltene extrinsische Wandel wird zum permanenten intrinsischen Wandel.

Agile Methoden sind auf Anpassungsfähigkeit ausgelegt. Sie bilden daher auch für Routinetätigkeiten einen Rahmen, um Veränderungen jederzeit strukturiert und kontinuierlich umsetzen zu können. Agilität ist Routine für Veränderung.

3.1.3. Kanban und Scrum

Ein Team kann zwei verschiedene Arbeitsmethoden nutzen. Einerseits Scrum für die Entwicklungsaufgaben und die Arbeit an den Routinen. Auf der anderen Seite Kanban für die Fallbearbeitung. Beide Ansätze können parallel genutzt und effektiv kombiniert werden.11

Handelt es sich überwiegend um Entwicklungstätigkeiten mit Scrum als Basis, dann wird im Sprint entsprechend Zeit für die Fallbearbeitung reserviert. Die einzelnen Fälle, z. B. Bugs, werden direkt ins Sprint Backlog aufgenommen und mit höchster Priorität behandelt.

Ein Team, das für Softwareentwicklung und Support zuständig ist, wird neben dem Sprint Backlog auch ein Kanban-Board für den Support führen und eine Priorisierungsregel definieren, z. B. „Support First“.

Dominiert dagegen die Fallbearbeitung, dann ist Kanban die vorherrschende Methode. Wenn auch Projektarbeit erforderlich ist, kann Scrum wie bereits beschrieben ergänzend eingesetzt werden.

3.1.4. Von DevOps zu Opsless

Nicht nur Product Owner und Scrum Master können Aufgaben delegieren, sondern auch Developer. Sie delegieren nicht an Menschen, sondern an Systeme. Die Automatisierung der gesamten Pipeline ist eine Kernaufgabe der Entwicklung und Grundlage für agiles Arbeiten. Idee und Konzept von DevOps wurde nach dem Agilen Manifest und Scrum geboren (2009). Was früher manuell vom IT-Betrieb erledigt wurde, wird heute unter dem Begriff DevOps von den Developern selbst erledigt.

Ursprünglich zielte DevOps darauf ab, die Kluft zwischen Entwicklung (Development) und Betrieb (Operations) zu überbrücken und eine nahtlose Zusammenarbeit beider Seiten zu fördern. Als die Idee von DevOps aufkam, nahm gleichzeitig die Cloud-Revolution an Fahrt auf. Anfangs boten Cloud-Anbieter lediglich Rechenkapazität an, doch schon bald erweiterten sie ihr Portfolio um Serverless Computing. Damit entfiel für Dev und Ops die Notwendigkeit, sich um das Server-Management zu kümmern. Doch die Entwicklung ging weiter: Heute liefert die Cloud den Systembetrieb so selbstverständlich wie Strom aus der Steckdose. Aus Entwicklungssicht ist der Betrieb nicht nur Serverless, sondern auch Opsless.

You Build It, You Own It, You Run It.

Die Verantwortung für den Applikationsbetrieb liegt nun vollständig in den Händen der Developer. Aus der horizontalen Trennung von Entwicklung und Betrieb (DevOps) ist eine vertikale Trennung von Applikation und System geworden. Bei „AppSys“ geht es darum, die Schnittstelle zwischen Applikations- und Systembetrieb für die Anwendungsentwicklung so einfach wie Autofahren zu machen (Platform Engineering).

Site Reliability

Das Konzept Site Reliability Engineering (SRE) überträgt die Prinzipien und Praktiken aus der Entwicklung auf den Systembetrieb. Im Kontext von DevOps hat die Entwicklung den Anwendungsbetrieb übernommen und wendet dort bereits Praktiken der Softwareentwicklung zur Automatisierung an. Der Systembetrieb, als Unterbau des Anwendungsbetriebs, profitiert ebenfalls von Automatisierung, um Zuverlässigkeit und Skalierbarkeit zu erhöhen.

Der Trend geht dahin, dass die Softwareentwicklung die volle Verantwortung für den gesamten Lebenszyklus übernimmt – von der Entwicklung über die Produktion bis hin zum Betrieb der Anwendung. Dazu steht der Systembetrieb als Service für die Anwendungsentwicklung zur Verfügung. Die Ops-Funktion existiert also weiterhin und wird von einem Plattform-Team bereitgestellt. Der entscheidende Unterschied ist, dass Ops für das Anwendungsentwicklungsteam nicht mehr sichtbar ist – es ist Opsless.

Der Big Bang

„Infrastructure as Code“ bezeichnet die automatisierte Einrichtung und Verwaltung von Softwaresystemen durch...

Über Autor(innen)

Bode, Ulrich
Der Autor Ulrich Bode ist Informatiker und seit vielen Jahren als Berater in Branchen wie Automotive, Handel, Finanzdienstleister und öffentliche Verwaltung tätig. Ulrich Bode ist Fellow der Gesellschaft für Informatik.