Allgemein – atra.consulting –

stackconf 2026: End Release Anxiety

Daniel Schock — Tue, 14 Apr 2026 14:54:50 +0000

Release Anxiety ist kein Naturgesetz

Freitag, 16:47 Uhr. Ein Pull Request mit einem kritischen Fix landet auf dem Tisch. Und plötzlich diese leise Frage im Hinterkopf: „Machen wir das wirklich noch vor dem Wochenende?”

Release Anxiety ist erstaunlich verbreitet. Nicht weil Teams unfähig wären — sondern weil Prozesse es sind. Manuelle Checklisten, Nachtdeployments, halbautomatische Pipelines und Changelogs, die „irgendwie” entstehen, machen Releases zu kleinen Events. Dabei sollten sie Routine sein.

Daniel Schock auf der stackconf 2026

Auf der stackconf 2026 spricht unser Kollege Daniel Schock genau darüber: „End Release Anxiety: A Guide to Fully Automated Workflows with Semantic Release”.

Es geht nicht um Tool-Evangelismus, sondern um die Transformation eines subjektiven, nervösen Rituals in einen reproduzierbaren, automatisierten Workflow.

Themen der stackconf

Die stackconf bringt Expertinnen und Experten aus dem gesamten Cloud-native- und DevOps-Ökosystem zusammen. Die Themenlandschaft spiegelt die aktuellen Herausforderungen moderner Infrastruktur:

Cloud-native Plattformen & Kubernetes

Container-Orchestrierung, Plattform-Engineering und Cloud-native Architekturen.

CI/CD & Automatisierung

Deployment-Pipelines, Release-Automatisierung und Infrastructure as Code.

Observability & Metriken

Monitoring, Tracing und datengetriebene Entscheidungen im Betrieb.

Sicherheit & Zero Trust

Security by Design, Supply Chain Security und Zero-Trust-Architekturen.

KI im Kontext von Infrastruktur & DevOps

Intelligente Automatisierung und KI-gestützte Betriebsprozesse.

Nachhaltige Systemarchitekturen

Langlebige, wartbare und ressourcenschonende Systeme.

Veranstaltungsort und Termin

Die stackconf 2026 findet am 28. und 29. April im Studio Balan in München statt. atra ist als Sponsor dabei.

Daniel Schock

Senior Software Engineer

Daniel ist ein erfahrener Fullstack-Entwickler und DevOps-Spezialist mit einem klaren Schwerpunkt auf der Backend-Entwicklung mit Java und Kotlin. Seine Expertise wird durch praktische Erfahrung in der Frontend-Entwicklung mit Vue.js abgerundet. Er verfügt über umfassende Kenntnisse in der Konzeption von CI/CD-Pipelines sowie im Einsatz von Cloud-Technologien wie Kubernetes und AWS, die er erfolgreich in den Branchen Versicherung, Logistik und E-Commerce einsetzte. Daniel arbeitet bevorzugt in agilen Umgebungen und zeichnet sich durch seine analytische Denkweise und hohe Problemlösungskompetenz aus.

d.schock@atra.consulting

Integral Facilitation – Warum echte Veränderung dort beginnt, wo Methoden enden

Johannes Uske — Thu, 09 Apr 2026 09:19:33 +0000

Warum scheitern so viele gut gemeinte Change-Initiativen?

Warum scheitern so viele gut gemeinte Change-Initiativen trotz exzellenter Methoden, Tools und Roadmaps?

Weil sie meist nur einen Teil des Systems adressieren:

Prozesse oder Menschen.
Strukturen oder Kultur.

In der Realität wirken diese Aspekte jedoch immer gleichzeitig – und genau dort entstehen Reibung, Überlastung und Stillstand.

Veränderung scheitert selten an fehlender Kompetenz.
Sie scheitert daran, wie Arbeit organisiert ist, wie Entscheidungen zustande kommen, wie mit Abhängigkeiten umgegangen wird – und wie Teams mit Spannungen umgehen, die aus Komplexität ganz natürlich entstehen.

Integral Facilitation setzt genau an diesem Punkt an.

Worum es bei Integral Facilitation wirklich geht

Integral Facilitation ist kein neues Toolset und keine Ersatzmethode.
Es ist ein Arbeitsansatz, um Veränderung dort wirksam zu machen, wo sie tatsächlich entsteht: in der Zusammenarbeit realer Teams unter realen Bedingungen.

Im Kern macht Integral Facilitation sichtbar und bearbeitbar, was in Veränderungsprozessen ohnehin wirkt – aber selten bewusst gestaltet wird:

Innere Dimensionen
Wie Menschen denken, priorisieren, Sinn erkennen oder Widerstand entwickeln.

Äußere Dimensionen
Meetings, Entscheidungswege, Prozesse, Artefakte, konkrete Ergebnisse.

Individuelle Perspektiven
Verantwortung, Führung, Selbstorganisation, Rollenverständnis.

Kollektive Dynamiken
Teamkultur, unausgesprochene Regeln, Konfliktmuster, Zusammenarbeit über Schnittstellen hinweg.

Die Wirkung entsteht nicht durch zusätzliche Reflexion, sondern dadurch, dass diese Ebenen miteinander in Beziehung gesetzt werden. So entsteht kollektive Handlungsfähigkeit – auch unter Druck, auch bei widersprüchlichen Anforderungen.

Einordnung im Vergleich zu Beratung und Change

Klassische Beratung	Klassischer Change	Integral Facilitation
Experten liefern Analysen und Empfehlungen	Vorgehensmodelle und Maßnahmen werden eingeführt	Entwicklung von Zusammenarbeit wird ermöglicht
Fokus auf Struktur, Prozesse, Konzepte	Fokus auf Verhalten und Umsetzung	Fokus auf Denk- und Handlungsmuster im Arbeitsalltag
Steuerung überwiegend von außen	Veränderung meist top-down	Verantwortung entsteht im Team
Effizienz und Optimierung	Akzeptanz und Umsetzung sichern	Kollektive Handlungsfähigkeit stärken
Wirksam bei klaren Problemstellungen	Wirksam bei planbaren Veränderungen	Wirksam bei Komplexität und widersprüchlichen Anforderungen

Integral Facilitation ist kein Ersatz dieser Ansätze, sondern ergänzt sie dort, wo Komplexität nicht mehr sauber zerlegt werden kann und Zusammenarbeit selbst zum entscheidenden Erfolgsfaktor wird.

Eine praktische Orientierung für deinen Arbeitsalltag

Wenn du in komplexen Situationen feststeckst, hilft es, bewusst aus unterschiedlichen Blickwinkeln auf die gleiche Situation zu schauen.

Nicht, um mehr zu analysieren – sondern um schneller zu erkennen, wo du wirklich ansetzen kannst.

Vier Perspektiven haben sich dabei als besonders hilfreich erwiesen:

Innere Sicht
Was nehmen Menschen gerade wahr?
Welche Erwartungen, Spannungen oder Überlastungen sind spürbar?

Äußere Sicht
Was passiert konkret im Arbeitsalltag?
Wie laufen Meetings, Entscheidungen und Abstimmungen tatsächlich ab?

Team-Logik
Welche unausgesprochenen Regeln prägen die Zusammenarbeit?
Was „funktioniert hier einfach so“, ohne dass es je vereinbart wurde?

System-Logik
Welche Strukturen wirken im Hintergrund?
Rollen, Abhängigkeiten, KPIs, Schnittstellen – was verstärkt das aktuelle Verhalten?

Der entscheidende Unterschied: Viele Ansätze bleiben auf einer dieser Ebenen stehen.
Hier geht es darum, sie bewusst zusammen zu betrachten.

Erst dadurch wird sichtbar, warum Probleme stabil bleiben – und wo Veränderung mit möglichst wenig Aufwand ansetzen kann.

Mini-Fallgeschichte aus der Praxis

Ein Team beschreibt seine Situation so:
„Wir springen ständig zwischen Themen und kommen nicht wirklich voran.“

Innere Sicht: Gefühl von Überlastung und fehlender Klarheit
Äußere Sicht: viele parallele Themen, häufige Unterbrechungen
Team-Logik: „Alles ist wichtig“ – niemand priorisiert klar
System-Logik: viele Stakeholder, ungefilterte Anforderungen von außen

Teamgröße: 12 Personen
Branche: Versicherungsumfeld
Kontext: international, Englisch als Arbeitssprache

Das Team verantwortet parallel:

stabile Run- und Maintenance-Aufgaben
kontinuierliche Weiterentwicklung
akute Produktionsprobleme

Die fachlich stärksten Entwickler werden regelmäßig aus der Entwicklung gezogen, um Incidents zu lösen. Gleichzeitig gibt es viele Ansprechpartner, zahlreiche Abhängigkeiten und regelmäßige Einwürfe „von links“ – fachlich wie organisatorisch.

Der fachliche Kontext ist komplex, die Fluktuation vergleichsweise hoch, Einarbeitungszeiten sind lang. Durch die internationale Zusammenarbeit reduziert sich zudem die fachliche Tiefe in Diskussionen – nicht aus Unwillen, sondern aus pragmatischer Sprachökonomie.

Die Folgen im Alltag:

Meetings werden zunehmend als Belastung erlebt
Veränderung wird eher defensiv betrachtet
Gute Ideen bleiben liegen, weil Zeit und Fokus fehlen
Einzelne Schlüsselpersonen tragen einen Großteil des Produktionsdrucks

Der entscheidende Punkt ist:

Das Problem liegt nicht nur in der Planung – sondern im Zusammenspiel der genannten Ebenen und Perspektiven. Deshalb setzten wir nicht bei neuen Prozessen an, sondern bei der Art der Zusammenarbeit.

Wie konkret angesetzt wurde

Produktionsarbeit genutzt, um Last zu verteilen und Kompetenz aufzubauen
Produktionsprobleme bleiben Priorität – aber nicht mehr Aufgabe einzelner Schlüsselpersonen. Mehr Entwickler wurden gezielt in Analyse und Lösungsfindung eingebunden – nicht nur zur Entlastung, sondern als bewusster Teil des Kompetenzaufbaus.

Priorisierung im Moment geklärt – auch gegenüber Stakeholdern
Backlog und Struktur waren vorhanden. Entscheidend war, Priorisierung im Alltag bewusst zu machen. Neue oder eskalierende Themen wurden aktiv rückgekoppelt: Was bedeutet diese neue Priorität konkret – und was wird dafür verschoben?
Diese Klärung wurde auch gegenüber Stakeholdern eingefordert.

