BONUS Why Software Projects Fail When Everyone Keeps Quiet With Mark Stringer

BONUS: Why Software Projects Fail When Everyone Keeps Quiet

Software projects rarely fail because no one noticed the problem. More often, people see the missing database, the wrong assumptions, the broken process, or the weak product ownership, but the organization has trained them to stay quiet. In this BONUS episode, Mark Stringer, author of Delivering the Impossible, helps us understand how Scrum Masters can make reality visible again.

The Problem Of Intention In Software Projects

"You've got here a problem of intention, and you can't fix that by coming up with new, more magical marks on the page."

Mark starts with a story from the mid-1990s, before Agile was a common word in software teams. In a software development course, he heard the familiar promise: if only requirements could be captured with the right notation, the project would go correctly. His reaction was different. Software is not only a problem of documentation or process, it is a problem of translating intent into reality. That gap between marks on a page and what people actually need is where many projects begin to drift.

Point Of View Can Make Smart People Miss Reality

"If we see things in the wrong way, then point of view can take 80 IQ points off us."

Mark uses Alan Kay's idea that point of view is worth 80 IQ points to explain why good people can still make poor project decisions. A methodology can help, but only if it helps the team see what is actually happening. When the model becomes more important than reality, teams start defending the plan instead of learning from the system they are trying to change. Scrum Masters can help by asking what the current point of view hides, not only what it explains.

The Swamp: Why Project Complexity Is Not On The Diagram

"The fastest way between two points in a real organization is not necessarily a straight line."

In one banking project, Mark found two realities that had not survived the diagrams. First, a transaction database shown on every architecture diagram did not exist. Second, after six months of requirements work and several million pounds spent, a simple show and tell revealed that the design was organized around accounts when stakeholders needed it organized around people. The point was not that the team had failed to write enough requirements. The point was that the real environment was a swamp of legacy systems, power shifts, competing groups, regulations, users, and assumptions. You only discover that swamp by starting, showing real work, and letting stakeholders react.

Agreed Activity: When The Rituals Keep Going But The Project Is Already Lost

"Everybody knows why the project's failing. It's not a mystery at all."

Mark calls one common failure mode "agreed activity." The team keeps attending standups, planning meetings, status reviews, and retrospectives, even when people privately know the project is not going anywhere. Often they have tried to raise the real issue before and were punished for it. After that, silence becomes rational. The organization keeps reporting activity, expenditure, and compliance with the process, while the real blockers stay untouched. For Scrum Masters, this is a warning: ceremonies are useful only when they let reality enter the conversation.

Product Ownership, Bad News, And The Message Leaders Send

"The message that the development team hears is: don't rock the boat, just keep taking the money."

The Product Owner role can help break agreed activity, but only if the person has enough authority to make decisions and enough proximity to the team to learn. Mark describes two common anti-patterns: appointing someone junior who can be pushed around, or appointing someone so senior they have no time for the work. Worse, when someone points out a fundamental problem and gets metaphorically shot, the team learns the real rule: stay quiet. Leaders may think they are asking for positivity or commitment, but the team hears permission to cut corners, hide bad news, and treat spending as progress.

Make Scrum A Hypothesis Testing Framework Again

"That kind of unexpected feedback, that's the hope. That's the machine working."

Mark's practical advice is to keep the cadence, but make the meetings real. A show and tell should expose assumptions. A retrospective should make uncomfortable feedback usable. Scrum works best when it is treated as an empirical, hypothesis-testing framework, not a list of meetings to implement. Mark also points to user research as a way to extend learning back into the environment. Teams cannot guess how users will react, which buttons they will press, what they will ignore, or what market and organizational changes are shaping the work. They have to test, learn, and adjust.

About Mark Stringer

Mark Stringer is the author of Delivering the Impossible, a 2026 Apress book on better ways of seeing software project management. He has spent 30 years in software delivery as a developer, application researcher, and project manager, working with IBM, Xerox, and Cambridge University.

You can link with Mark Stringer on LinkedIn and follow Mark's writing at markstringer.github.io. You can find Delivering the Impossible on Amazon and Springer.