MIC

Etablierte Firma

Alle Videos anzeigen

Technical Agile Enabling

Pia Otter-Bäck von MIC gibt in ihrem devjobs.at TechTalk Einblick darüber, wie im Unternehmen das Thema Technical Agile Enabling umgesetzt wird.

Beim Videoaufruf stimmst Du der Datenübermittlung an YouTube und der Datenschutzerklärung zu.

Video Zusammenfassung

In „Technical Agile Enabling“ zeigt Pia Otter-Bäck, wie gute technische Praktiken teamnah etabliert werden, um Features schneller und in höherer Qualität zu liefern, technische Schulden zu vermeiden und eine kontinuierliche Lernkultur zu fördern. Sie arbeitet dafür zeitlich begrenzt direkt mit Teams, identifiziert Code- und Technik-Herausforderungen und setzt maßgeschneiderte Verbesserungen um – von der Teilnahme an Scrum-Events über User-Story-Mapping, Ensemble Programming und Learning Hours. Zentrale Techniken sind BDD für Anforderungsdesign mit lebender, automatisierter Dokumentation, DDD für domänenzentriertes Systemdesign sowie eine nachhaltige Testkultur mit TDD, die Refactoring und Wartung erleichtert und unmittelbar übernehmbar ist.

Technical Agile Enabling bei MIC: Praktiken, die Softwareteams spürbar schneller und besser machen

Einleitung: Was wir aus „Technical Agile Enabling“ mit Pia Otter-Bäck (MIC) mitgenommen haben

In der Session „Technical Agile Enabling“ von Pia Otter-Bäck (MIC) bekamen wir bei DevJobs.at einen dichten, praxisnahen Einblick in einen Ansatz, der technische Exzellenz nicht dem Zufall überlässt. MIC ist Marktführer für Zollsoftware-Lösungen, 1988 gegründet, mit 265 Mitarbeitern, aktiv in 48 Ländern auf sechs Kontinenten und im Einsatz bei über 700 multinationalen Kunden. In dieser Größenordnung zählt jede Verbesserung in Qualität und Durchsatz – und genau dort setzt der „Technical Agile Enabling“-Ansatz an.

Pia Otter-Bäck machte deutlich: Ziel ist, gute technische Praktiken in der Organisation zu etablieren, damit neue Features schneller und mit besserer Qualität entstehen. Dazu gehören hochwertiger Code, effektive Entwicklungspraktiken, eine gesunde Unternehmenskultur – und der bewusste Umgang mit technischer Schuld, statt darin zu ertrinken. Der Ansatz ist keine einzelne Methode, sondern eine Sammlung wirkungsvoller, maßgeschneiderter Praktiken, die Teams in ihrer konkreten Situation stärken.

„Qualität ist kein Unfall, sondern es ist immer das Resultat von einem intelligenten Ansatz.“

Warum Technical Agile Enabling?

Pia formulierte die Ziele klar und messbar aus Team-Perspektive:

Technische Expertise erhöhen
Eine kontinuierliche Lernorganisation etablieren
Ein inspirierendes Arbeitsumfeld fördern
Die Qualität der Codebasis steigern
Ein gemeinsames Verständnis der Problemdomäne schaffen
Geschäftsagilität und Erfolg verbessern

Hinter diesen Zielen steht die Einsicht, dass Entwicklungserfolg nicht nur aus Code entsteht, sondern aus klaren Anforderungen, tragfähigem Systemdesign, nachhaltigem Testdesign und der Art, wie Teams miteinander arbeiten. Technical Agile Enabling verknüpft genau diese Ebenen – von der Anforderung über das Systemdesign bis hin zum Codedesign.

Rolle und Arbeitsweise der Technical Agile Enablers

Das Enabling bei MIC ist keine losgelöste Beratung, sondern findet „im Team“ statt. Die Technical Agile Enablers:

arbeiten für eine definierte Zeitperiode eng mit einem Team,
identifizieren gemeinsam mit dem Team codebasierte und technische Herausforderungen,
priorisieren, woran in dieser Zeit gearbeitet wird,
etablieren verbesserte Entwicklungspraktiken,
begleiten alle relevanten Scrum-Aktivitäten,
unterstützen bei größeren Herausforderungen mit Methoden wie User-Story-Mapping,
organisieren Ensemble-Programming-Sessions und Learning-Hours,
stellen geeignete Praktiken und Werkzeuge bereit.