Schnittstellen klarer statt schneller gemacht
Bei vielen Abhängigkeiten wurde nicht versucht, alles sofort zu klären.
Stattdessen wurde bewusst unterschieden: Was gehört in unseren Verantwortungsbereich – und was nicht?
Dabei ging es nicht um Abgrenzung, um der Abgrenzung willen, sondern um ein klareres, verlässlicheres Zusammenspiel.

Fokuszeiten aktiv geschützt
Fokus wurde nicht dem Zufall überlassen, sondern bewusst gestaltet.
Es wurde klarer vereinbart, wann Abstimmung notwendig ist – und wann konzentriertes Arbeiten Vorrang hat.

Was sich dadurch verändert hat

Produktionsdruck verteilt sich auf mehrere Schultern
Prioritäten werden bewusster entschieden statt implizit gelebt
Schnittstellen verursachen weniger Reibung
Wissen wächst im Team statt bei Einzelnen
Fokuszeiten werden wirksam – nicht nur geplant

Das Ergebnis:

weniger Kontextwechsel
spürbar weniger Frustration
bessere Planbarkeit trotz gleichbleibender Komplexität

Die Fragen, die uns geholfen haben und die Du gleich in Deinem Team stellen könntest, um ähnliche Ergebnisse erzielen, sind die folgenden:

Fragen, die Wirkung freilegen

Wo optimieren wir Symptome, statt Zusammenarbeit zu gestalten?
Welche Probleme tauchen immer wieder auf – unabhängig vom Toolset?
Welche Spannungen sind systemisch – und welche machen wir unnötig persönlich?
Wo liegt der kleinste Hebel mit der größten Wirkung?

Veränderung beginnt dort, wo Zusammenarbeit bewusst gestaltet wird

Integral Facilitation ist keine Technik, die man einführt. Es ist eine Haltung zur Gestaltung von Zusammenarbeit in komplexen Umfeldern – und die Bereitschaft, mehrschichtig zu denken und zu handeln.

Spannungen, Widerstände und Reibung werden dabei nicht als Störung gesehen, sondern als Hinweis darauf, wo Entwicklung möglich ist.

Vielleicht ist der nächste Schritt kein neues Tool oder eine bessere KI.
Vielleicht ist es ein anderes Gespräch im Team. Oder der Mut, eine der Fragen aus diesem Artikel gemeinsam anzugehen.

Nicht, um schneller oder effizienter zu werden. Sondern um wirksamer zusammenzuarbeiten.

Dort beginnt Veränderung, die den Kern der Herausforderungen adressiert und nachhaltig wirkt.

Was wäre möglich, wenn Du das in deinem Umfeld einfach einmal ausprobierst?

Johannes Uske

Agile Master

Johannes ist ein erfahrener Agile Coach. Er bringt umfassende Erfahrungen in Transformationen, Scrum, SAFe und Teamentwicklung in den Bereichen IT, Konsumgüter, Banking und Automobil mit. Sein Fokus liegt auf praxisnahen Trainings, Führungskräfte-Coaching und systemischer Beratung, die nachhaltige Veränderungen und Selbstorganisation fördern. Durch den Einsatz partizipativer Methoden beseitigt er Blockaden und steigert den Teamerfolg. Johannes legt besonderen Wert auf psychologische Sicherheit, Produktqualität, Kundenzufriedenheit, Wertschätzung und kontinuierliche Verbesserung – und stärkt so Teams, um ihre Kollaboration zu optimieren.

j.uske@atra.consulting

c’t webdev conference 2025

Timo Kaiser — Fri, 19 Dec 2025 10:51:58 +0000

Zwei Tage voller Frontend-Tiefgang in Köln

Die Webentwicklung verändert sich rasant – aktuell vor allem durch neue Frontend-Paradigmen und den zunehmenden Einsatz von AI-gestütztem Coding. Genau deshalb war die c’t webdev conference Mitte November im KOMED im MediaPark in Köln für mich mehr als nur ein Pflichttermin.

Zwei Tage lang trafen sich dort Frontend-Entwickler:innen, die sich intensiv mit Themen wie UI/UX, modernen JavaScript-Frameworks und neuen Ansätzen wie Vibe Coding und AI Agents beschäftigten. Der klare fachliche Fokus, die Tiefe der Vorträge und der direkte Austausch auf Augenhöhe machten schnell klar: Die Konferenz richtet sich nicht an Neugierige, sondern an echte Praktiker:innen. Die Organisation war top und das Catering im KOMED hervorragend – ideale Voraussetzungen für konzentriertes Networking und Lernen.

Doch was die c’t webdev wirklich auszeichnet, war die spezifische Zielgruppe: Es handelte sich um eine klare Frontend-Konferenz. Das Publikum war tief in den Themen UI/UX, Coding mit AI Agents, Vibe Coding und den aktuellen JavaScript-Frameworks (React, Angular, Vue) verwurzelt. Hier traf man auf gleichgesinnte Frauen und Männer, die nicht nur auf der Suche nach Inspiration waren, sondern auch den tiefen fachlichen Austausch suchten. Der Vibe stimmte sofort, was eine ideale Basis für die kommenden Vorträge legte.

Tag 1: Über AI Autopilots, Architektur und granularem State-Management

Keynote: Von Copilot zu Autopilot

Der Tag begann mit einer fesselnden Keynote von Daniel Sogl, der uns mitnahm auf die Reise „From Copilot to Autopilot – How AI Coding Tools Are Transforming the Developer Role“. Der Vortrag war mehr als eine Bestandsaufnahme; er war eine Aufforderung, die neue Realität kritisch zu hinterfragen.

Sogl präsentierte eindrucksvolle Statistiken zur Adoption von AI-Tools, wobei 84 % der Entwickler sie bereits nutzen oder planen zu nutzen, und 51 % sie täglich verwenden. Diese Tools versprechen echte Produktivitätssteigerungen, wie z. B. eine um 55,8 % schnellere Aufgabenerledigung in kontrollierten Studien und eine Reduzierung der täglichen Arbeitszeit um 56 Minuten.

Der zentrale Weckruf kam mit dem Trust Paradox: Während Syntax-Fehler dank AI um bis zu 76 % reduziert werden, steigt das Risiko für tiefer liegende, architektonische Probleme signifikant an. Berechtigungsprobleme (+322 %) und Architekturmängel (+153 %) sind laut Sogl keine Seltenheit. Diese Zahlen haben mich am meisten überrascht und bestätigen meine Skepsis: AI erzeugt „saubereren“ Code, verleitet aber zur Vernachlässigung der architektonischen Kontrolle.

Die Quintessenz des Vortrags: Die Entwicklerrolle wandelt sich vom reinen Coder zum Orchestrator und Strategen. Die Zukunft liegt in der Spec-Driven Development (SDD), bei der wir die Spezifikationen klar vorgeben, bevor die AI den Code generiert. Genau hier liegt für mich eine der großen Herausforderungen der nächsten Jahre: Wir müssen uns stärker als je zuvor auf die architektonische Planung und saubere Anforderungsanalyse konzentrieren, um die AI als präzises Werkzeug zu führen, statt uns von ihren zufälligen ‚Vibes‘ treiben zu lassen.

Das Highlight von Tag 1: Signals in Depth

Nach der strategischen Keynote, die den Rahmen für die Zukunft der Entwicklerrolle setzte, tauchten wir am späten Vormittag tief in die Frontend-Architektur ein. Mein persönliches Highlight von Tag 1 war ein Vortrag, der zeigte, wie die modernen Frameworks das Kernproblem der Webentwicklung – die Reaktivität – endlich effizient lösen: „Signals in Depth – How reactivity works in many frontend frameworks“ von Garrelt Mock.

Mock erklärte anschaulich die Schwächen traditioneller Reaktivitätsansätze: das „Dirty Checking“ (bekannt aus älteren Angular-Versionen mittels Zone.js) und das Virtual DOM (VDOM) Diffing in React. Diese Methoden, obwohl funktional, verursachen oft Performance-Overhead und unnötige Rechenzyklen, da unnötig große Teile der Komponenten neu gerendert werden, selbst wenn sich nur ein kleiner Datenpunkt geändert hat.

Die Lösung liegt in Signals, die auf einem granularen Observer-Pattern basieren: Ein Signal weiß genau, welche UI-Teile oder Effekte von ihm abhängen. Bei einer Änderung wird nur dieser spezifische abhängige Effect aktualisiert, nicht die gesamte Komponente.

Für mich war dieser Vortrag die wichtigste technische Erkenntnis des Tages. Die Eleganz und Effizienz, mit der Signals die Notwendigkeit für komplexe Mechanismen wie Zone.js oder VDOM-Diffing eliminieren und Frameworks wie SolidJS, Preact und das neue Angular schneller und speichereffizienter machen, ist ein klarer Hinweis auf einen Paradigmenwechsel im State-Management. Die Frontend-Architektur wird sich dadurch grundlegend vereinfachen – ein Muss für jede skalierbare Anwendung in den kommenden Jahren.

Der Rest des ersten Tages: Von AI-Agents bis zur Frontend-Architektur

Neben Keynote und Signal-Tiefgang bot der erste Konferenztag eine spannende Bandbreite an Themen, die die aktuellen Herausforderungen und Trends in der Frontend-Welt widerspiegelten.

AI-Driven Development: Sebastian Springer beleuchtete in seiner Session „AI Agents Beyond Simple Chatbots“ die Entwicklung komplexer, autonomer AI-Lösungen und proaktiver Assistentensysteme, die weit über einfache LLM-Chat-Interfaces hinausgehen. Er zeigte Frameworks wie LangChain, mit denen man AI-Agents befähigen kann, reale Probleme zu lösen und mehrstufige Workflows zu automatisieren.

Architektur und Skalierung: Der Vercel-Partner-Talk „From Monolith to Microfrontends: Choosing the Right Architecture…“ von Yi Min Yang lieferte einen praktischen Leitfaden zu modernen Frontend-Architektur-Patterns. Er diskutierte alles von Monorepos (z.B. mit Turborepo) bis Microfrontends und präsentierte ein klares Entscheidungs-Framework, um die passende Architektur für Teamgröße und technische Anforderungen zu finden. Sehr interessant zu sehen, wie man auch step-by-step Architekturen modernisieren kann.

