Why compromising on software quality is a leadership decision

TL;DR; Compromising on software quality is a leadership decision, not a team one, and lowering standards to meet deadlines carries business risks that should be explicitly approved by leadership. A clear Definition of Done helps maintain consistent quality, and any decision to reduce it should be transparent and deliberate. Development managers should ensure quality expectations are set and upheld at the leadership level, not left to teams under delivery pressure.

Published on 1 April 2025

Written by Martin Hinshelwood

1 minute read

https://nkdagility.com/resources/3YDTlhSlU4A

Would your CFO sign off on a financial report that was “mostly accurate”? Would your legal team approve a contract that “should be enforceable”? No?

Then why do organisations think it’s acceptable to compromise on software quality?

A strong Definition of Done prevents cutting corners. It ensures every increment meets the same professional standard. Reducing quality to meet deadlines is a financial decision, not a team decision. If leadership wants to change the quality bar, they should sign off on the risks—not sneak it past teams under the banner of “Agile.”

Scrum teams don’t get to lower quality. And if your teams are being asked to, the real conversation should be happening in the boardroom.

Has your leadership ever knowingly shipped bad software?

[the article is linked in the comments]

Also published on: LinkedIn

Connect with Martin Hinshelwood

If you've made it this far, it's worth connecting with our principal consultant and coach, Martin Hinshelwood, for a 30-minute 'ask me anything' call.

Our Happy Clients

We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.