Product over Projects: Inside RZL Software GmbH’s “textbook Scrum,” .NET modernization, and culture of ownership

Session context and core message

In “Herbert Windsperger, Scrum Master bei RZL Software” (RZL Software GmbH), we heard a concise, first‑hand account of how a product‑driven software company structures teams, process, and technology to ship quality sustainably. The north star is reusable value for many users, not one‑off custom builds. That principle shapes everything—from product planning to engineering culture, from hiring to onboarding.

What stands out: RZL Software builds a modular suite for tax advisors and companies. Customers choose which products and modules they want; no one has to buy “everything.” Engineering works in stable, accountable teams, delivering in “textbook Scrum” two‑week cycles. The stack is firmly Microsoft‑centric (.NET/C#, Entity Framework Code First, Microsoft SQL Server, WPF/Blazor) and guarded by a robust safety net—around “10,000 unit tests that run at night.” Microsoft Azure DevOps Server is the operational backbone for backlog, code, tests, builds, and deployments.

Product, not bespoke projects: the business model that drives engineering

RZL Software is “a little over 100 people,” with roughly half dedicated to software development. The crucial differentiator: product development. Clients—especially tax advisors and companies—consume a modular suite and pick only the modules they need. There is no individual development for single users.

That choice reshapes engineering:

• No custom one‑offs: Features and components are designed for reuse and to help many users.
• Time to build well: With no external project deadlines, RZL decides when to ship—when the quality is there.
• Sustainable product stewardship: Modules are built for the long run and maintained as part of a coherent suite.

For engineers, this means focusing on design quality, reuse, and consistent processes rather than deadline firefighting.

Team topology: a team per product, reinforced by architecture and core capabilities

“Each product is built by a development team.” That simple rule explains how RZL scales. Product teams own their module end to end—backlog to delivery—and, for newer products, operate as Scrum teams.

Beyond the product teams, there is “a team of architects and core [framework] developers” that provides central components used across products. This pattern supports consistency, reuse, and delivery speed by giving teams reliable building blocks.

Key points from the talk:

• Newer teams: Scrum, C#, .NET
• Older “cash cows”: C++, to be phased out over time
• Hiring focus: “as many .NET developers as possible” for modernization and new development

“Textbook Scrum”: Dailies, Plannings, Reviews, Retros—on two‑week sprints

Herbert Windsperger describes the day‑to‑day as “Scrum actually still by the book.” Concretely:

• Daily stand‑ups
• Sprint planning
• Reviews
• Retrospectives
• Fixed two‑week sprints

This cadence supports predictable flow, focused work, and regular inspection of increments—ideal for engineers who value clear, iterative rhythms.

Ownership: encouraged—and expected

Ownership at RZL Software is not just a cultural tagline; it shows up in daily decisions. A vivid example from the talk: vacation planning is decided within the team—“we don’t need someone from outside to decide for us.”

The implication:

• Teams own their work and readiness for release.
• Release timing is an internal, quality‑based decision.
• Decisions are made where the expertise sits: inside the team.

This blend of freedom and responsibility is what strong product teams thrive on.

Technical backbone: Microsoft stack, modern .NET, and rigorous quality

RZL operates “purely in the Microsoft environment.” Concretely:

• Languages & frameworks: C#, .NET
• Data access: Entity Framework Code First (as OR mapper)
• Database: Microsoft SQL Server
• UI technologies: WPF or Blazor
• Controls: third‑party/middleware control libraries where it makes sense, rather than building every control from scratch

The codebase has a long history—the company dates back to 1983—with legacy C++ that the teams are steadily lifting to .NET/C#. Reasons include broader technical possibilities and hiring realities: it’s hard to find developers who want to work in C++.

RZL keeps frameworks and development environments up to date to leverage “the latest language features.” Upgrades are effortful, but the risk is contained by tests:

For engineers, this signals support for platform evolution, real safety nets, and a modern language/tooling toolkit.

Azure DevOps as the operational core

“The heart of software development is our Microsoft Azure DevOps Server.” That line says it all. RZL runs an end‑to‑end flow in Azure DevOps:

• Backlog management
• Source control
• Test plan integration
• Boards for each Scrum team
• Build and deployment services for continuous integration and provisioning

This backbone provides transparency, traceability, and automation—and reinforces “textbook Scrum” with battle‑tested tooling.

Hiring with pace and clarity: process, criteria, and team fit

Recruiting starts in a familiar way—via email “to jobs.jt.at” or by uploading application documents on the website. From there, pace matters. HR teams up quickly with a recruiter from the functional area, and within 48 hours the decision is made whether to move forward or not.

The next steps:

1) First interview (classic): with HR and someone from the functional area. Topics include:

• Motivation: “Why did this person apply to our company?”
• Background: experience and technical knowledge
• Learning mindset: more important than raw knowledge is “the willingness and interest to continue learning and adopt new technologies.”

2) Second interview (about three hours): A deep dive into how the team works and builds software, delivered by the very team the candidate would join. Demonstrations include:

• How backlog items are prioritized
• How software is produced, including unit tests
• How deployments to test systems run