Qualität und Metriken: Richard Gross erklärte unter dem Titel „Making sense of frontend code with forensic techniques“, wie man mithilfe von Tools wie CodeCharta und CodeGraph die Code-Qualität und Architektur in Projekten mit hunderttausenden Zeilen analysiert. Darüber hinaus zeigte Eva Feigl in „Beyond clicks: Measuring UX, outcomes and real product success“ auf, wie man Produkt-Telemetrie und qualitative Nutzerforschung kombiniert, um wirklich verwertbare UX-Metriken zu erhalten und den Produkterfolg zu validieren.

Tag 2: Menschliche Empathie und AI-Strenge

Keynote: Nobody needs UX – Die Unverzichtbarkeit der Empathie

Der zweite Konferenztag begann mit einer provokanten und nachdenklich stimmenden Keynote von Vicky Pirker mit dem Titel „Nobody needs UX“.

Pirker nutzte diesen vermeintlich paradoxen Titel, um die Essenz von User Experience (UX) in Zeiten der schnellen AI-Entwicklung neu zu definieren: Es braucht nicht den Begriff UX, sondern die menschliche Haltung dahinter. Schlechte UX führt zu Frustration und Ablehnung, wie sie eindrücklich zeigte.

Besonders relevant war die Diskussion im Kontext der AI-Revolution. Ihre klare Schlussfolgerung: User Experience bleibt menschzentriert, und KI dient lediglich als unser Sidekick. Die Aufgabe der Entwickler und Designer ist es, die Vision zu formen und die Nutzer zu begeistern.

Für mich war der Fokus auf die Empathie der wichtigste Takeaway. Während KI gut darin ist, bekannte UX-Schemata und Design-Regeln zu erlernen und perfekt umzusetzen, bleibt die Fähigkeit, sich tief in den User hineinzufühlen – also die Wünsche und emotionalen Reaktionen vorherzusehen – eine zutiefst menschliche Leistung. Dieser Mangel an Empathie kann aber zum Problem werden, wenn KI versucht, UX komplett zu übernehmen. Daher muss die menschliche Perspektive, die qualitative Nutzerforschung und Empathie stets die letzte Kontrollinstanz bleiben.

Das Highlight von Tag 2: EXACT Coding gegen den „Vibe“

Die Keynote von Vicky Pirker stellte klar: Der Mensch muss die ethische und empathische Kontrolle behalten. Der darauf folgende Vortrag „AI-Powered Development Vibe Code Doesn’t Work!“ von Marco Emrich und Ferdinand Ade lieferte die technische Methodik dazu. Sie äußerten eine klare Kritik am unstrukturierten „Vibe Coding“ (generieren, akzeptieren, nicht prüfen) und belegten, dass dieser Ansatz – obwohl schnell – zu unsauberen und unsicheren Codebasen führt.

Ich sehe Vibe Coding als einen effizienten Weg für schnelles Prototyping und Proof-of-Concepts; man erhält in kürzester Zeit gute, lauffähige Ergebnisse. Doch für Production-Ready Code ist dieser Ansatz meiner Meinung nach untauglich.

Die Lösung der Sprecher war EXACT Coding, ein Ansatz, der die besten Seiten der AI mit der Disziplin etablierter Methoden kombiniert. EXACT Coding basiert auf EXample-Guided Ai-CollaboraTive.

Das ist die Essenz für professionelle Softwareentwicklung: Bevor die AI überhaupt mit dem Codieren beginnt, müssen wir als Software Engineers in unseren Teams die Anforderungen und Spezifikationen klar erfassen und visualisieren. Der Mensch (Human-in-the-Loop) definiert das „Was“ durch die Beispiele und Tests; die AI übernimmt die Implementierung.

Der größte Vorteil dieser Methodik ist die Qualitätssicherung der Architektur: Indem wir uns zuerst auf Spezifikationen und die „Red“-Phase des TDD-Zyklus konzentrieren, zwingen wir die KI, in einem engen, validierten Rahmen zu arbeiten. Das beugt nicht nur Syntaxfehlern vor, sondern verhindert auch das Auseinanderdriften von Code und Gesamtarchitektur. Nur so stellen wir sicher, dass wir nicht nur Code schreiben, sondern nachhaltige, wartbare Software entwickeln und dabei niemals das große Ganze aus dem Auge verlieren.

Weitere Highlights an Tag 2: Reaktivität, Testing und Agenten-Interfaces

Auch abseits der Keynote und des AI-Vortrags lieferte Tag 2 wertvolle Inhalte, die sich tief mit den technischen Details der modernen Frontend-Entwicklung beschäftigten:

Standardisierung von AI-Interfaces: Max Marschall stellte in seinem Vortrag „AG-UI & MCP: Standardizing Agentic Web Interfaces“ zwei neue Protokolle vor: AG-UI (Agent-User Interaction Protocol) und MCP (Model Context Protocol). Diese zielen darauf ab, die Interaktion zwischen intelligenten Agents und modernen Web-Frontends zu standardisieren und modularer, testbarer und verständlicher zu gestalten.

Test-Qualität: Marco Emrich leitete die interaktive Session „How valuable are your tests?“. Er präsentierte die „Four Pillars of a Good Test“ von Vladimir Khorikov, um Kriterien für eine objektive Bewertung des Nutzens von Tests zu schaffen und so eine fundierte Diskussion über Teststrategien zu ermöglichen.

Accessibility in Komponenten: Und natürlich das beinahe-Highlight „Accessible Web Components“ von Anna Maier. Sie lieferte einen wichtigen Einblick, wie man technische Fallstricke des Shadow DOM vermeidet, um die Barrierefreiheit von Komponenten von Anfang an zu gewährleisten, und betonte die Notwendigkeit, dies auch im Produktkontext zu testen und zu dokumentieren.

Fazit: Eine lohnende Investition in die Frontend-Zukunft

Die zwei Tage auf der c’t webdev conference im Kölner MediaPark waren für mich eine absolut lohnende Investition. Die Konferenz lieferte nicht nur einen umfassenden Überblick über die aktuellen Tools und Frameworks (von Signals bis React Fullstack), sondern beleuchtete vor allem die strategischen und methodischen Herausforderungen der Branche. Der Fokus lag klar auf der Zukunft der Entwicklerrolle: Wir bewegen uns vom reinen Code-Schreiber hin zum Orchestrator, der AI strukturiert einsetzt und dabei die menschliche Urteilsfähigkeit (Human Judgement) behält.

Die wichtigste Erkenntnis: Der Mensch bleibt die Kontrollinstanz

Die entscheidenden Takeaways liegen für mich in der methodischen Disziplin und Empathie. Wir haben gelernt, dass wir AI nicht blind vertrauen dürfen (Stichwort: Trust Paradox bei Architekturmängeln), sondern dass unser menschliches Urteilsvermögen und die Fähigkeit zur Empathie die unverzichtbaren Kontrollinstanzen bleiben.

Networking und Empfehlung

Abgesehen vom Inhalt war die Atmosphäre auf der Konferenz herausragend. Die Teilnehmer:innen waren sehr freundlich und offen für einen fachlichen Austausch, was das Networking sehr erleichtert hat.

Ich kann die c’t webdev conference definitiv uneingeschränkt weiterempfehlen, da sie wertvolle Beiträge und tiefgreifende Infos aus der Tech-Branche im Bereich Frontend liefert. Die Konferenz richtet sich an diejenigen, die wissen wollen, wie man die Zukunft baut, nicht nur, wie man sie benutzt. Ob ich im nächsten Jahr wieder dabei bin, steht noch offen – schließlich soll man als Entwickler auch mal über den Tellerrand hinausschauen. Aber die Impulse aus Köln sind gesetzt und werden meine Arbeit nachhaltig prägen.

Timo Kaiser

Senior Software Engineer

Timo ist ein erfahrener Webentwickler mit über 15 Jahren Projekterfahrung, insbesondere in der Umsetzung moderner, barrierefreier Frontends auf Basis von Angular, TypeScript, HTML und SCSS. Sein Schwerpunkt liegt auf der Entwicklung skalierbarer, wartbarer und zugänglicher Webanwendungen.

Als Lead Developer verantwortet er in Projekten die technische Umsetzung, Architekturentscheidungen sowie die kontinuierliche Optimierung der User Experience. Timo ist Ansprechpartner für technische und methodische Fragen, übersetzt Anforderungen in strukturierte Sprints und Git-Workflows und sorgt durch Code-Reviews, Pairing und Coaching für hohe Qualität und Effizienz im Team. Er arbeitet eng mit Design- und UX-Teams zusammen und bringt seine gestalterische Erfahrung auch in Tools wie Figma oder Adobe XD ein.

t.kaiser@atra.consulting

ISAQB SAG 2025

Daniel Wochnik — Mon, 15 Dec 2025 10:45:38 +0000

Es gibt einige Konferenzen, die wir gewöhnlich besuchen. Eine davon ist das ISAQB Software Architecture Gathering (SAG), das traditionell im November im H4 Hotel in Berlin stattfindet – so auch in diesem Jahr, vom 24. bis zum 27. November.

Als technologieagnostische Konferenz bietet das SAG weniger Deep Dives, dafür aber einen breit gefächerten und gut zugänglichen Überblick über den aktuellen „Architektur-Mainstream“ in Deutschland. Man trifft viele bekannte Gesichter und das Programm ist üblicherweise mit namhaften nationalen wie internationalen Sprecherinnen und Sprechern besetzt. In diesem Jahr etwa mit Bernd Ruecker (Co-Founder Camunda, mit – Überraschung – einem halben, aber sehr sympathischen Werbevortrag), Cheryl Hung (ehem. CNCF), Alistair Cockburn (Mitautor des Agilen Manifests) oder Gregor Hohpe (dessen launisch-meinungsstarke Vorträge ich seit jeher mag).

Der Nachteil dieser breiten und bewusst agnostischen Ausrichtung liegt allerdings auf der Hand: Viele Themen bleiben eher an der Oberfläche. Auch in diesem Jahr gab es ausschließlich Talks der Kategorien „Beginner“ und „Intermediate“ – wirklich neue Erkenntnisse sind dementsprechend selten.

Wir waren dennoch vor Ort – und möchten im Folgenden ein paar Eindrücke teilen.