Wichtig ist dabei der Verzicht auf „one size fits all“: Es gibt bewusst kein universelles Pattern. Lösungen sind maßgeschneidert und sollen Teams dort helfen, wo der konkrete Engpass liegt. Dieses Prinzip der lokalen, kontextbezogenen Optimierung ist zentral: Statt ein Standardrezept durchzudrücken, wird das Team in die Lage versetzt, wirksame technische Praktiken zu verstehen, auszuprobieren und nachhaltig zu verankern.

Durchgängiger Ansatz: Von Anforderungsdesign bis Codedesign

Pia spannte den Bogen über die komplette Wertschöpfung der Softwareentwicklung:

Anforderungsdesign: Klarheit schaffen, bevor Code entsteht
Systemdesign: Die Domänenlogik in den Mittelpunkt stellen
Codedesign und Testdesign: Qualität so planen, dass sie langfristig tragfähig ist

Diese Klammer ist entscheidend: Was in der Anforderung unklar bleibt, lässt sich später nur teuer korrigieren. Was im Systemdesign nicht verstanden ist, wird in Codeform kaum wartbar. Und ohne tragfähiges Testdesign entstehen kurzfristige Erfolge auf Kosten der langfristigen Entwicklungsfähigkeit.

Behaviour Driven Development: Anforderungen präzise und überprüfbar machen

Als Beispiel für wirksames Anforderungsdesign nannte Pia Behaviour Driven Development (BDD). Der Ablauf, wie sie ihn beschrieb, verbindet Fachlichkeit und Technik von Beginn an:

In einer Discovery erarbeiten Product Owner, Tester und Entwickler gemeinsam die Anforderung.
Sie fassen die Anforderung in Beispielen und Regeln zusammen.
In der Formulierung werden die Beispiele des Systemverhaltens dokumentiert – in Fachsprache, damit auch Kundenseite und nicht nur Entwickler sie verstehen.
Diese Dokumentation wird in der Entwicklung des Features automatisiert.
So entsteht eine „lebende Dokumentation“, die das Systemverhalten automatisch verifiziert.

Dieser Ablauf schafft einen durchgängigen Faden: von der Absicht (Fachziel) über konkrete Beispiele (Verhalten) bis zur Verifikation (automatisierte Checks). Der erkennbare Nutzen: Missverständnisse werden früh reduziert, Änderungen bleiben nachvollziehbar, und die Dokumentation altert nicht, weil sie an die automatisierten Verifikationen gekoppelt ist.

Praktische Anhaltspunkte für BDD im Teamalltag

Discovery ernst nehmen: Die gemeinsame Erarbeitung von Anforderungen durch PO, Tester und Entwickler ist kein Meeting-Proforma, sondern die Quelle für tragfähige Beispiele.
Beispiele konkret machen: Statt abstrakter Beschreibungen zählen aussagekräftige Beispiele und klare Regeln.
Fachsprache verwenden: Die Dokumentation sollte für Kunden und Fachexperten lesbar sein – Technik übersetzt die Fachabsicht, nicht umgekehrt.
Automatisierung einplanen: Die Beispiele sind nicht nur Text, sie werden in der Implementierung verankert und laufen als lebende Dokumentation mit.

Domain-Driven Design: Systemdesign an der Domäne ausrichten

Pia betonte beim Systemdesign Domain-Driven Design (DDD) – mit einer klaren Begründung:

Eine Applikation, egal wie toll sie entwickelt ist, und egal, was für eine tolle Architektur sie besitzt, ist nur nutzbar und nützlich, wenn sie das Problem löst.

Statt Architektur als Selbstzweck zu betreiben, rückt DDD die Domänenlogik in den Mittelpunkt. Im Zentrum stehen hier zwei Dinge, die Pia hervorhob:

kreative Zusammenarbeit zwischen technischen und Domänen-Experten,
iterative Arbeit am konzeptuellen Modell, bis es für alle in der Entwicklung verständlich ist.

Diese Art der Zusammenarbeit ist ein Katalysator für bessere Entscheidungen: Wenn das konzeptuelle Modell klar ist, können Architektur- und Implementierungsentscheidungen gezielter getroffen werden. Das reduziert Reibungsverluste und Nachjustierungen, weil die zentrale Frage – „Welches Problem lösen wir?“ – laufend beantwortet wird.

Praktische Anhaltspunkte für DDD im Alltag

Gemeinsames Modellieren: Fach- und Tech-Vertreter arbeiten am selben konzeptuellen Modell, bis es für alle nachvollziehbar ist.
Iterativ, nicht einmalig: Das Modell lebt mit – wie die Software. Neue Einsichten führen zu Anpassungen.
Entscheidungen am Problem ausrichten: Der Nutzen entsteht erst, wenn das Modell das reale Problem abbildet; technische Eleganz folgt aus der fachlichen Klarheit.

