MIC

Established Company

Show all Videos

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.

By playing the video, you agree to data transfer to YouTube and acknowledge the privacy policy.

Video Summary

In “Technical Agile Enabling,” Pia Otter-Bäck presents a practical approach to embed solid engineering practices so teams deliver features faster with higher quality, avoid technical debt, and foster a continuous learning culture. She partners with teams for fixed periods to surface codebase and technical challenges and implement tailored improvements, joining Scrum activities and facilitating user story mapping, ensemble programming, and learning hours. Key techniques include BDD for requirements with automated living documentation, DDD for domain-centric system design, and a sustainable testing culture with TDD that enables efficient refactoring—practices teams can apply immediately.

Technical Agile Enabling at MIC: Practices that help engineering teams deliver faster with higher quality

Introduction: Our takeaways from “Technical Agile Enabling” by Pia Otter-Bäck (MIC)

In the session “Technical Agile Enabling” by Pia Otter-Bäck (MIC), we at DevJobs.at got a crisp, practice-oriented view into an approach that treats technical excellence as a deliberate choice. MIC is a market leader in customs software solutions, founded in 1988, with 265 employees, offering solutions for 48 countries on six continents and used by over 700 multinational customers. At that scale, every gain in quality and throughput matters—and that’s where Technical Agile Enabling comes in.

Pia’s message was straightforward: establish sound technical practices across the organization so that new features are built faster and with better quality. That includes high-quality code, effective development practices, a healthy engineering culture—and a conscious stance toward technical debt, rather than drowning in it. The approach is not a single method but a set of impactful, tailored practices designed to strengthen teams in their specific context.

“Quality is no accident; it is always the result of an intelligent approach.”

Why Technical Agile Enabling?

Pia articulated the goals in clear, team-relevant terms:

Increase technical expertise
Build a continuous learning organization
Foster an inspiring work environment
Improve codebase quality
Create a shared understanding of the problem domain
Increase business agility and success

The underlying insight is that engineering success emerges not only from code, but also from clear requirements, robust system design, sustainable test design, and the way teams collaborate. Technical Agile Enabling ties these layers together—from requirements to system design to code design.

The role and working model of Technical Agile Enablers

At MIC, enabling is not an off-line consultancy—it happens inside the team. Technical Agile Enablers:

work closely with a team for a defined time period,
identify code-based and technical challenges with the team,
jointly decide what to address during that period,
establish improved development practices,
participate in relevant Scrum activities,
help with larger challenges using tools like user story mapping,
organize ensemble programming sessions and learning hours,
provide suitable practices and tools.

A key principle is the explicit avoidance of “one size fits all.” There is no universal pattern here. Solutions are tailored to where the actual bottleneck is. This local, context-specific optimization is central: rather than pushing a standard recipe, the enabler helps the team understand, try out, and embed effective technical practices that stick.

A coherent end-to-end approach: from requirements to code

Pia framed the software value stream holistically:

Requirements design: establish clarity before code
System design: put domain logic at the center
Code and test design: plan for quality that remains sustainable over time

This end-to-end view matters: unresolved ambiguity at the requirements level becomes expensive later. Poorly understood system design is hard to maintain in code form. And without sustainable test design, short-term gains come at the cost of long-term delivery capabilities.

Behavior Driven Development: Turning requirements into verifiable behavior

As a proven practice for requirements design, Pia highlighted Behavior Driven Development (BDD). The flow she described connects business and engineering from the start:

In a discovery session, Product Owner, tester, and developer work out the requirement together.
They summarize the requirement into examples and rules.
The examples of system behavior are documented in domain language so that customers as well as developers can understand them.
These documents are then automated during feature development.
The result is a “living documentation” that automatically verifies system behavior.

The benefit is a continuous thread from intent (business goal) to examples (behavior) to verification (automated checks). Misunderstandings are reduced early, changes stay traceable, and documentation stays alive because it is coupled to automated verification.

Practical anchors for BDD in day-to-day work

Take discovery seriously: the joint effort by PO, tester, and developer is the source of robust examples.
Make examples concrete: clear examples and rules beat abstract descriptions.
Use domain language: documentation should be readable by customers and domain experts, not only engineers.
Plan for automation: examples are not just text; they are embedded into implementation and run as living documentation.

Domain-Driven Design: Let the domain drive your system design

For system design, Pia emphasized Domain-Driven Design (DDD), with a clear rationale:

An application—no matter how well engineered or how impressive its architecture—is useful only if it solves the problem.

Rather than architecture as an end in itself, DDD puts domain logic front and center. Two elements stood out in her remarks:

creative collaboration between technical and domain experts,
iterative work on the conceptual model until everyone in development understands it.

This collaboration is a catalyst for better decisions: once the conceptual model is clear, architectural and implementation choices become more targeted. That reduces friction and rework, because the core question—“What problem are we solving?”—is continuously answered.

Practical anchors for DDD in the everyday

Model together: domain and tech folks build the same conceptual model until it is clear to all.
Iterate: the model evolves with the software; new insights trigger updates.
Align decisions with the problem: usefulness emerges when the model reflects the real problem; technical elegance follows from domain clarity.

Test design and test culture: Sustainable foundations for refactoring and maintenance