Themenlandschaft: weniger AI-Dominanz als erwartet

Ein Blick auf die Agenda brachte die erste Überraschung. Trotz ordentlicher Präsenz war AI nicht erdrückend dominant – für eine Architekturkonferenz zur aktuellen Zeit fast wohltuend. „Nur“ ungefähr jeder sechste Talk drehte sich explizit um die Themen AI, wobei natürlich sehr viele Sessions das Thema zumindest gestreift haben. Im Sprachgebrauch des Gartner Hype Cycle sind wir nun wohl endgültig über den Peak of Inflated Expectations hinaus und arbeiten uns langsam, aber sicher, hin zu wirklichen und nachhaltigen Use Cases.

Statt GenAI waren sozio-technologische Fragestellungen oder auch der Dauerbrenner DDD in diesem Jahr wieder deutlich präsenter.

Auch Green IT, ein Thema, von dem ich mir vor drei bis vier Jahren eine dauerhafte Etablierung erhofft hatte und das spätestens vom energieverschlingenden GenAI-Hype ein wenig in den Hintergrund gedrängt worden ist, war (für mich) überraschend präsent. Letzteres mag damit zu tun haben, dass das iSAQB seit vergangenen Jahr ein neues Modul „Green IT“ in seiner Advanced-Zertifizierung anbietet [1].

Vibe Coding, Verantwortung und Plattformarchitektur

Unter den Vorträgen ist mir der Talk „Vibe Coding Auth Without Melting Down!“ von Cheryl Hung besonders in Erinnerung geblieben [2]. Er ging der Frage nach, ob sich auch fehlerintolerante Bereiche wie Authentifizierung mittels Vibe Coding lösen lassen. Die Antwort: It depends. In ihrem Beispiel zeigte sie eine mit Claude Code generierte Authentifizierungslösung, die funktional war, aber typische handwerkliche Anfängerfehler enthielt – etwa die Verwendung veralteter Hash-Bibliotheken oder das unbeabsichtigte Leaken von Nutzerinformationen [3]. Das deckt sich sehr mit meinen eigenen Erfahrungen: Vibe Coding liefert einen erstaunlich brauchbaren, aber eben nicht fehlerfreien Ausgangspunkt [4].

Spannend war allerdings weniger der Code selbst, sondern Cheryls Vorgehen: Sie hat die Sicherheitslücken nicht eigenhändig gesucht, sondern Claude Code im einmal generierten Code gezielt nach Schwachstellen analysieren lassen – eine Vorgehensweise, die in der Praxis zunehmend eingesetzt wird [5]. Einerseits nicht unerwartet, andererseits irgendwie faszinierend – das LLM „weiß“ grundsätzlich von diesen Schwachstellen, muss aber erst in die richtige Richtung geleitet werden.

Damit bleibt Vibe Coding für mich auf einem Niveau, das signifikante Geschwindigkeitsvorteile ermöglicht – solange man den Leitsatz beachtet: Never vibe code an app you wouldn’t be able to code yourself. Ob das im Startup-Kontext immer beherzigt wird? We will see…

Als möglichen Lösungsansatz griff Cheryl das Konzept Shift Down Security auf. Während Shift Left als etabliertes Prinzip die frühzeitige Verlagerung von Verantwortung – etwa für Qualität, Tests, Sicherheit oder Architektur – in die Entwicklungsteams und in die frühe Phase des Entwicklungsprozesses beschreibt, setzt Shift Down an einer anderen Stelle an: Statt Verantwortung weiter nach vorne zu schieben, wird sie bewusst nach unten, also auf Plattform- und Infrastruktur-Level, verlagert [6][7].

Dort werden Sicherheitsmechanismen technisch und organisatorisch verankert – etwa durch vordefinierte, abgesicherte Base Images, verpflichtende Policies, vorstrukturierte Toolchains oder Plattform-Guardrails, die bestimmte Fehler (menschliche wie maschinelle) gar nicht erst zulassen. Dieser Gedanke deckt sich stark mit dem Prinzip sogenannter Enabling Constraints: Bedingungen, die nicht einschränken, sondern Qualität und Sicherheit gezielt ermöglichen [8].

Ein Konzept, das sowohl menschlichen als auch KI-basierten Entwicklerwerkzeugen hilft, typische Fehler gar nicht erst entstehen zu lassen. Und noch dazu ein netter Querverweis zum Talk von Michael Mahlberg war, in welchem Enabling Constraints eine wichtige Rolle einnehmen [9].

Der Übergang von Vibe Coding zu Shift Down war für meinen Geschmack etwas abrupt, zumal die gezeigten Authentifizierungsfehler kaum über Plattformmechanismen lösbar gewesen wären. Trotzdem ein sehr gelungener Talk mit einem prägnanten Beispiel sowie einem für mich neuen und interessanten Konzept.

Hexagons, Ports & Adapter

Auch der Vortrag von Alistair Cockburn zur hexagonalen Architektur [10] – laut ihm selbst eine der drei schlimmsten Benennungen von Architekturkonzepten überhaupt – war eine der Sessions, die gleichzeitig unterhaltsam, temporeich und technisch fundiert waren. Zum einen ist es schlicht faszinierend, den Urheber eines Architekturstils über Historie, Motivation und ursprüngliches Designziel sprechen zu hören. Zum anderen hat Alistair den Vortrag sehr geschickt mit konkreten Implementationsbeispielen aus unterschiedlichen Sprachen kombiniert.

Allein das Tempo machte den Talk für mich zum anspruchsvollsten Vortrag, den ich die Tage gehört habe – und damit zur willkommenen Abwechslung zu den insgesamt sehr gut gemachten, aber oft sehr einsteigerorientierten Sessions. Ein einzelnes fachliches Learning würde ich rückblickend gar nicht herausgreifen. Stattdessen hat sich mein Eindruck bestätigt, dass Port-&-Adapter-Architekturen zu den Stilformen gehören, mit denen sich jede Entwicklerin und jeder Architekt ernsthaft beschäftigt haben sollte (und spätestens dann versteht, wie ich von Hexagons zu Ports & Adaptern komme).

Fazit: Vor allem eine gute Orientierung

Was bleibt für mich am Ende vom SAG? Am Ende war es inhaltlich zumeist nicht revolutionär, aber durchaus wertvoll. AI war präsent, DDD sowieso – und manche Konzepte wirken erstaunlich robust gegenüber Hype-Zyklen. Vielleicht ist genau das der eigentliche Reiz des SAG: Man nimmt selten ein einzelnes atemberaubendes Konzept mit nach Hause, aber jedes Jahr ein etwas klareres Verständnis davon, warum sich bestimmte Ideen in der Architektur so hartnäckig halten. Und vielleicht reicht das völlig.

Referenzen

iSAQB Advanced Level Module – Green IT
https://isaqb.org/certifications/advanced-level/green-it/
Keynote: Vibe Coding Auth Without Melting Down!
https://conferences.isaqb.org/software-architecture-gathering/session/keynote-vibe-coding-auth-without-melting-down/
Cheryl Hung – Vibe Coding Auth Without Melting Down (Slides)
https://www.slideshare.net/slideshow/cheryl-hung-vibe-coding-auth-without-melting-down-isaqb-software-architecture-gathering-2025-pdf/284317660
Ein halber Tag im Leben eines Vibecoders
https://atra.consulting/engineering/ein-halber-tag-im-leben-eines-vibecoders
Passing the Security Vibe Check: The Dangers of Vibe Coding
https://www.databricks.com/blog/passing-security-vibe-check-dangers-vibe-coding
Shift-Down Security (SIG-Security Working Paper)
https://raw.githubusercontent.com/kubernetes/sig-security/main/sig-security-docs/papers/shift-down/shift-down-security.md
What is Shift-Down Security?
https://nirmata.com/2024/09/13/what-is-shift-down-security/
The Magic Power of Enabling Constraints
https://www.scrum.org/resources/blog/magic-power-enabling-constraints
Now We’ve Given Them Every Freedom – and They Still Don’t Do What We Want
https://conferences.isaqb.org/software-architecture-gathering/session/now-weve-given-them-every-freedom-and-they-still-dont-do-what-we-want/
The Hexagonal or Ports & Adapters Architecture
https://conferences.isaqb.org/software-architecture-gathering/session/the-hexagonal-or-ports-adapters-architecture/

Daniel Wochnik

Geschäftsbereichsleitung »Finanzdienstleistungen«

Daniel ist seit 2017 in der IT-Branche aktiv und bringt seine umfassende Erfahrung als Senior Managing Consultant und Geschäftsbereichsleiter für Finanzdienstleistungen bei atra.consulting ein. Besonders begeistert ihn das Zusammenspiel technischer, methodischer und organisatorischer Aspekte. Als leidenschaftlicher Läufer und bekennender 1. FC Köln-Fan hat er seine Leidensfähigkeit auch privat mehrfach unter Beweis gestellt. Seine Kunden unterstützt er als Softwarearchitekt, agiler Coach und Berater bei der nachhaltigen und zielgerichteten Umsetzung von Entwicklungsprojekten.

d.wochnik@atra.consulting

Ein (halber) Tag im Leben eines Vibecoders

Daniel Wochnik — Mon, 04 Aug 2025 13:05:04 +0000

Vier Stunden Vibe-Coding mit Lovable – ein Erfahrungsbericht zwischen Wow-Effekt, Warnsignalen und Wirklichkeit.

Vor einigen Monaten bat mich ein ehemaliger Kunde um Unterstützung. Er plante den Schritt in die Selbstständigkeit und wollte im Rahmen seines Businessplans eine grobe Kosteneinschätzung für eine eigene Website inklusive App. Der Einsatz von Standardlösungen kam für ihn aus verschiedenen Gründen nicht infrage. Nachdem wir seine Anforderungen in ein, zwei Runden durchgesprochen hatten, nannte ich ihm – eher konservativ geschätzt – einen Betrag von 60.000 bis 80.000 Euro für eine solide entwickelte, barrierefreie, SEO-optimierte Webanwendung mit Integration in relevante Umsysteme.

Die Summe überraschte ihn. Verständlich – viel Geld für ein Startup, das zu diesem Zeitpunkt noch nicht einmal offiziell gegründet war.