Testdesign und Testkultur: Nachhaltige Basis für Refactoring und Wartung

Beim Testdesign warnte Pia vor dem Trugschluss, ein einzelner Test würde das Thema erledigen. Sie nannte drei Aspekte, die zusammengehören:

Bereits in der Architektur über Testbarkeit nachdenken
Eine gute Testkultur etablieren
Test-Driven Development (TDD) praktizieren

Ziel ist ein nachhaltiger Testing-Ansatz, der Refactoring und Wartung effizient macht. Tests sind nicht nur ein Kontrollinstrument, sondern eine Investition in Veränderbarkeit. Je früher Testbarkeit mitgedacht wird, desto günstiger sind spätere Anpassungen – technisch und organisatorisch.

„Qualität ist kein Unfall …“ – sie entsteht dort, wo Testbarkeit gestaltet, TDD praktiziert und Kultur gelebt wird.

Praktische Anhaltspunkte für Testdesign

Testbarkeit als Architekturkriterium: Designentscheidungen daran messen, wie gut das System überprüfbar ist.
TDD als Praxis: Tests als Treiber für Designentscheidungen verstehen.
Nachhaltigkeit vor Kurzfristigkeit: Tests so anlegen, dass sie Refactoring nicht behindern, sondern ermöglichen.

Zusammenarbeit im Alltag: Story Mapping, Ensemble-Programming, Learning-Hours

Technical Agile Enablement verankert Praktiken direkt im Teamalltag. Pia nannte drei Formate, die in diesem Rahmen organisiert werden:

User-Story-Mapping für größere Herausforderungen
Ensemble-Programming-Sessions
Learning-Hours

Diese Formate erfüllen unterschiedliche Funktionen – von Orientierung über gemeinsame Umsetzung bis hin zum strukturierten Lernen – und sie sind darauf ausgelegt, die Teamfähigkeit zu stärken und Wissen zu verteilen.

User-Story-Mapping

Story Mapping hilft, größere Anforderungen in einen verständlichen Fluss zu bringen: Was ist das Nutzerziel? Welche Schritte gehören dazu? Welche Scheiben sind „Release-fähig“? Der Wert für Teams liegt in der gemeinsamen Sicht auf das Ganze und in der Fähigkeit, Prioritäten zu setzen, ohne den Überblick zu verlieren.

Ensemble-Programming

Bei Ensemble-Programming arbeitet das Team an einem Thema gemeinsam. Wissen bleibt nicht in Köpfen einzelner, und Lösungswege werden transparenter. Das Format fördert Qualität – nicht durch mehr Kontrolle, sondern durch geteiltes Verständnis und unmittelbares Feedback während des Arbeitens.

Learning-Hours

Learning-Hours schaffen eine wiederkehrende, explizite Lerngelegenheit. Die Lernorganisation, von der Pia sprach, wird dadurch greifbar: Lernen ist kein „Nebenbei“, sondern Teil der Entwicklungsarbeit. Das stärkt nicht nur Individuen, sondern auch die kollektive Problemlösefähigkeit des Teams.

Maßschneiderung statt Dogma: Warum kein „Generalrezept“ funktioniert

Ein wiederkehrendes Motiv in Pias Darstellung: Es gibt nicht „das Pattern“ oder „den generellen Ansatz“. Der Enabling-Charakter besteht darin, Praktiken im jeweiligen Teamkontext wirksam zu machen. Was zählt, ist Wirkung – gemessen daran, ob Teams damit ihre Arbeit besser erledigen können, schneller liefern und Qualität steigern.

Die Konsequenz daraus:

Praktiken werden auf konkrete Herausforderungen zugeschnitten.
Verbesserungen passieren iterativ und beobachtbar.
Das Team behält die Ownership; Enablers arbeiten als Teil des Teams, nicht als äußere Instanz.

Gemeinsame Sprache, geteiltes Verständnis: Der Kitt zwischen Fach und Technik

Pia betonte an mehreren Stellen die Rolle gemeinsamer Sprache und gemeinsamen Verständnisses:

BDD nutzt Fachsprache und Beispiele, damit alle das gleiche Verhalten meinen.
DDD bringt Domänen- und Technik-Experten an einen Tisch, um ein konzeptuelles Modell zu entwickeln, das jeder versteht.
Scrum-Aktivitäten und gemeinsame Formate (Story Mapping, Ensemble, Learning-Hours) stellen regelmäßigen Austausch sicher.