On test design, Pia cautioned against the illusion that writing “a test” settles the matter. She highlighted three intertwined aspects:

Think about testing already at the architecture level
Establish a healthy test culture
Practice Test-Driven Development (TDD)

The goal is a sustainable testing approach that makes refactoring and maintenance efficient. Tests are not just a control mechanism; they are an investment into changeability. The earlier testability is considered, the cheaper later adaptations become—technically and organizationally.

“Quality is no accident …” It emerges where testability is designed, TDD is practiced, and culture is lived.

Practical anchors for test design

Treat testability as an architectural concern: weigh design choices by how verifiable the system is.
Use TDD as a design tool: let tests inform design decisions.
Favor sustainability: craft tests so they enable, not hinder, refactoring.

Everyday collaboration: Story mapping, ensemble programming, learning hours

Technical Agile Enabling anchors practices directly in team routines. Pia called out three formats organized within that frame:

user story mapping for larger challenges,
ensemble programming sessions,
learning hours.

These formats serve different functions—from orientation, to shared implementation, to structured learning—and they are designed to strengthen the team and distribute knowledge.

User story mapping

Story mapping helps bring larger requirements into a coherent flow: What is the user goal? What steps are involved? Which slices are release-ready? The value lies in a shared view of the whole and in the ability to set priorities without losing sight of the context.

Ensemble programming

In ensemble programming, the team tackles a topic together. Knowledge doesn’t get stuck with individuals, and solution paths become transparent. The format raises quality—not through heavier control, but through shared understanding and immediate feedback during the work.

Learning hours

Learning hours provide a recurring, explicit learning opportunity. The learning organization Pia described becomes tangible: learning is not an afterthought but part of development. It strengthens individuals and the team’s collective problem-solving capability.

Tailoring over dogma: Why there is no “general recipe”

A recurring theme in Pia’s account is the absence of a universal pattern or generic approach. The core of enabling is to make practices effective in the team’s specific context. What counts is impact—measured by whether the team can do its work better, deliver faster, and raise quality.

The implications:

Practices are tailored to concrete challenges.
Improvements are iterative and observable.
Ownership remains with the team; enablers work as part of the team, not as an external authority.

Shared language, shared understanding: The glue between business and engineering

Pia repeatedly highlighted the role of shared language and shared understanding:

BDD uses domain language and examples so everyone means the same behavior.
DDD brings domain and technical experts together to develop a conceptual model everyone understands.
Scrum activities and the joint formats (story mapping, ensemble programming, learning hours) ensure regular exchange.

This social, communicative dimension is the foundation for technical excellence. Without shared language, even solid architectures become hard to manage in practice.

Business agility as the result of technical excellence

One explicit goal Pia mentioned is improving business agility and success. The path runs through the technical layer: high-quality codebases, effective practices, sustainable test design, and a lived learning culture. If teams ship new features faster and with better quality, risk and cycle time go down—and the organization can respond to market needs instead of lagging behind.

This is not a contradiction but a correlation: business agility emerges when technical agility is treated seriously. Technical Agile Enabling ensures that these foundations are in place and embedded in daily work.

Concrete takeaways for teams ready to start

The session offered several actionable prompts:

1) Discover requirements together (BDD discovery)

Bring PO, tester, and developer together and derive examples plus rules.
Document in domain language and automate these examples during development.

2) Let the domain drive system design (DDD)

Bring technical and domain experts together to iteratively build a conceptual model.
Align decisions with the problem, not with fashionable architectures.

3) Design for testability and practice TDD

Optimize architecture explicitly for testability.
Treat tests as an investment into changeability; use TDD as a design instrument.

4) Embed collaboration formats

Use user story mapping for larger challenges.
Run ensemble programming sessions to spread knowledge and raise quality.
Establish learning hours so a learning organization becomes lived practice.

5) Favor context over dogma

Tailor practices to the concrete challenge.
Improve iteratively and keep ownership within the team.

Guiding principles that stick

Quality is deliberate: “Quality is no accident …”
Problem before solution: “… useful only if it solves the problem.”
Organize learning: a continuous learning organization and inspiring environment are both means and ends.
Think and build together: from requirements to test design, collaboration is the constant.
Tailor practices: there is no general pattern—solutions must actually help the team.

Conclusion: Enablement as daily practice, not a side project

As described by Pia Otter-Bäck (MIC), Technical Agile Enabling is a way of strengthening teams across the entire development stream. It starts with clarity in requirements (BDD), continues through domain-centered system design (DDD), and reaches sustainable test design including TDD. All of this is carried by joint work inside the team: story mapping, ensemble programming, learning hours, and active participation in Scrum activities.

The goals are simultaneously ambitious and grounded: raise technical expertise, build a learning organization, foster an inspiring environment, improve code quality, deepen domain understanding, and increase business agility. The path is not dogma but deliberate tailoring—solutions that genuinely help the team in its context.

For us, the core image from this session is that enablement is not a one-off initiative but a daily practice. It relies on clear language, shared models, automated verification, and learning formats integrated into the flow of work. That’s how “better code quality” becomes a felt reality in delivery speed and maintainability. And that is what makes the difference—today and tomorrow.

More Tech Talks

More Tech Lead Stories