Gerade in solchen Situationen wirken die zahlreichen Vibe-Coding-Plattformen, die aktuell wie Pilze aus dem Boden schießen, besonders verlockend. Vibe-Coding ist ein von Andrej Karpathy – ehemaliger KI-Chef von Tesla und Mitgründer von OpenAI – geprägtes Konzept (Quelle bei X): Man beschreibt in natürlicher Sprache, was man bauen möchte, und ein großes Sprachmodell generiert direkt lauffähigen Code. Der Code selbst wird meist nicht wirklich verstanden – man folgt dem „Vibe“, iteriert in schnellen Feedbackschleifen. Eine faszinierende Vorstellung, besonders für Gründer ohne technisches Know-how.

Ein prominentes Beispiel für eine solche Plattform ist das schwedische Start-up Lovable: Nur drei Monate nach seiner Gründung Ende 2023 zählte es nach eigenen Angaben bereits 30.000 Abonnenten und erzielte einen jährlich wiederkehrenden Umsatz (Annual Recurring Revenue, ARR) von 17 Millionen Dollar (Handelsblatt). Keine fünf Monate später legte Lovable noch einmal nach – und wurde zum jüngsten Software-Unternehmen aller Zeiten, das die Marke von 100 Millionen Dollar ARR durchbrach (Tech.eu).

Ich persönlich nehme in der öffentlichen Debatte aktuell eine zunehmende Polarisierung rund um Vibe-Coding und AI-basierte Softwareentwicklung wahr. Während manche, wie etwa Softbank-Gründer Masayoshi Son, das Ende der menschlichen Programmierer postulieren und noch 2025 Milliarden autonomer AI-Agenten einsetzen wollen (heise.de), warnen Kritiker vor den Risiken von unkontrolliertem Code. Zuletzt machte ein Fall Schlagzeilen, bei dem ein AI-Agent eigenständig eine komplette Unternehmensdatenbank löschte und anschließend sogar noch versuchte, diesen Fehler zu verheimlichen (PCMag).

Auch die Studienlage ist alles andere als eindeutig: Während einige Erhebungen positive Effekte von AI-Tools aufzeigen, zeigt etwa eine Untersuchung der Non-Profit-Organisation Metr, dass erfahrene Entwickler zwar subjektiv von Effizienzgewinnen ausgehen – objektiv aber 19 % langsamer arbeiten, wenn sie AI-Tools einsetzen (metr.org).

Ich persönlich sehe mich irgendwo in der öffentlich wenig präsenten Mitte: Ich bin überzeugt, dass wir auf absehbare Zeit erfahrene Architekten und Entwickler brauchen, um komplexe Systeme zu verstehen, zu gestalten und langlebig zu betreiben – insbesondere, wenn es darum geht, die eigentlichen Bedürfnisse des Kunden zu ergründen. Gleichzeitig glaube ich, dass viele AI-Tools uns bereits heute spürbar effizienter machen können. Mein Bauchgefühl: 15 bis 20 Prozent Produktivitätsgewinn sind realistisch – unter den richtigen Bedingungen.

Aber ich gebe auch zu: Ich stehe dem konkreten Thema Vibe-Coding eher skeptisch gegenüber. Vielleicht, weil es niemand gern hört – und noch weniger gern zugibt –, dass das, was man selbst jahrelang gelernt, gelehrt und beruflich begleitet hat, plötzlich von einer Maschine besser, schneller und billiger erledigt werden könnte. Aber: Ist diese Skepsis berechtigt? Oder doch nur verletzter Entwicklerstolz?

Um genau das herauszufinden – um meiner Skepsis entweder ein solides Fundament zu geben oder es ihr zu entziehen – habe ich mich in ein kleines Offsite zurückgezogen. Für einen halben Tag bin ich selbst zum Vibecoder geworden: kein Editor, keine Zeile selbstgeschriebener Code. Nur ich, ein Use Case, ein KI-Tool – und vier Stunden Zeit.

Und genau von diesem halben Tag im Leben eines Vibecoders möchte ich euch jetzt erzählen.

Der Usecase

Ein reales Kundenprojekt schied allein schon aus Sicherheitsgründen aus – also musste ein internes Vorhaben her, das auch über meinen kleinen Proof of Concept hinaus einen echten Mehrwert bringt. Gleichzeitig sollte das Szenario überschaubar genug sein, um Lovable eine realistische Chance zu geben, aber auch nicht zu trivial – idealerweise mit mindestens einem integrierten Umsystem.

Die Wahl fiel schnell auf einen Profilgenerator. Bei neuen oder freiberuflichen Berater:innen entsteht regelmäßig Aufwand, ihren Lebenslauf oder ihre Projekthistorie in unser internes Standardformat zu überführen. Intern nutzen wir bereits intensiv Google Gemini, das sich gut dafür eignen sollte, Informationen aus Lebensläufen zu extrahieren und ansprechend aufzubereiten. Wenn das Ergebnis anschließend auch noch automatisch in Google Docs abgelegt wird, haben wir einen Use Case mit zwei Systemintegrationen – bei gleichzeitig klar umrissenen Ziel.

Klingt fair für mich.

Eine kurze Vorbereitung

Eine erste Prompt zur Profilerstellung war schnell geschrieben – und funktionierte überraschend gut. Das Zauberwort lautete: Few-Shot-Prompting. Auch die Einrichtung von Lovable war unkompliziert: Innerhalb von fünf Minuten war ich startklar und hatte für 25 $ im Monat das Pro-Abo abgeschlossen, inklusive 100 Credits. Insgesamt habe ich während meiner vier Stunden rund 130 Credits verbraucht und 50 € ausgegeben.

Das Creditsystem von Loveable

Erfahrungsbericht Workation

Daniel Wochnik — Wed, 25 Jun 2025 13:21:49 +0000

Meeresrauschen statt Meetingraum, Surfbrett statt Kaffeetasse aus der Cafeteria:

Die Vorstellung, mobiles Arbeiten zu nutzen, um den Laptop für ein paar Tage am Strand aufzuklappen, hat zweifellos ihren Reiz. Das haben inzwischen auch viele Unternehmen erkannt und bieten flexible Arbeitsmodelle an – darunter auch die sogenannte Workation (eine Mischung aus “Work” und “Vacation”).

Laut einer Studie des Deutschen Instituts für Wirtschaft von 2022 ermöglichen bereits 15,1 % der Unternehmen in Deutschland ein solches Modell. Eine aktuelle PWC-Studie aus dem Jahr 2024 zeigt: 80 % der 18- bis 29-Jährigen wünschen sich die Möglichkeit zur Workation. Und altersunabhängig würden ganze 30 % der Befragten ein Jobangebot ablehnen, wenn diese Option nicht gegeben ist. (Ich habe da übrigens meine Zweifel – in einer Onlineumfrage ist das schnell gesagt).

Rechtliche Rahmenbedingungen einer Workation

atra Weihnachtsspende 2024

Daniel Wochnik — Wed, 20 Nov 2024 11:51:00 +0000

Am vergangenen Wochenende war der erste Advent – die Weihnachtszeit hat offiziell begonnen. In dieser Zeit möchten wir bei atra.consulting einer Tradition folgen, die uns am Herzen liegt: “Spenden statt Schenken”.

Die Auswahl an wohltätigen Organisationen und karitativen Einrichtungen ist riesig. Alleine eine kurze Online-Suche nach dem Stichwort „Weihnachtsspende“ ergibt unzählige Treffer – mit vielen wunderbaren Projekten, die jede Unterstützung verdient hätten. Doch die schiere Vielfalt macht es schwierig, gezielt auszuwählen.

Da wir als IT-Beratungsgruppe täglich im technologischen Umfeld arbeiten, möchten wir unsere Spende deshalb auf einen Bereich konzentrieren, der direkt zu unserem beruflichen Alltag passt. Unsere Wahl fiel auf Open-Source-Software (OSS). Durch OSS werden nicht nur moderne Technologien ermöglicht, sondern auch Innovationen und Stabilität in der IT-Infrastruktur gefördert. Uns ist es wichtig, auch hier einen Beitrag zu leisten und uns für eine „karitative Technologie-Spende“ zu engagieren, die sich für viele Menschen langfristig positiv auswirken kann.

Das Rückgrat unserer digitalen Welt

Open-Source-Software ist das unsichtbare Rückgrat der digitalen Welt, auf das sich viele unserer Projekte und Technologien stützen. Oft denken wir gar nicht daran, dass hinter dieser Software kleine Entwicklerteams oder sogar Einzelpersonen stehen, die diese Infrastruktur ehrenamtlich und ohne finanzielle Rückendeckung aufrechterhalten.

Die Open-Source-Community sieht sich einem Spannungsfeld gegenüber: Auf der einen Seite ist “ihre Software” enorm erfolgreich und weit verbreitet. So läuft Android, ein auf dem Linux-Kernel basierendes Betriebssystem, auf über 2 Milliarden Geräten weltweit. Linux selbst, mittlerweile 25 Jahre alt, ist aus der digitalen Welt nicht mehr wegzudenken. Sein Einsatzgebiet reicht von Alltagsgeräten wie Smartphones und Druckern über Webserver und Cloudinfrastruktur bis hin zu Supercomputern, wo es auf 498 der 500 leistungsstärksten Systemen läuft. Die Weltherrschaft von Linux ist unbestritten.

Linux und Android sind zwar bekannte Beispiele, aber bei weitem nicht die einzigen. Die Datenbank SQLite, beispielsweise, ist außerhalb der IT-Welt kaum jemandem ein Begriff. Trotzdem wird sie Schätzungen zufolge auf über einer Billion Geräten aktiv genutzt.

Schattenseiten: Herausforderungen in der Open-Source-Welt

Obwohl Open-Source-Software das unsichtbare Rückgrat unserer modernen digitalen Welt darstellt, gibt es auch weniger beachtete Schattenseiten. Dieses Rückgrat ruht auf den Schultern engagierter Freiwilliger, die ihre Arbeit mit Leidenschaft und ohne kommerziellen Anreiz der Allgemeinheit zur Verfügung stellen. Doch von dieser Arbeit können sie oft nicht leben. Kritische Software-Infrastruktur wird deshalb häufig von Einzelpersonen in späten Nachtstunden oder am Wochenende – zusätzlich zu ihrem regulären Job – entwickelt und gepflegt.