Dieser soziale, kommunikative Anteil ist das Fundament für technische Exzellenz. Ohne gemeinsame Sprache werden selbst gute Architekturen in der Praxis schwer handhabbar.

Business-Agilität als Ergebnis technischer Exzellenz

Ein wichtiges Ziel, das Pia explizit nannte, ist die Verbesserung von Geschäftsagilität und Erfolg. Der Weg dorthin führt über Technik: hochwertige Codebasis, effektive Praktiken, nachhaltiges Testdesign, gelebte Lernkultur. Wenn neue Features schneller und qualitativ besser entstehen, sinken Risiken und Durchlaufzeiten – und die Organisation kann auf Marktanforderungen reagieren, statt hinterherzulaufen.

Das ist kein Widerspruch, sondern eine Korrelation: Business-Agilität entsteht, wenn technische Agilität ernst genommen wird. Technical Agile Enabling sorgt dafür, dass genau diese Grundlagen gelegt und im Teamalltag verankert werden.

Konkrete Takeaways für Teams, die starten wollen

Die Session hat uns einige klare, direkt umsetzbare Impulse gegeben:

1) Anforderungen gemeinsam entdecken (BDD Discovery)

PO, Tester, Entwickler zusammenbringen und Beispiele plus Regeln erarbeiten.
In Fachsprache dokumentieren und diese Beispiele in der Entwicklung automatisieren.

2) Systemdesign an der Domäne ausrichten (DDD)

Technische und Domänen-Experten zusammenführen, um ein konzeptuelles Modell iterativ zu entwickeln.
Entscheidungen am Problem ausrichten, nicht an Mode-Architekturen.

3) Testbarkeit gestalten und TDD praktizieren

In der Architektur gezielt auf Testbarkeit optimieren.
Tests als Investition in Veränderbarkeit betrachten; TDD als Gestaltungswerkzeug nutzen.

4) Kollaborationsformate verankern

User-Story-Mapping bei größeren Herausforderungen einsetzen.
Ensemble-Programming-Sessions organisieren, um Wissen zu verteilen und Qualität zu erhöhen.
Learning-Hours etablieren, damit Lernorganisation gelebte Praxis ist.

5) Kontext vor Dogma

Praktiken auf die konkrete Herausforderung zuschneiden.
Iterativ verbessern und das Team in Verantwortung halten.

Leitprinzipien, die in Erinnerung bleiben

Qualität entsteht bewusst: „Qualität ist kein Unfall …“
Problem vor Lösung: „… nur nützlich, wenn sie das Problem löst.“
Lernen organisieren: Kontinuierliche Lernorganisation und inspirierendes Arbeitsumfeld sind Ziele – und Mittel zugleich.
Gemeinsam denken, gemeinsam bauen: Vom Anforderungsdesign bis zum Testdesign ist Zusammenarbeit die Konstante.
Maßschneiderung: Kein generelles Pattern – Lösungen müssen dem Team effektiv helfen.

Fazit: Enablement als tägliche Praxis, nicht als Projekt

„Technical Agile Enabling“ – so, wie Pia Otter-Bäck (MIC) es beschrieben hat – ist ein Ansatz, der Teams entlang der gesamten Entwicklungskette stärkt. Er beginnt bei der Klarheit der Anforderungen (BDD), zieht sich über ein domänenzentriertes Systemdesign (DDD) und führt bis zu einem nachhaltigen Testdesign inklusive TDD. Das alles wird getragen von gemeinsamer Arbeit im Team: Story Mapping, Ensemble-Programming, Learning-Hours und die aktive Teilnahme an den Scrum-Aktivitäten.

Die Ziele sind anspruchsvoll und zugleich bodenständig: technische Expertise erhöhen, eine Lernorganisation etablieren, ein inspirierendes Umfeld schaffen, Codequalität steigern, die Domäne verstehen und die Geschäftsagilität verbessern. Der Weg dorthin ist kein Dogma, sondern bewusst maßgeschneidert – mit Lösungen, die dem jeweiligen Team wirklich helfen.

Für uns war das zentrale Bild dieser Session: Enablement ist kein einmaliges Vorhaben, sondern eine tägliche Praxis. Es setzt auf klare Sprache, gemeinsame Modelle, automatisierte Verifikation und Lernformate, die in den Arbeitsalltag integriert sind. So wird aus „besserer Codequalität“ kein abstraktes Ziel, sondern eine spürbare Realität im Delivery-Tempo und in der Wartbarkeit. Und genau das macht den Unterschied – heute und morgen.

Weitere Tech Talks

Weitere Tech Lead Stories