Purpose: to check “whether the chemistry fits between the candidate and the team.” Afterward, feedback is collected, and “the team decides whether the candidate is accepted and receives an offer.”

This team‑led decision underscores collaboration as a core expectation. RZL looks for people, not just profiles, who will thrive in the team’s way of working.

Onboarding: guided, structured, and real from week three

If both sides agree and an offer is accepted, onboarding starts—without “throwing anyone in at the deep end.”

• First two weeks: guided ramp‑up and training, including video tutorials if needed.
• From week three: work on “real code” with the Scrum team, supported by a buddy.
• Quality gate: code ships to users, but “quality is assured through reviews and tests.”

This combines learning, team integration, and impact: contributing to product code early, protected by review and test practices.

Collaboration in practice: reuse, central components, and disciplined cycles

Taken together, the statements paint a clear delivery model:

• Product teams operate in disciplined, iterative sprints.
• An architecture/core team delivers central, reusable components across products.
• Prioritization and testing are first‑class activities, not afterthoughts.
• Azure DevOps (boards, pipelines, tests) provides the shared operational fabric.

For engineers, this means clarity of expectations, transparent workflows, and tooling that makes work visible and reliable.

Why RZL Software appeals to tech talent

From our DevJobs.at editorial standpoint, the session highlights several qualities engineers look for:

• Product focus over deadline chaos: “We decide ourselves … when we have the quality.”
• Impact at scale: features are designed “for multiple use”—to help many users.
• Sound engineering practices: unit tests, reviews, CI, Azure DevOps as the backbone.
• Modernization with intent: moving from C++ to .NET/C#, using WPF/Blazor and Entity Framework Code First.
• Learning over dogma: willingness to grow “often” matters more than what you already know.
• Team fit matters: candidates meet the team, see how it works, and the team decides together.
• Supported onboarding: buddy model, early product code contributions, guarded by tests.
• Ownership culture: from vacations to release readiness—decisions rest with the team.

If you enjoy stable, product‑oriented Scrum teams that prioritize quality and reuse, this environment will feel like home.

How candidates can stand out

Windsperger’s remarks point to a clear preparation playbook:

• Articulate your motivation: Why RZL Software GmbH? Why product development, .NET, and a modular suite for tax advisors and companies?
• Demonstrate your learning mindset: Show how you adopt new technologies—concrete examples are compelling.
• Show fluency in Scrum: daily stand‑ups, planning, reviews, and retrospectives are a lived cadence.
• Live quality: unit testing, code reviews, CI/CD, Azure DevOps—bring experience and appreciation for these practices.
• Lean into team chemistry: openness and curiosity count when the team makes the final call.
• Align on stack: C#, .NET, Entity Framework Code First, SQL Server, WPF/Blazor—all relevant signals.

Modernization as an ongoing discipline—backed by tests

Moving from a long‑standing C++ base (the company traces to 1983) to modern .NET is more than a tooling change. It touches architecture, data access, UI, and testing. RZL tackles this with a steady, test‑backed approach:

• Gradual retirement of older “cash cows”
• New development squarely in C#/.NET
• Broad unit‑test coverage as the safety net
• Willingness to update frameworks and toolchains proactively

The result is technically interesting work: bridging legacy and modern platforms with real user benefit.

A day in the flow: from idea to deploy

While the talk remains purposefully compact, the described steps outline a pragmatic delivery cycle:

1) Backlog prioritization: value for many, reuse, and quality drive selection.

2) Sprint planning and execution: slicing stories, owning commitments, and staying transparent via dailies.

3) Testing as a constant: unit tests arrive early and run automatically—at scale, nightly.

4) Review and feedback: show increments, learn, adjust next steps.

5) Deployments to test systems: part of the standard flow—CI/CD‑driven in Azure DevOps.

6) Release when ready: no external deadlines; quality determines timing.

It’s a durable recipe that balances agility with product accountability—ideal for engineers who want to ship methodically.

Clear process signals: fast start, team decision at the end

The recruiting process reveals a rare mix:

• Fast initial response (48‑hour decision to proceed)
• Deep, team‑led immersion (a three‑hour session)
• Team‑based final decision

From an employer‑branding perspective, this is compelling: candidates gain early transparency into how teams work, and teams preserve their culture by deciding together.

Conclusion: A product focus that strengthens engineering—and attracts talent

“Herbert Windsperger, Scrum Master bei RZL Software” portrays a company aligning product strategy, team organization, and technology along a coherent line: multi‑use value over one‑offs, disciplined two‑week Scrum cycles, a modern Microsoft stack with up‑to‑date tooling, and a test net that de‑risks upgrades. Ownership is tangible—not a slogan—from vacation planning to release readiness.

For .NET‑oriented engineers (or those eager to learn it) who value well‑organized, product‑centric work, RZL Software GmbH is an inviting destination. Or, in Windsperger’s words: the teams take the time to “program cleanly”—and ship when the quality is right.

• 

  

  Jakob Wegenschimmel, Software Developer bei RZL Software

  Jakob Wegenschimmel von RZL Software erzählt im Interview über seine Laufbahn im Software Development, was das Spannende in seinem Job ist und spricht über wichtige Dinge für Anfänger.

  Watch now