Ein markantes Beispiel hierfür ist die Programmbibliothek OpenSSL, die rund zwei Drittel des gesamten Internetverkehrs verschlüsselt und damit eine Schlüsselrolle in der digitalen Sicherheit einnimmt. Ein über Jahre unentdeckter Fehler in OpenSSL führte zum berühmten Heartbleed-Bug, der eine erhebliche Sicherheitslücke darstellte und private Daten im Internet anfällig für Angriffe machte. Nach der Behebung des Bugs machte das Entwicklungsteam deutlich auf die strukturellen Probleme in der Open-Source-Welt aufmerksam und bat um Hilfe.

Ein etwas aktuelleres Beispiel wurde von Heise gar als größtes Fiasko in der Geschichte des Internets bezeichnet, dem wir gerade so entgangen sind. Vermutlich staatliche Akteure nutzten eine technisch hochentwickelte Methode, um die Paketierungssoftware XZ zu kompromittieren. Dabei setzten sie auf raffiniertes Social Engineering, indem sie die angeschlagene psychische Gesundheit von Lasse Collin, dem Hauptentwickler der Software, gezielt ausnutzten. Diese Aktion, die zunächst unscheinbar wirken mag, hätte fast eine Backdoor in nahezu jedes System weltweit geöffnet.

Open Source: Stärke durch Transparenz, aber wer trägt die Verantwortung?

An dieser Stelle möchten wir betonen: Open Source Software ist nicht per se unsicherer oder weniger nachhaltig als kommerzielle Software (Closed Source Software). Ganz im Gegenteil – die breite und öffentliche Aufarbeitung, wie im Fall von XZ, sehen wir als eine Stärke, die langfristig Sicherheit und Stabilität fördert. Gleichzeitig wirft dies aber auch die wichtige Frage nach einer fairen Lastenverteilung auf – ein Punkt, der in folgendem xkcd-Comic auf amüsante Weise illustriert wird.

Ob insbesondere große Unternehmen, alleine in Deutschland nutzen 71% dieser Open-Source-Software, sowie Staaten hier zum Erhalt unseres digitalen Rückgrats genug investieren und „zurückgeben“, ist ein sehr berechtigter Aspekt dieser Frage, bspw. erst kürzlich wieder von der Wikimedia gestellt.

Das Spannungsfeld zwischen der erfolgreichsten Idee der IT-Geschichte und vielen engagierten “stillen Helden” ist auch hier offensichtlich. Glücklicherweise werden auch Themen wie Burnout immer offener diskutiert.

Weihnachtsspende: Immer noch viel Auswahl

Nun gibt es auch bei der Suche nach geeigneten Spendenzielen im Open-Source-Bereich unzählige inspirierende Organisationen und Projekte, die jede Unterstützung verdienen. Statt selbst eine Auswahl zu treffen, haben wir innerhalb von atra.consulting eine kleine Umfrage gestartet. Der Rahmen war einfach: Für jedes Teammitglied stand eine Spendensumme von 50 € zur Verfügung. Alle Kolleginnen und Kollegen waren eingeladen, ihr persönliches Herzensprojekt vorzuschlagen. Anschließend wurde gemeinsam über die eingereichten Vorschläge abgestimmt.

So starten wir die Weihnachtszeit nun mit Spenden an folgende Projekte:

Signal – Der sichere, E2E-verschlüsselte Open-Source-Messenger überzeugte unser Team auf ganzer Linie. Neben innovativer Entwicklung, etwa im Bereich Post-Quantum-Verschlüsselung, leistet die Signal Foundation unschätzbare Arbeit. Mit Abstand auf Platz 1 erhält Signal 50 % der Spendensumme.

Wikipedia – Zwar keine klassische Open-Source-Software, aber ein unverzichtbares Open-Knowledge-Projekt. Es bereichert unseren Alltag und ist eine essenzielle Grundlage, auch für die Entwicklung moderner Technologien wie LLMs. Wikipedia erhält 30 % der Spendensumme.

Notepad++ – Ein einfacher, aber wertvoller Texteditor, der für viele von uns tägliches Werkzeug ist. Notepad++ erhält 20 % der Spendensumme und würdigt damit die Bedeutung kleiner, effektiver Tools.

Mit unserer Spendenaktion möchten wir nicht nur einen Beitrag leisten, sondern auch das Bewusstsein für die Bedeutung von Open-Source-Software schärfen. Wir laden alle ein, sich dieser Idee anzuschließen und die Open-Source-Community aktiv zu unterstützen.

Daniel Wochnik

Geschäftsbereichsleitung »Finanzdienstleistungen«

d.wochnik@atra.consulting

Übernahme SCS Consulting GmbH

Michael Schwarze — Fri, 16 Apr 2021 10:19:44 +0000

Die Schwarze Consulting GmbH, Nürnberg übernimmt im Zuge einer Nachfolgeregelung die SCS Consulting GmbH, Stuttgart.

Nach über 10 erfolgreichen Jahren in der Beratung rund um Softwareentwicklung insb. im Umfeld Handel, Online/E-Commerce erweitert die Schwarze Consulting GmbH aus Nürnberg ihre Branchenexpertise mit Übernahme der SCS Consulting GmbH aus Stuttgart um die Bereiche Finanzdienstleistungen und Behörden. Gleichzeitig kann so die regionale Präsenz der Unternehmensgruppe auf die dann fünf Standorte Nürnberg, Stuttgart, München, Hamburg und Berlin ausgeweitet werden.

Zur Schwarze Consulting GmbH

Seit 2009 unterstützt das Unternehmen namhafte Kunden bei Fragestellungen rund um Softwareentwicklung und das Management von Softwareentwicklungsvorhaben, insb. im innovativen E-Commerce-Umfeld. Die Unternehmens-DNA ist ganzheitliches Software Engineering, also die Entwicklung von langlebigen und wartbaren Softwaresystemen. Dies umfasst Softwarearchitektur- und Technologieberatung, Organisationsberatung von Softwareentwicklungseinheiten zu Struktur- und Prozessfragen sowie Interimsmanagement im Technologieumfeld.

Michael Schwarze, geschäftsführender Gesellschafter der Schwarze Consulting GmbH:

»Ich freue mich sehr, nach 10 erfolgreichen Jahren organischem Wachstums mit der Übernahme der SCS Consulting GmbH nun das berühmte nächste Kapitel der Unternehmensentwicklung einläuten zu können. Die beiden Unternehmen ergänzen sich hervorragend hinsichtlich ihres Leistungsspektrums und der Branchenexpertise, aber auch bezogen auf ihre Unternehmensphilosophie. So können wir unsere Kunden zukünftig noch umfassender bei ihren IT-bezogenen Fragestellungen unterstützen. Gleichzeitig erreichen wir damit eine Größe, die es uns erlaubt, nicht mehr nur als Sperrspitze für innovative Themen, sondern als umfassender Lösungspartner für unsere Kunden auftreten zu können. Mein herzlicher Dank geht an Herrn und Frau Zink, die ein hervorragend aufgestelltes Unternehmen übergeben. Ich freue mich darauf, mit großartigen Mitarbeiterinnen und Mitarbeitern unsere treuen Kunden weiterhin nachhaltig unterstützen zu dürfen.«

Zur SCS Consulting GmbH

Gegründet 2004 unterstützt das Unternehmen renommierte Kunden aus den Bereichen Finanzdienstleistungen und Behörden im IT- und Business-Consulting. Dies umfasst diverse Managementservices von der Managementberatung bis zum Coaching, sowie die Konzeption und Entwicklung von komplexen IT-Services in einem weiten Technologieumfeld.

Klaus-Ulrich Zink, geschäftsführender Gesellschafter der SCS Consulting GmbH:

»Nach dreieinhalb Jahrzehnten IT-Consulting freuen wir uns, mit Herrn Schwarze und seiner Schwarze Consulting GmbH eine optimale Lösung für unsere Nachfolgeregelung gefunden zu haben. Meiner Frau und mir, als Gründer und Gesellschafter der SCS Consulting GmbH, war es wichtig, für unsere Mitarbeiter:innen sowie Geschäftspartner einen Nachfolger zu finden, der die gewohnte Kontinuität bietet und dabei aber auch den Generationenwechsel ermöglicht. Mit Herrn Schwarze und seiner Schwarze Consulting GmbH ist dies gewährleistet, denn es übernimmt ein erfolgreicher Unternehmer, der über umfangreiche Erfahrung in der Softwareentwicklung, Beratung und dem Management verfügt. Gleichzeitig passt bei ihm aber auch die »Chemie«, so dass wir das Unternehmen, die Kunden und Mitarbeiter:innen in den besten Händen wissen. Wir bedanken uns herzlich bei allen, die uns bis hierhin begleitet haben und wünschen das Beste für die Zukunft.«

Pressemitteilung herunterladen

Michael Schwarze

Geschäftsführer

Michael ist ein erfahrener Softwareentwickler, -architekt und -manager mit über 30 Jahren Erfahrung in der Technologiebranche. Er hat sowohl in Startups als auch Konzernen auf Anwender- als auch Entwicklungs- und Beratungsseite gearbeitet. Coden ist für ihn nicht nur Beruf, sondern Leidenschaft, am liebsten mit dynamisch-typisierten Sprachen wie Ruby. Neben der Entwicklung langlebiger Softwaresysteme liegt ihm auch die Verbesserung des Managements in der Softwareentwicklung am Herzen. Wenn er nicht gerade mit seiner Familie und seinen zwei Kindern beschäftigt ist, findet man ihn in den Bergen, beim Joggen oder anderen sportlichen Aktivitäten.

m.schwarze@atra.consulting

Erste Prognosen der wirtschaftlichen Auswirkungen der Corona-Krise auf den Softwaremarkt

Michael Schwarze — Sat, 04 Apr 2020 09:34:44 +0000

Auch wenn derzeit keine verlässlichen Prognosen möglich sind, haben wir die uns verfügbaren Bruchstücke genommen, um ein Gefühl für die Auswirkungen der Corona-Krise auf den Softwaremarkt zu bekommen. Und noch sieht es nicht so schlimm aus… [Update: Dies ist eine Aktualisierung des Artikels vom 23.4.20 ergänzt um Daten vom 30.3.20.]

