BLOG
Most software teams have never read their own contract.
Not the Scrum Master. Not the Product Owner. Not the developers. The document that defines what the team legally owes the client – and what happens if things go wrong – is signed by someone else, filed somewhere, and never looked at again.
Sebastian Dietrich looks at these contracts professionally. He is a certified court expert in software, called in by judges when software projects end in disputes. In his experience, the contracts are almost always wrong – not just imprecise, but actively harmful in the scenarios they were supposed to protect against.
At Agile Tour Vienna 2025, he laid out the legal realities that most agile practitioners have never been told: why „time and material“ contracts often aren’t what teams think they are, what courts actually look for when quality is disputed, and why the client who asks for a Product Owner is usually the worst person to be one.
This article covers the key points from that talk – and what any software team running agile projects should have in writing before the work begins.
A vendor wins a tender. Standard agile approach: methodology presented, client asked to appoint a Product Owner, work begins. A design firm is involved – the client’s existing partner – delivering assets in parallel. The design firm runs a month late. The deadline slips. The vendor flags the risk two months in advance.
Then January’s invoice doesn’t get paid.
The client commissioned an audit, run by the design firm that had a competing interest. The verdict: architecture unusable, code poor, documentation inadequate, needs a full rebuild. A court expert confirmed the finding. The lawsuit that followed claimed €1.5 million in repayment plus another €1.5 million in damages – the cost of running the project again.
The case is ongoing. But the point Dietrich makes is about the structure of the situation, not the outcome. A vendor who had a clear contract, a defined quality standard, and documented proof of process would have been in a completely different position. The vendor in this case had a document with „Dienstleistungsvertrag“ on the top and some agile terminology inside. That’s not a contract for bad times.
Most software contracts, in Dietrich’s experience, are written as sales documents. They describe the vendor’s methodology, reference past work, include process diagrams, and promise high-quality delivery. None of this is useful in a dispute.
A contract for bad times asks a different set of questions: what exactly is owed? Who decides what goes into the product? What happens when timelines slip? What constitutes acceptable quality, and how is it measured?
No superlatives. „Best quality“ means zero defects in a legal context. „Industry-leading processes“ set a standard you cannot meet. Write for the worst-case reading by someone who doesn’t know what a Product Owner is – because that’s the person who will decide what the document means.
This is the legal point that surprises most people.
Writing „Dienstleistungsvertrag (time and material)“ on the top of a document does not make it a service contract. Austrian courts – confirmed by the Supreme Court (OGH) – routinely classify software development agreements as Werkverträge (work contracts), regardless of what the header says. What counts is the intention of the contract: is the vendor being paid for time spent, or for delivering something that works?
If the client believes they were buying a working product – and most clients believe exactly that – a court will tend to find that a work contract existed. Which means the vendor is responsible for delivering something that functions, not just for hours logged.
The language that actually helps: that the client is giving instructions (weisungsgebunden), that the vendor has no sovereignty over the content of the software (keine Hoheit über den Inhalt), and that what is to be built is not fixed at the outset. These phrases are awkward. They are the phrases that determine liability.
If a contract says nothing about quality, Austrian law defaults to „recognised standards of the trade.“ In software, that means ISO/IEC norms. Dietrich has read them. His assessment: mostly useless. They describe processes, not outcomes. Many include clauses allowing deviations as long as they’re documented, which means they’re largely unenforceable.
GDPR adds another layer. Software handling personal data is subject to additional quality expectations – „appropriate technical measures“ is the standard phrase. What counts as appropriate is interpretable. You want your contract to define that, not leave it to a court.
The practical path forward: define quality yourself, in the contract, with measurable terms. Architecture rules (maximum component nesting depth, dependency constraints). Mandatory code review requirements. And something Dietrich returns to repeatedly – residual defect rates.
In Austrian law, Stand der Technik appears in over 250 statutes. It carries a specific legal meaning: based on scientific evidence, progressive, technologically advanced, and proven to be efficient and effective.
Almost no standard engineering practice meets this definition. There is no peer-reviewed scientific literature establishing that Scrum is superior to Kanban, or that three-layer architectures outperform two-layer ones, or that Mob Programming produces fewer defects than pair programming. When a vendor claims their software is „state of the art,“ they are making a claim they almost certainly cannot defend.
Dietrich’s recommendation: don’t use the phrase. Define quality in concrete, measurable terms instead. If you want scientific backing for specific practices, commission thesis work through a university – he’s done this himself, three times, for specific questions about development methods, at the cost of pizza and beer.
Residual defect rate. How many bugs remain in production software that haven’t been found yet.
The logic is straightforward. Research gives us reasonable estimates for how many defects developers introduce per 1,000 lines of code, and what proportion automated tests and reviews typically catch. From your issue tracker, you can see how many have been found. The arithmetic gives you an estimate of how many haven’t.
The thresholds that matter legally: 2 defects per 1,000 lines for standard software, 0.5 per 1,000 for anything safety-critical – which includes software handling personal data under GDPR. To reach 0.5, you need every testing layer working together: unit tests, integration tests, end-to-end tests, performance tests, and – most importantly – code reviews.
Code reviews find and prevent more defects per unit of time than any other testing technique. If you have ten hours to invest in quality, Dietrich argues, spend them on reviews. Not on chasing code coverage metrics that can be optimised without improving the underlying software.
One more thing: SBOMs. Software bill of materials – knowing exactly what your software is made of, at which versions. Increasingly a legal requirement. Already a good idea.
One of the most useful moments in the talk isn’t about contracts at all.
The client doesn’t want a Product Owner. They don’t want Sprint Reviews. They came to a software firm because they have a problem they can’t solve themselves, and they want a solution. They expect expertise. Asking them to define their own product – through backlog refinement, story writing, acceptance criteria – is asking them to do a job they didn’t hire you to do.
Understanding what you’re actually committing to when you take on a project – not what the contract says, but what the law implies – is part of what TechTalk’s Agile Scrum Foundation training is built around. For the architectural and quality dimensions Dietrich describes specifically, the Software Architecture Foundation Level Training covers the technical choices that need to be defined in contracts and defensible in audits.
The firms that avoid the most serious disputes are the ones who lead with domain expertise: „we build the best school software“ rather than „we build software using agile processes.“ The method is invisible to the client. The outcome is everything. The contract should reflect that – and it almost never does.
Agile is not illegal. But the combination of vague contracts, undefined quality standards, and clients who never understood the Product Owner role they were asked to play creates legal exposure that most software teams have never seriously considered. The fixes are not complicated. They require honesty about what a contract is for, and a willingness to define quality before the work begins rather than after the relationship breaks down.
Sebastian Dietrich spoke at Agile Tour Vienna 2025. The 2026 edition is live – the full program is available now.
Build your solid foundation through our training and continue developing your leadership and coaching journey.