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 starti