Verschiedene Indikatoren können dabei helfen, sich eine Meinung über die wirtschaftliche Entwicklung zu verschaffen, um so beispielsweise unternehmerische Entscheidungen fundieren zu können. Da wir im deutschen Markt für Software tätig sind, schauen wir uns regelmäßig die Prognose des Bundeswirtschaftsministeriums (BMWi) zur Entwicklung des deutschen Bruttoinlandsproduktes (BIP) und die bitkom ITK-Marktzahlen an.

Anfang 2019 war der Ausblick auf die wirtschaftliche Entwicklung in Deutschland mit 1,1 % Wachstum nicht nur sehr positiv, sondern zu dem Zeitpunkt insbesondere auf Basis der Entwicklung der vergangenen Jahre auch durchaus realistisch. Noch besser, dabei aber mindestens genauso verlässlich sah es mit 6,4 % für den Softwaremarkt aus.

Mit Ausbruch der Corona-Krise in Deutschland Anfang März 2020 haben sich diese Prognosen überholt und entsprechende Aussagen sind absehbar mit einer hohen Unsicherheit behaftet. Nichtsdestotrotz haben wir in diesem Artikel vom 23.3.20 eine erste korrigierte Indikation zur Entwicklung der Wirtschaftsleistung gefunden:

»Das Finanzministerium kalkuliert Regierungskreisen zufolge 2020 mit einem Rückgang der Wirtschaftsleistung um sechs Prozent«

Da seitens bitkom bislang noch keine korrigierten Zahlen für den ITK-Markt vorliegen, welche auch die Corona-Krise berücksichtigen, haben wir die vorhandenen Informationen absolut ins Verhältnis gesetzt, um eine erste Prognose für den Softwaremarkt ableiten zu können. Absolut bedeutet in diesem Zusammenhang, dass wir den Vorsprung von 5,3 Prozentpunkten, den der Softwaremarkt bislang bei der wirtschaftlichen Entwicklung gegenüber dem Gesamtmarkt hatte, 1:1 auf die neue wirtschaftliche Realität übertragen haben. Somit ergibt sich mit Stand vom 23.3.20 ein Rückgang des Softwaremarktes in Deutschland in 2020 von 0,7 %.

Einzelne Stellen, wie zum Beispiel auch das ifo Institut berichten zwar in Abhänggikeit von der Dauer des Shutdowns schon von einem Rückgang des BIP von bis zu 20,6 % für dieses Jahr. Wir greifen für diese Betrachtung aber nur auf Informationen aus regierungsnahen Kreisen zurück.

Diesbezüglich liegt seit dem 30.3.20 vom sogenannten »Sachverständigenrat zur Begutachtung der gesamtwirtschaftlichen Entwicklung« oder auch den Wirtschaftsweisen das Sondergutachten »DIE GESAMTWIRTSCHAFTLICHE LAGE ANGESICHTS DER CORONA-PANDEMIE« vor. Hierin werden drei mögliche Szenarien unter Berücksichtung der aktuellen Erkenntnisse der Corona-Krise zur Entwicklung des BIP für 2020 diskutiert. Im sogenanten Basisszenario, welches von den Wirtschaftsweisen als derzeit wahrscheinlichstes angesehen wird, geht die Wirtschaftsleistung in Deutschland dieses Jahr um 2,8 % zurück. Darüber hinaus werden zwei sogenannte Risikoszenarien vorgestellt. Das Risikoszenario »langes U« stellt sich auf ein Minus von 4,5 % ein, wohingegen der derzeitige Worstcase der Wirtschaftsweisen, das Risikoszenario »ausgeprägtes V« von einem Rückgang von 5,4 % ausgeht. Somit ist die Prognose der Wirtschaftsweisen vom 30.3.20 mit im schlimmsten Fall -5,4 % aber auch immer noch besser als die Annahme des Finanzministeriums vom 23.3.20 mit -6 %.

Entsprechend abgeleitet auf die Entwicklung des Softwaremarktes ergibt sich somit für diesen am 30.3.20 gemäß der Wirtschaftsweisen je nach Szenario für 2020 sogar noch ein Plus zwischen 0,8 % und 2,5 % oder nur ein leichter Rückgang um 0,1 %.

Auch wenn diese erste Ableitung natürlich eine Vereinfachung ist, die der Komplexität des Marktes nicht annähernd gerecht wird, halten wir sie doch für nicht ganz unrealistisch. Denn einerseits wird der Druck zur Digitalisierung an vielen Stellen durch die aktuelle Krise sogar noch steigen, kommt doch beispielsweise der Onlinehandel der aktuell erhöhten Nachfrage nicht hinterher. Und andererseits kann gerade in der IT viel Arbeit unabhängig vom Ort, also beispielsweise auch von daheim aus erfolgen. Die aktuellen Ausgangsbeschränkungen werden hier, anders als in anderen Branchen, somit auch nur geringere wirtschaftliche Auswirkungen zur Folge haben. Deutsche Unternehmen, die sich dem Thema Homeoffice gegenüber bisher eher verschlossen haben, sehen jetzt die Vorteile flexiblerer Arbeitsformen, wie zum Beispiel eine höhere Produktivität und geringere Arbeitsplatzkosten, aber auch eine geringere Umweltbelastung durch weniger Fahrten, etc. Sollte Deutschland diesbezüglich nun beispielsweise zu Skandinavien mit seiner Home Office Quote von 28 % aufschließen, könnte die Krise auch etwas Gutes haben.

Michael Schwarze

Geschäftsführer

m.schwarze@atra.consulting

Warum Softwareentwicklung durch schnelleres Tippen nicht schneller geht

Michael Schwarze — Fri, 08 Nov 2019 11:22:45 +0000

Effizienz oder Effektivität? Wenn die Softwareentwicklung optimiert werden soll, wird häufig an der falschen Stelle angesetzt. Die Lösung liegt mit Blick auf zwei Studien und unter Anwendung des Pareto-Prinzips auf der Hand. Die Produktivität der Softwareentwicklung kann so um das bis zu Fünffache gesteigert werden – allerdings nicht durch schnelleres Tippen …

Inhalt:

Einleitung

Die Softwarekrise ist auch rund 50 Jahre nach ihrer offiziellen Feststellung noch nicht überstanden. Jede Softwareentwicklungseinheit steht vor der Herausforderung, dass es mehr Bedarf beziehungsweise Anforderungen als Entwicklungskapazität gibt. Um dem entgegenzuwirken, liegt der Fokus von entsprechenden Optimierungsversuchen häufig auf Produktivitäts- beziehungsweise Effizienzsteigerungsmaßnahmen. Salopp gesagt, wird versucht, durch “schnelleres Tippen” mehr Software in kürzerer Zeit entwickelt zu bekommen.

Dies funktioniert aus verschiedenen Gründen nicht. Einerseits wird bei Effizienzsteigerungsversuchen häufig an der falschen Stelle angesetzt und der echte Hebel in der Softwareentwicklung, die Effektivität, wird andererseits viel zu selten betrachtet.

Effizienz – wie entwickelt wird

Softwareentwicklung ist zu einem hohen Anteil eine geistig-kreative Tätigkeit. Natürlich muss auch ein Schriftsteller zügig schreiben können, der Fertigstellungstermin eines Romans ist aber nur zu einem geringen Anteil von der reinen Schreibgeschwindigkeit des Schriftstellers abhängig. Gleiches gilt für die Softwareentwicklung. Es gibt zwar noch wenige Studien hierzu, die bestätigen allerdings unsere Projekterfahrung. Demnach umfasst ein Großteil der gesamten Entwicklungszeit für eine einzelne Software-Funktion Wartezeit und nur ein geringer Anteil ist Arbeits- beziehungsweise eben “echte” Entwicklungszeit:

© Darstellung: Schwarze Consulting GmbH – © Daten: Kanban University: https://leankanban.com/flow-efficiency-a-great-metric-you-probably-arent-using/

Die sogenannte Flow Efficiency, also die Dauer für die Entwicklung einer Funktion geteilt durch die reine Arbeitszeit, beträgt üblicherweise 15 %; Organisationen, die sich noch gar nicht mit dem Thema befasst haben, liegen häufig bei nur 1-2 % und am anderen Ende gibt es wenige Entwicklungseinheiten, die auf eine Flow Efficiency von bis zu 40 % kommen. Der Normalverteilung folgend, darf man hier aber guten Gewissens erstmal die üblichen 15 % ansetzen.

Der ABC-Analyse oder auch dem Pareto-Prinzip folgend, sollte man sich bei einer Wartezeit von 85 % natürlich zunächst um diesen großen Hebel kümmern. Bei entsprechenden Produktivitäts- beziehungsweise Effizienzsteigerungsmaßnahmen der Softwareentwicklung wird er aber unserer Erfahrung nach nahezu kategorisch ignoriert. Vermutlich weil die Wartezeiten schwerer zu greifen sind, als die eigentliche Arbeitsleistung. Dabei sind sie auch einer der Gründe, warum die Umsetzungsdauer von Entwicklungsvorhaben schwer zu schätzen ist, beziehungsweise entsprechende Schätzungen häufig daneben liegen: Wartezeiten sind kaum vorhersehbar, geschweige denn solide abschätzbar. Was ich zu entwickeln habe, kann ich als Entwickler sicherlich sehr gut mit etwas Erfahrung einschätzen. Aber wann ich wie lange auf was oder wen dabei zu warten habe, ist nicht deterministisch.

Selbst wenn man mit viel Aufwand die Entwicklungsgeschwindigkeit um 50 % erhöht bekäme, so hat man auf die übliche Flow Efficiency doch dann gerade mal 7,5 % an Umsetzungsdauer gewonnen1. Die Fertigstellung einer einzelnen Funktion wird durch “schnelleres Tippen” des Entwicklers also nur unwesentlich beschleunigt.

Und wenn man ehrlich ist, so wird in vielen Organisationen durch eine Vielzahl von Hürden für den Entwickler die Entwicklungsgeschwindigkeit sogar eher noch mutwillig reduziert. Als Beispiele seien hier die Team-übergreifend einheitlich zu verwendende IDE zu nennen, die den einzelnen Entwickler eher verlangsamt. Oder Internet-Proxys, die einen daran hindern, notwendige Entwicklungsbibliotheken zu beziehen, nicht vorhandene Admin-Rechte auf dem Entwicklungsrechner, quälende langsame Test-Suiten, für die niemand Zeit zum Aufräumen bekommt, und so weiter.

Nicht, dass das falsch verstanden wird. Es ist extrem wichtig, in die Entwicklungseffizienz durch vernünftiges Tooling, individuelle IDEs und schnelle Feedback-Zyklen zu investieren, um einem Entwickler eine optimale Arbeitsumgebung zur Verfügung stellen zu können und so insbesondere die Entwicklungsqualität zu erhöhen. Die Umsetzungsdauer eines Features wird dies aber, wie gezeigt, nicht signifikant reduzieren.

Multitasking

Ein Entwickler wechselt bei entsprechender Wartezeit natürlich zu einer anderen Aufgabe, zum Beispiel der Entwicklung eines zweiten Features:

Dieses Task-Switching ist aber sowohl grundsätzlich als auch bei Entwicklungstätigkeiten im Besonderen ein Produktivitäts- und Qualitäts-Killer. Jeder, der schon mal versucht hat, eine Aufgabe zu erledigen, die eine gewisse Konzentration erfordert und dabei permanent unterbrochen wurde, sollte das leicht nachvollziehen können. Und bis ein Entwickler das mentale Modell einer umfangreichen Codebasis “in den Kopf geladen” hat, können auch schon mal Stunden vergehen, bevor eine Zeile verändert wird. Blöd, wenn er dann kurz vorher gestört wird. Es ist also extrem wichtig, ein Arbeitsumfeld für Entwickler zu schaffen, in dem sie durchaus mehrere Stunden ungestört sind.

Sind dann mehrere Entwicklungsaufgaben parallel in Bearbeitung, um die Wartezeit zu optimieren, kommt es häufig zu Situationen, in denen der Entwickler eigentlich an beiden Features gleichzeitig arbeiten müsste, was natürlich nicht geht. Somit entsteht an einer Stelle eine zusätzliche Wartezeit () und die Umsetzungsdauer erhöht sich entweder beim einen (Entwicklungsdauer Feature 1 = 100 % + x) oder beim anderen Feature (Entwicklungsdauer Feature 2 = 100 % + y) entsprechend. Die Umsetzungdauer jedes einzelnen Features, welches parallel zu anderen entwickelt wird, verlängert sich durch Multitasking also.

Untersuchungen zeigen, dass ein Entwickler trotz dieser Task-Wechsel aber auch nur 25-50 % seiner Zeit pro Tag mit reinen Entwicklungstätigkeiten verbringt. Unter Annahme der üblichen Flow Efficiency von 15 % schafft ein Entwickler es also, an 2 bis 3 Features parallel zu entwickeln; mit entsprechenden Zeit- und Qualitätseinbußen. Also liegt auch unter Einsatz von Multitasking das angenommene Effizienzpotential durch “schnelleres Tippen” bei nur 18,75 % 2 und somit immer noch unter der Pareto-Schwelle.

Effizienz in der Softwareentwicklung ist also nicht der Heilsbringer, da ihr Hebel gering ist und ihre Optimierung, beispielsweise durch Multitasking auch negative Auswirkungen mit sich bringt.

Effektivität – was entwickelt wird

Die Effektivität, also die Frage, was beziehungsweise ob das Richtige entwickelt wird, ist bei der Optimierung von Softwareentwicklungsvorhaben unserer Erfahrung nach häufig nur von nachrangiger Bedeutung. Dabei werden nur 20 % der Anforderungen wirklich benötigt:

© Darstellung: Schwarze Consulting GmbH – © Daten: Universität Karlsruhe: https://ps.ipd.kit.edu/downloads/za_2007_schlanke_produktionsweisen_moderne_softwareentwicklung.pdf

Auch hier springt einen die ABC-Analyse oder das Pareto-Prinzip wieder geradezu an. Durch die richtige Auswahl dessen, was entwickelt wird, also über die Effektivität, lässt sich die Softwareentwicklung offensichtlich wesentlich leichter verbessern als über die Effizienz: der Hebel ist hier mit 80 % beim “Was” entwickelt wird viel höher als die oben weiter genannten 15 % beim “Wie”.

Zugegebenermaßen etwas polemisch formuliert, müsste eine Entwicklungseinheit, da bei 20% ja nur jedes fünfte umgesetzte Feature auch wirklich zum Einsatz kommt, kalkulatorisch auch “einfach” nur fünf Mal so groß sein, um die fehlende Effektivität zu kompensieren. Wir sind mit dem Vorschlag leider noch bei keinem Budgetverantwortlichen durch gekommen …

Bei Umsetzungen im Kundenauftrag ließe sich natürlich argumentieren, dass der Kunde doch alle Anforderungen bezahlt und damit doch wohl auch alle Anforderungen benötigt werden. Doch auch hier ist der Bedarf meist größer als die Entwicklungskapazität oder das Entwicklungsbudget. Und auch in diesem Fall stellt der Auftraggeber früher oder später fest, dass das eine oder andere Feature vielleicht doch nicht oder zumindest nicht so gebraucht wird, weshalb man auch hier drauf achten sollte, was entwickelt wird.

Weniger ist in der Softwareentwicklung also wirklich mehr, auch wenn es zunächst abwegig erscheint und abgedroschen klingen mag. Optimierungsversuche sollten hier also immer zuerst auf die Effektivität abzielen.

Lösungsansätze

Wie kann ich aber nun die Effektivität meiner Softwareentwicklung erhöhen, also dafür sorgen, dass möglichst viel von dem umgesetzt wird, was auch wirklich benötigt wird und möglichst wenig von dem, was nicht wirklich benötigt wird?

Wir erleben immer wieder Product-Backlogs, die voll von uralten Features sind. Wissend, dass 80 % davon nicht wirklich gebraucht werden, kann man also guten Gewissens davon ausgehen, dass die wichtigen Features schon umgesetzt wurden und die, die eine gewisse Zeit lang nicht zur Umsetzung kamen, auch nicht mehr gebraucht werden. Trotzdem müssen diese Features dann häufig umgesetzt werden, wodurch knappe Entwicklungskapazität unnötig gebunden wird. Effektive Softwareentwicklung ist keine “Supermarktkasse”, wo jeder früher oder später dran kommt. Um effektiver zu werden, müssen die Anforderungen sich jeden Tag aufs Neue hinsichtlich ihrer Priorität beweisen; Anforderungen, die nicht wichtig genug sind, sollten auch nicht “dran kommen”, wenn man mehr (des Richtigen) aus der Entwicklung bekommen möchte.

Anders herum erleben wir auch immer wieder, dass die Priorisierung von Features darüber erfolgt, welcher Anforderer “am lautesten schreit”. Wenn 80 % der Features aber nicht benötigt werden, wird so wiederum wertvolle, da knappe Entwicklungskapazität für unnötige Themen verschwendet, weil der, der am lautesten schreit, noch lange nicht der wichtigste Anforderer ist. Gibt man denen nach, entsteht natürlich der Eindruck, dass aus einer Entwicklungseinheit nicht genug heraus kommt, da eben nicht genug des Richtigen heraus kommt. So lange die Entwicklungseinheit sich selbst die Aufgaben priorisiert, wird sie immer Teil des Problems sein. In diesem Fall ist es genau wie an einer Supermarktkasse: Wenn ich vorgelassen werden möchte, kann das nicht der Mitarbeiter an der Kasse, also die Entwicklungseinheit entscheiden, sondern ich muss der Reihe nach alle vor mir Stehenden fragen beziehungsweise davon überzeugen, dass mein Anliegen dringender ist.

Wichtig ist in solchen Fällen, dass die üblicherweise vielen verschiedenen Stakeholder der Softwareentwicklung das Problem unter sich lösen. Hierzu haben wir schon erfolgreich unterschiedliche Ansätze, üblicherweise Gremien-orientiert in verschiedenen Organisationen implementiert. Alternativ wird es durch einen entsprechend “starken” Product Owner erledigt:

Die Rolle des Product Owners ist zwar mittlerweile in vielen Organisationen, die sich mit Softwareentwicklung beschäftigen, besetzt. Unserer Erfahrung nach aber noch eher selten im Sinne eines »Unternehmers im Unternehmen« (“Entrepreneur”), der auch alleine und vollumfänglich über die Roadmap und Features “seines” Produktes entscheiden kann. Dabei ist eine seiner Hauptaufgaben, “Nein” zu den meisten Anforderungen zu sagen und das Entwicklungsteam so effektiv und produktiv entwickeln zu lasssen. Alle anderen der oben gezeigten Ausprägungen der Rolle Product Owner werden üblicherweise einen konsens-orientierten Ansatz mit ihren Stakeholdern zur Priorisierung finden müssen. Wobei auch einem “starken” Product Owner dieser Weg durchaus angeraten sein kann.

Fazit

Eine effiziente Softwareentwicklung ist heutzutage ein Hygienefaktor. Über die Effizienz lässt sich die Produktivität in der Entwicklung, wie wir gezeigt haben, mit unter 20 % auch nur begrenzt steigern. Wenn das Thema Effizienz in der Softwareentwicklung angegangen wird, empfehlen wir, Wartezeiten zu reduzieren, da diese üblicherweise den Großteil der Entwicklungszeit eines Features ausmachen.

Wer wirklich mehr aus seiner Softwareentwicklungseinheit heraus bekommen möchte, sollte tatsächlich weniger entwicklen, nämlich weniger der nicht benötigten Features. Über die Effektivität lässt sich die Produktivität in der Entwicklung um das bis zu Fünffache steigern! Dann ist auch wieder ausreichend Kapazität für die wichtigen Features vorhanden. Hierzu wird jemand in verantwortlicher Position gebraucht, der “Nein” sagen kann – beispielsweise ein entsprechend “starker”, also befähigter und ermächtigter Product Owner.

Fussnoten:

15 % normale Flow Efficiency beziehungsweise Entwicklungszeit * 50 % angenommene Optimierung = 7,5 % optimierte Entwicklungszeit und somit Reduktion der gesamten Umsetzungsdauer.
Der Mittelwert der Zeit, die ein Entwickler pro Tag mit reiner Entwicklung verbringt von 25-50 % ist 37,5 %. Die Annahme im voran gegangenen Beispiel bei der Entwicklung eines Features war, dass 50 % der reinen Entwicklungszeit optimierbar wären. Bei Multitasking somit also 50 % von 37,5 % = 18,75 %.

Michael Schwarze

Geschäftsführer

m.schwarze@atra.consulting